3 ms·

You are mostly right, but > There's no particular reason that segmented stacks (like old Go or old Rust had) couldn't be used in the kernel. A very good reaso

by qb45 10y ago

You are mostly right, but > There's no particular reason that segmented stacks (like old Go or old Rust had) couldn't be used in the kernel. A very good reason is that Linux happens to be written in C, which just doesn't support this. So the patch you linked uses VM mappings instead. > What is easier (as I advocated in another comment) is to keep the monolithic kernel model, but pretend that privsep within a single kernel doesn't happen, and run it all within VMs. That's the exokernel model, with hypervisor being the kernel and Linux being a private "libOS" of your httpd or whatever.

geofft 10y ago
> A very good reason is that Linux happens to be written in C, which just doesn't support this. This is a tangent, but I thought that C supported this just fine as long as there was compiler and runtime support? The compiler needs to insert a check at each stack allocation (beginning of each function, or each call to alloca or equivalent), and if it switches your stack pointer, it needs a trampoline as the last frame on the new stack, to un-switch the stack pointer. And you need to teach everything that traces stacks how to keep tracing across segments. But it doesn't seem impossible. GCC and LLVM seem to have support that doesn't care what language you're using: https://gcc.gnu.org/wiki/SplitStacks https://gcc.gnu.org/wiki/SplitStacks http://llvm.org/releases/3.0/docs/SegmentedStacks.html http://llvm.org/releases/3.0/docs/SegmentedStacks.html
- qb45 10y ago
  Fair enough. I wasn't aware that GCC actually supports this in C.