I've read a little about Genode before, so I am familiar with the name. But I have to admit that I have no clue what this project is trying to achieve (or has achieved already).
Could someone explain to me in not-overly-complicated terms what this project is all about? What is an "operating system framework" supposed to be?
(EDIT: I found the "about" link on their home page! :) Consider my question answered! This sounds like a very interesting interesting project.)
By "framework" they largely mean you have a choice of microkernel, with support for several microkernels of the L4 family (most recently initial support for SEL4).
They also have virtualisation support, so you can run Linux applications, and impressively secure desktop support.
See the publications (esp older) section of my comment above. Not just a microkernel, it's a specific way to structure a system that was developed via German R&D and reuses other developments there + abroad. The papers are very clear on details you're probably looking for.
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.
Unikernels and MirageOS are a step up (or in same direction) from this work, actually. ;) Unikernels are similar to L4 community's device-driver reuse but often have a larger TCB from my reading. (Not an expert on unikernels, to be clear!) MirageOS combines virtualization-based security with language-based protections and good build tools to aim at more secure, special-purpose deployments. The two are similar. The Nizza Security Architecture and Genode Architecture have each been able to do this with more efficiency and smaller TCB (attack surface). MirageOS's use of language security is a differentiator that's orthogonal to other aspects. I've encouraged such things in Genode, etc albeit with safer, low-level languages and static/dynamic analysis.
EDIT to Add: Just remembered that MILS separation kernel vendors (eg INTEGRITY-178B) have been doing this for over a decade with combinations such as sep kernel, Ada runtime for critical stuff, and user-mode VM's for legacy stuff. Long proven approach that mainstream is just catching up to.
I suspect you'd run unikernels under Geode. Instead of targeting Xen resources and Xen event/message channels and Xen security modules/FLASK, MirageOS would target Geode instead but perhaps have slightly higher-level resources and better-featured interfaces to lean on.
But I haven't quite had time to figure it out myself yet; I've been interested in exploring Geode for a while.
Exactly. The question is how mature they are and what you're implementation language would be. The MILS security people have been doing this for over a decade with the effective approach of combining separation kernels, user-mode OS's for GUI/legacy, and critical stuff running right on the kernel. Relative to MirageOS, several vendors developed special runtimes for Ada and Java to leverage their safety properties without the complexity of a standard runtime.
So, it's a proven approach that could be implemented in GenodeOS and probably easier given others were bare-bones.
It's been proven in practice for reliability and security in embedded space. They just called them Ada/Java "runtimes in dedicated partitions on microkernels." :) I always say that when mainstream starts to converge on what top engineers have been doing, then it's a good bandwagon to jump on. ;)
I've read a little about Genode before, so I am familiar with the name. But I have to admit that I have no clue what this project is trying to achieve (or has achieved already).
Could someone explain to me in not-overly-complicated terms what this project is all about? What is an "operating system framework" supposed to be?
(EDIT: I found the "about" link on their home page! :) Consider my question answered! This sounds like a very interesting interesting project.)
By "framework" they largely mean you have a choice of microkernel, with support for several microkernels of the L4 family (most recently initial support for SEL4).
They also have virtualisation support, so you can run Linux applications, and impressively secure desktop support.
Here is a video overview [1]
[1] https://www.youtube.com/watch?v=Nr2h9eigpqA&feature=youtu.be...
See the publications (esp older) section of my comment above. Not just a microkernel, it's a specific way to structure a system that was developed via German R&D and reuses other developments there + abroad. The papers are very clear on details you're probably looking for.
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.
[1] http://genode.org/about/publications
[2] http://genode-labs.com/publications/nizza-2005.pdf
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.
9 replies →
Is this a complete step-up from unikernel-based OSs such as MirageOS or could it also use unikernels for improved security?
Unikernels and MirageOS are a step up (or in same direction) from this work, actually. ;) Unikernels are similar to L4 community's device-driver reuse but often have a larger TCB from my reading. (Not an expert on unikernels, to be clear!) MirageOS combines virtualization-based security with language-based protections and good build tools to aim at more secure, special-purpose deployments. The two are similar. The Nizza Security Architecture and Genode Architecture have each been able to do this with more efficiency and smaller TCB (attack surface). MirageOS's use of language security is a differentiator that's orthogonal to other aspects. I've encouraged such things in Genode, etc albeit with safer, low-level languages and static/dynamic analysis.
EDIT to Add: Just remembered that MILS separation kernel vendors (eg INTEGRITY-178B) have been doing this for over a decade with combinations such as sep kernel, Ada runtime for critical stuff, and user-mode VM's for legacy stuff. Long proven approach that mainstream is just catching up to.
I suspect you'd run unikernels under Geode. Instead of targeting Xen resources and Xen event/message channels and Xen security modules/FLASK, MirageOS would target Geode instead but perhaps have slightly higher-level resources and better-featured interfaces to lean on.
But I haven't quite had time to figure it out myself yet; I've been interested in exploring Geode for a while.
Exactly. The question is how mature they are and what you're implementation language would be. The MILS security people have been doing this for over a decade with the effective approach of combining separation kernels, user-mode OS's for GUI/legacy, and critical stuff running right on the kernel. Relative to MirageOS, several vendors developed special runtimes for Ada and Java to leverage their safety properties without the complexity of a standard runtime.
So, it's a proven approach that could be implemented in GenodeOS and probably easier given others were bare-bones.
Running unikernels on top of a microkernel OS makes a lot of sense.
You could also interconnect multiple unikernels via nanokernels running off picokernel cloud
1 reply →
It's been proven in practice for reliability and security in embedded space. They just called them Ada/Java "runtimes in dedicated partitions on microkernels." :) I always say that when mainstream starts to converge on what top engineers have been doing, then it's a good bandwagon to jump on. ;)