Re: [TUHS] Macs and future unix derivatives

On 2/9/21, Theodore Ts'o <tytso(a)mit.edu> wrote: seL4 basically provides no primitives other than send and receive, and UX/RT will just map read()/write()-family APIs onto send and receive (the IPC transport layer won't be trivial, but it will be simpler than those under most other microkernel OSes). Basically everything else will be implemented on top of the read()/write() APIs provided by the transport layer (memory mapping will sort of bypass it, but all user memory will be handled as memory-mapped files, even that which is anonymous on other systems). In order to better map onto seL4 IPC semantics, variants of read()/write() that operate on message registers and a shared buffer will be provided, but these will be compatible with each other and with the traditional versions (messages will be copied on read when a different variant was used to write them). Basically if there were something that couldn't be implemented efficiently and securely on top of a combination of read()/write() and shared memory, that would mean that it couldn't be securely implemented on top of IPC, and I'm not sure that there is anything like that. UX/RT's file locking will be implemented with RPCs to the process server just like open()/close() and the like (which will use read()/write()-family APIs underneath; the initial RPC connection to the process server will be permanently open but it will be possible to create new connections to manipulate the environment of child processes before starting them, so that fork() doesn't have to be a primitive anymore). AFAIK, little actually depends on those rather broken "close one FD and release all locks on that file" semantics, so UX/RT will implement more sane locking semantics by default. There will be a flag to revert to the traditional semantics (probably just implemented at the library level) in case anything actually depends on them. The directory contents that normal user programs actually see on UX/RT will be in a standardized format managed by the VFS (since support for a limited form of union mounts will be built in). I'm talking about implementing local filesystems in regular processes (rather than requiring them to be in the kernel) like in QNX or Plan 9, not about network filesystems (although of course network filesystem clients can be implemented on top of such an API). Linux has support for them through FUSE, but AFAIK it has performance issues and isn't very well integrated, so it isn't used all that much. When it comes to normal server processes, UX/RT will mostly depend on checking security on open() rather than on read()/write()-family APIs, which will limit the risk of TOCTTOU vulnerabilities. Where security does have to be checked on reads or writes (such as the ones underlying the RPC implementing open() itself), the data will be copied before checking. Using the traditional read()/write() instead of the new zero-copy equivalents should usually be good enough AFAIK, since they copy to a caller-provided buffer. I'm very well aware of that. UX/RT will implement most Linux APIs (either in libraries, servers, or combinations of the two) and will have a Linux binary compatibility layer. The only major incompatibilities are likely to be with stuff that manages sessions and logins (since UX/RT will natively have a mostly process-oriented security model, with no way to fully revert to traditional Unix security outside of running programs in fakeroot containers).