this post was submitted on 08 Apr 2024
22 points (66.7% liked)
Privacy
32120 readers
370 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As I understand it, a crude way to specify a micro kernel might be to call it a specialised slice of a monolithic kernel. It's still a kernel, and it being more/less efficient, have better security etc depends on the code itself rather than something external.
Understandably, I understand that the motivation comes from a combination of embedded projects: I remember that Minix is still a good example of a micro-kernel albeit being extremely vulnerable and buggy. Microkernels are nice, but I suppose one should look for a compromise when thinking of an OS based on Linux which runs around the world, and having a specialised kernel might not be the best idea.
You've got a lot of it, yeah. A microkernel tends to try to implement the smallest amount of essential functionality needed. When used in a specialized environment, like embedded controllers (ex. ZMK firmware, which is built on the Zephyr Kernel), microkernels are great and can exhibit great performance and efficiency.
Once one starts trying to build a general-purpose OS with a microkernel, however, things deteriorate very quickly. Things that are essential for general-purpose computing usually do not make it into the scope of the microkernel's functionality. This means that anytime something as simple as opening a file is required, a lot more communication is needed between processes, increasing the number of times that calls need to cross between the kernel and user context boundary.
Every context change requires one or more operations and the isolation necessary to be secure, means that they microkernel has to act as a messenger any time that a subsystem needs to communicate with another. The total number of system calls grows at an exponential rate, killing performance and increasing the threat surface that an adversary can target (individual components even end up needing greater awareness of security because there are now a lot more potential "weak links" in the data transmission chain).
That's why a suitable middle-of-the-road approach seems to be statically compiling one's kernel with the least amount of add-ons (drivers - that's what most of the kernel is anyway) possible. I see it as a decent idea but annoying in practice since bigger updates mean either a script/manual intervention every time, and I like Debian so you can see how I perceive that.
Exactly. And it also introduces limitations, should your system usage exceed the bounds expected and established when compiling. Like so many other things, context matters.
And now we've come a full circle. Microkernels are better because they have less code, but to make them usable across various systems you'd need to add more code. And after a point it'll stop being a micro kernel.