I think the simple answer here is “extremely unlikely”. This proposed feature fundamentally violates the microkernel minimality principle, as the same can be achieved in other ways. It is also narrow in its application, and carries policy. It will also almost certainly lengthen the critical syscall pass and thus penalise the performance of everything. If someone comes with a convincing performance case then we’ll think about whether there is a clean way of addressing it. Gernot
On 22 Nov 2020, at 19:22, Andrew Warkentin
wrote: I am wanting to implement a system call origin limit (akin to that of OpenBSD) in UX/RT. This could probably be accomplished by adding a "set system call range" TCB method that takes the start and end addresses of the range in which system calls will be permitted without interception. Any system call issued from code outside this range would incur a user exception (which would provide all the state required for user code to handle the system call and resume the thread if desired).
UX/RT will require all binaries to be dynamically linked with a minimal "libroot" library that will contain an IPC transport layer that will be the only part of the system outside the root server that makes direct system calls. This will make it easier for later versions to retain backwards compatibility. Limiting system call origin should also make certain kinds of attacks more difficult.
I am also planning to use the system call origin limit in the Linux compatibility environment in order to distinguish Linux syscalls from seL4 ones, since Linux syscalls will never come from libroot. Each process in the Linux compatibility environment will have a fault handler thread that looks up the syscall and calls the corresponding UX/RT APIs, and will also replace the trap with a call to a jump table if the function containing it is a known syscall wrapper in order to cut down on the number of trips through the kernel.
Would it be possible to add something like this to the mainline seL4 tree? _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems