On 7/31/21, Gernot Heiser <[email protected]> wrote: > On 31 Jul 2021, at 20:20, Hugo V.C. <[email protected]> wrote: >> >> "Therefore the process server will be almost as important as the kernel >> when it comes to security" >> >> I'm not developer, so please excuse my ignorance in some topics (like OS >> dev), but, I've experience in exploiting OS stuff and I always prefer a >> ring 0 vuln than a ring 3 vuln... If the process server is implemented at >> user space (ring 3) then I don't get how we can compare security in so >> different cpu execution modes. Am I missing something? > > I agree. It seems that Andrew’s design looks pretty monolithic. >
It will be comparable to QNX in its degree of modularization. It will still have a multi-server architecture, but vertical modularity will be avoided for most subsystems. Each server process will normally contain the full stack of a subsystem instance; e.g. the process server will contain the memory/process manager and VFS (which will be very tightly integrated), the disk server will contain the disk device driver for a particular disk or HBA, partition table drivers, and disk filesystem drivers, and the network stack will contain the driver for a particular device and all protocols up to and including the transport layer. Basically all servers other than the process server will support multiple instances at least to some extent (servers with device drivers will typically be run as one process per device). In situations where separating the layers of a subsystem instance actually make sense, certain servers will optionally support it through stub drivers. IMO vertical modularity usually isn't worth it because protection domains tend to correspond to subsystems more often than they do to layers (e.g. the disk device driver, partition table driver, and disk filesystem driver usually all deal with the same data just at different levels and separating them into multiple processes will usually do nothing but add IPC overhead without any increase in security). On 7/31/21, Gernot Heiser <[email protected]> wrote: > On 1 Aug 2021, at 10:12, William ML Leslie <[email protected]> > wrote: >> >> Not if you don't have any capabilities mapped into the address space. > > Correct, which would be a reasonable design for a legacy subsystem, it > forces each syscall to raise an exception. Silly me for not pointing this > out in the first place. > That won't be an option on UX/RT. Its native environment will already be quite Linux-like and I want to treat Linux processes as native processes that have been loaded by an alternate binary loader and run in an alternate filesystem namespace with Linux libraries. With a system call handler that dynamically replaces Linux kernel traps with equivalent library functions that call native UX/RT APIs, performance should be equivalent to native processes or nearly so. _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
