System calls triggered by page faults

[Antti]

I know that this is not as efficient as "real" system calls. However, I was thinking whether this would be elegant or not. I am sure that this is already implemented somewhere.

Code: Select all

#define SYSCALL_TRAP 0xFFFFFFFC          /* "Some "kernel" address */

void Syscall(int number)
{
	*((int *)0xFFFFFFFC) = number;       /* Deliberate page faulting */
}

The page-fault handler would recognize the syscall number the user is trying to store at this "illegal" address. With C programming language, it is not very easy to recognize the call number portably. What about the parameters? Putting them to "parameter passing" space?

All the implementation details aside, what do you think about this in general? System calls could be triggered without any platform-specific opcodes. Programs could see system services like they see memory-mapped devices.

[Combuster]

- No concurrent system calls (race conditions).
- Significantly slower system calls.
- Actual pagefaults may be mistaken for system calls - try free(0) and it might just access that address

[iansjack]

I think you are addressing a problem that doesn't exist. Some parts of an OS are always going to be non-portable; for example the actual paging mechanism to implement your system would differ on different processors (as, almost certainly, would the fake address used).

Until all computers use the same instruction set you aren't going to get binary compatibility of a kernel, so why focus on the system call mechanism in particular? It can be made portable except for a small amount of architecture-dependent code. I don't see that as being a problem.

[skeen]

Has been discussed;
Here; http://forum.osdev.org/viewtopic.php?f= ... 21&start=0
And Here; http://forum.osdev.org/viewtopic.php?f=1&t=9827&start=0

[Antti]

I want to emphasize that efficiency is not very important if looking the idea itself. It is just platform-specific "detail".

In short: Memory-mapped system services with standarized inteface.

[skeen]

... try free(0) and it might just access that address

According to ISO-IEC 9899 (N1124) the behavior is; (7.20.3.2)

The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs.

Link to N1124; http://www.open-std.org/JTC1/SC22/wg14/ ... /n1124.pdf

[Antti]

Has been discussed

Exactly the same thing discussed already! I will look at those threads. Maybe there is not much more to talk about...

[skeen]

No concurrent system calls (race conditions).

One could have a sys call page-fault address per thread. In which case you'd be able to have concurrent sys calls.

[Antti]

If we had a plain toy OS (to avoid criticism of efficiency), we could consider to have this kind of implementation of "putchar":

Code: Select all

#define SYSCALL_PUTCHAR ???? ????    /* A trap address */

void putchar(int c)
{
	*((char *)SYSCALL_PUTCHAR) = c;
}

The basic idea seems quite elegant to me. I have always liked the memory-mapped I/O, like "when you write to this address, it has some effect".

[Combuster]

That gives the next problem, a pagefault doesn't show you the value that was attempted to be read or written, only the target address and the instruction that caused it. The pagefault handler couldn't sanely access the character value.

One could have a sys call page-fault address per thread.

And which portable mechanism are you going to use to get that address?

According to ISO-IEC 9899 (N1124) the behavior is

I must have gotten used to broken implementations.

[skeen]

One could have a sys call page-fault address per thread.

And which portable mechanism are you going to use to get that address?

Assuming you get the first one, when creating a process, it's just a matter of implementing the allocation of a sys call page-fault address as a part of the create thread method, I guess.

Assuming that threads are created from old threads, and that you're able to bootstrap 1 thread.

[skeen]

That gives the next problem, a pagefault doesn't show you the value that was attempted to be read or written, only the target address and the instruction that caused it. The pagefault handler couldn't sanely access the character value.

What one could do is to use two pages per thread to support sys calls. One to pass all arguments and such, and one to trigger the sys call. First one being present, last one not being.

However then writing to the non-present page would be somewhat alike doing a software interrupt, as it would just be a trap into the kernel.

[Antti]

That gives the next problem, a pagefault doesn't show you the value that was attempted to be read or written, only the target address and the instruction that caused it.

A real problem. I already mentioned it in the original post (when using C). In assembly, something like "mov [address], eax" would be possible. Then the page-fault handler would have to take that eax value (or whatever register would be) and store it. However, it is starting to look like the traditional system calls. It does not seem good if we had to care how the value is written. The simplicity and elegancy are lost.

Maybe this is not possible to implement on x86-platforms but it does not mean the idea is totally bad.

[Kevin]

Well, you could write an instruction emulator to "parse" the parameter from the faulting instruction and then skip the instruction before reentering userspace. This way you also get rid of the race conditions.

Possible? Absolutely. Sane? Not really.

[Combuster]

Assuming you get the first one, when creating a process, it's just a matter of implementing the allocation of a sys call page-fault address as a part of the create thread method, I guess.

And then what? Add an additional argument to every possible function in the app so you can pass it through?