5 ms·
I have been noticing recently people experimenting with things like WASM kernel modules, and even having the kernel itself (or maybe it was a supporting root-ow
by jeffparsons 5y ago
I have been noticing recently people experimenting with things like WASM kernel modules, and even having the kernel itself (or maybe it was a supporting root-owned process?) compile Rust code in a way that validates it doesn't do any dodgy and then loading the result into the kernel. It makes me wonder whether there might be a way to achieve many of the benefits of microkernels without the inefficiencies and complexity ("everything is now a distributed system") that has held them back in the real world. It sounds like Singularity was pushing in this direction, so maybe I should pay more attention to its spiritual successor Midori.
I also wonder whether there's anything stopping _Linux_ slowly becoming something more like this over time by supporting kernel modules that have direct but _limited_ access to talk to each other in more ways that can be verified at load time. In theory even some kinds of "arbitrary shared memory" patterns could work just fine, and get you pretty close to the best of both worlds even with supporting "binary blob" drivers etc. Instead of requiring modules to be compiled to a special kind of bytecode (which would require compiler support), maybe you could even create some special conventions for how memory is accessed by these sandboxed kernel modules (fake syscalls or something?) that let them be rewritten at load time.
I guess it boils down to: how much could you statically verify the behavior of a kernel module without preventing from having the flexibility to do what it needs to do?
- WastingMyTime89 5y ago> I also wonder whether there's anything stopping _Linux_ slowly becoming something more like this over time by supporting kernel modules that have direct but _limited_ access to talk to each other in more ways that can be verified at load time. You are more or less describing eBPF and the evolution you are wondering about has indeed started slowly happening for some years now. It does however use special bytecode but getting compiler support is not such a hard problem compared to building the safe VM.
- geon 5y agoSounds a bit like Google’s Native Client, which was kind of superseded by wasm. https://en.m.wikipedia.org/wiki/Google_Native_Client https://en.m.wikipedia.org/wiki/Google_Native_Client
- pjmlp 5y agoSearch for OS/400 language environments and TIMI.
- Aloha 5y agoI've long believed that OS/400 is a path not taken in systems programming, one that would have been much more influential had it happened outside of IBM.
- rincebrain 5y agoIt's rumored that Midori was built on Singularity, so it's much more than a "spiritual" successor if that's the case. (Also sadly discontinued as well.)
- pacaro 5y agoTo my understanding, Midori evolved out of Singularity
- rincebrain 5y agoSure, my remark was more intended to convey that I usually expect the phrase "spiritual successor" to be used for something where there's no direct shared ancestry/code between two projects other than "hey, you had some good ideas", which I would be astonished if were the case here.
- pacaro 5y agoI couldn't tell you how much of Singularity remained in Midori, but to give some context, this was a team that was not afraid to rewrite, often significantly, there was essentially a closed environment, so you could make what would be a breaking change in any other environment, and be sure that everything still built and ran. Example: I completely rewrote the process loader to load binaries from "the cloud" and other than a heisenbug caused by a misconfigured F5 router that had us scratching our heads for a couple of months, everything just kept working
- rincebrain 5y agoI mean, that's one way to handle package management. Wow. It's a shame that it's not going to see the light of day, it sounds like it'd be invaluable to see the decisions and mistakes made.