Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

According to wikipedia, Xen and ESX are both considered microkernels.


I mean, Xen is literally descended from exokernels. The whole point of an exokernel is to securely multiplex hardware with as few abstractions as possible (which makes for a pretty sweet hypervisor it turns out). It's original paravirtualized MMU is straight out of XOK and AEGIS.

VMWare calls their system a microkernel (and so Wiki's rules therefore repeat that without other research), but the stack trace on the ESX wiki page pretty clearly shows a network card driver being called inside kernel context, so they have to be playing fast and loose with the term. From the outside it looks like earlier Vxworks; it's somehow a microkernel despite all of the code living in the same address space with no real permissions differences because it has multiple kernel threads and loadable modules. By that definition Linux is a microkernel too.


> I mean, Xen is literally descended from exokernels. The whole point of an exokernel is to securely multiplex hardware with as few abstractions as possible

Xen has far too much in-kernel code to be considered an exokernel. Linux on L4 had even less overhead than paravirtualized Xen. If exokernels truly efficiently multiplex the hardware in the most minimal manner possible, this wouldn't be possible.

I can't comment on VMware beyond published documents since I'm not as familiar with it.


Exokernels aren't necessarily ascetic like a microkernel.

And Linux on which L4?


VMWare ESXi relies on a guest to provide drivers. Seeing a network stack in kernel context makes sense given that the process handling the driver is a VM. The VM used to be Linux. I recall them being sued because someone thought that violated the GPL.


They wrote a compatibility layer and run modified Linux drivers inside their hypervisor. That's separate from the Linux kernel that they use to boot and subsequently manage the hypervisor.


Look at OKL4 or Nova microhypervisor for what a microkernel version of Xen would look like. Xen is relatively large with pile of monolithic code in dom0. Microkernel vendors, esp OK Labs, were poking at its huge TCB for a while.


Thanks for reminding about NOVA! I had totally forgotten about it. Doesn't seem to have much activity since 2010 though, unfortunately. I wonder why Google does't just build on L4 or something like Nova instead of starting from scratch. These systems are low-level and general enough to do what they want, possibly better than they could achieve themselves. L4-sec has had 2 decades of research put into it, 3 decades if you count is predecessor L3.


I said same thing. I went further to say they shouldve bought OK Labs to get one of best combos of team and tech. It already worked with Android, too.

Far as NOVA, here's the dissertation that goes into a lot more detail on design considerations than most of the whitepapers.

https://www.researchgate.net/publication/275031217_Improving...

Of course, the number of hardware and firmware type of attacks on mainstream platforms made NSA retire the SKPP for doing separation on them. Even a perfect hypervisor cant be trusted to maintain that when its dependencies are garbage. That was even noted in 1992-1993 papers on VAX Secure VMM. Even secure digital desigms might have analog or RF attacks.

So, the current recommendation is to build things that way just to reduce number of attacks with monitoring and recovery as usual. Those two, though, could run on simpler, verified platforms. There's a lot of precedent for such split architectures.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: