Comment by nickpsecurity
10 years ago
Good to see one I've praised here before. Genode comes from the line of research that tries to reduce the Trusted Computing Base (i.e. attack surface) of systems by leveraging microkernels, better resource management, and better architecture. It came from this research [1] into real-time, secure GUI's, virtualization, and so on. The architecture itself is more than just a microkernel or virtualization scheme: it's structured in a hierarchical way that's supposed to support its security and reliability goals. Like with other things, I really want some smart researchers to give that architecture strong peer review and verification to test its claim before I trust it. However, the Nizza Security Architecture [2] it borrows from is based on solid, simple principles.
The best thing about GenodeOS is they learn from the past. Many mainstream approaches to INFOSEC seems like they've never heard of any prior R&D results. Some do, but this is the rule. For instance, the Rump kernels are similar to what OKL4 already did (and deployed) with their device driver reuse. QubesOS added their secure GUI scheme after I forwarded this team's work to them showing what's already been achieved in this space. Many are still building monolithic systems despite the fact that not a single one has ever shown to be remotely secure. And so on.
Unlike the rest, the Genode team seems to carefully watch the academic and industrial space to find any best-of-breed component to integrate into their system. They've attempted to use Nitpicker, NOVA, seL4, proven UNIX components, and so on. This attitude, along with tiny TCB, is why volunteers wanting to build secure, reliable systems should contribute to GenodeOS rather than most others. Done right, the component-based approach means your contributions might be easier to port to other projects (esp microkernels) as well.
For instance, the Rump kernels are similar to what OKL4 already did (and deployed) with their device driver reuse.
Reusable device driver frameworks are really old. There was DDE and NetDDE to run Linux 2.4 and 2.6 drivers, currently used by the GNU Hurd.
The good thing about rump kernels is that you're not just reusing device drivers, you're leveraging the whole NetBSD stack and with remarkable portability. They're also interchangeable between kernel and user contexts.
Rump kernels were the logical evolution of NetBSD's already top notch driver framework.
I do not know what OKL4 have done that is similar.
The point of rump kernels is not leveraging the whole stack from $OS. It's leveraging the unmodified drivers from $OS without the wholesale import of policies from $OS.
Sure, driver kits are an old idea, but starting from OSKit in the 90's the common fault is that the kits are forks over upstream. Forking is easy, but forking means that maintenance is unbearable unless you happen to be an organization with person-years to spare just to keep up with bugfixes and new features from upstream. Figuring out how to do it without forking (i.e. anykernel architecture which enables rump kernels out-of-the-box) takes more effort, but wins long-term. "proof": DDE is for Linux 2.4/2.6 drivers. NetBSD source tree from a second ago gives you rump kernels.
Exactly. It's an evolution of the old stuff and OSkit deserves credit too. Now, just imagine if the concept was discovered and built on sooner. Same with DDE. We'd have more projects doing more stuff. Took a while for one, bright outlier to make some of that potential happen. That's the problem I was illustrating. I like what's going on in Rump Kernel space, though.
8 replies →