MicroKernel Archetecture is the Future

[nurmagoz]

Sadly, there is no reliable or usable freedom operating system based on a microkernel design (yet). What we have are only monolithic ones, based on the Linux kernel.

Linux, by design, does not offer the same level of security as a microkernel. It is considered obsolete; nobody would want to build an operating system from scratch based on a monolithic design in nowadays.

Alternatives?

• seL4
• Redox
• Zircon

All mentioned are in active development and free software (sel4 is copyleft).

What i would avoid for sure is Zircon, because its google based.

What’s left are seL4 and Redox. Both are good, and if I had to choose one, I would choose seL4 due to its maturity. Also, the Redox team prefers to have a stupid software license, which is MIT. This is a non-copyleft license, which means all contributions to this project could be taken by a proprietary company and turned into a proprietary product (a waste of time and effort for the public).

Note (1): Minix and GNUmach are inactive/not much.
Note (2): Hybrid kernels are not an option like XNU or OpenHarmony .

Freedom OSs Based on MicroKernels

seL4

• Sculp OS (general-purpose OS, Built on Genode)

• Lions OS

Redox

• Redox OS

Competitors

Proprietary competitors are on the rise. HarmonyOS, for example, is arguably the most mature general-purpose microkernel-based OS developed in China. Google’s Fuchsia is another example. If we don’t stay ahead of these developments, control over security will slip from our hands, placing it instead in the hands of large corporations or state-backed entities.

Rustify the kernel

Its preferable to re-write the kernel into more modern and secure language like rust (the entire kernel is just 10k lines in case of seL4 which considered very minimal compared to linux)

[arraybolt3]

Could you elaborate on how this is particularly more secure than Qubes OS? I don’t think seL4 will be very suitable for this because of its likely very lacking hardware support (unless there’s an army of developers making networking and graphics drivers for seL4 that I don’t know about). Xen + a Linux dom0 seems like it probably gives similar levels of security to this.

Genode looks really cool, I didn’t know about it before. (Edit: Heh, looks like they’re using separate Linux VMs as both hardware and an application compatibility layers. Clever.)

[Patrick]

@nurmagoz

Competitors

Proprietary competitors are on the rise. HarmonyOS, for example, is arguably the most mature general-purpose microkernel-based OS developed in China. Google’s Fuchsia is another example. If we don’t stay ahead of these developments, control over security will slip from our hands, placing it instead in the hands of large corporations or state-backed entities.

answered here:

Proprietary tyrant competitors and project values

I am not worried about this. Related wiki chapter: Freedom vs Tyrant Security Hypothetical user quote: Due to lack of <insert cool security feature> by proprietary tyrant, I switched from Debian/Kicksecure to Google Android/iOS. That user doesn’t exist or is a minority infeasible to chase. In any case, we obviously cannot directly compete with proprietary tyrant companies with billions of USD in funding. That’s mission impossible. We can only compete on values. Such values include (no…

[nurmagoz]

@arraybolt3

Could you elaborate on how this is particularly more secure than Qubes OS?

Qubes is the closest design but it has its own drawbacks:

• Qubes is not App-per-VM design, rather OS-per-VM
• Qubes doesnt give the latest packages, Qubes relies on other OSs doing that, wether debian or fedora or…etc. So it doesnt solve the issue of anything related to packages issues (old, vulnerable…etc).
• Qubes doesnt solve packages compromising user level inside OS-per-VM, so if you have a malware in your VM or got infected package, your entire OS in the appVM will be infected (and if its from the repository, so as your templateVM).
• Qubes relies on merging two components which are not produced from the same developers, xen and linux, this can produce version conflicts or unwanted bugs, compared to seL4 or even qubes+kvm (even though kvm is worse than xen).
• Qubes is not immutable distro.
• Qubes doesnt support bootstrappable builds.
• Qubes has hands to modify the distros that they have from the main distro producer/owners. So debian package case for example will be X (package developer) -> Y (debian package maintainer/s) -> Q (qubes-debian maintainer/s) -> User.
• Qubes doesnt harden the connection or remove old stuff in the kernel or even harden the kernel itself.
• Qubes based itself on even deprecated versions of fedora, not even stable packages. Yes they upgrade xen,kernel and some other packages to mitigate some security issues or hardware compatibilities, but the concept itself is flawed.
• Qubes based on linux kernel, linux kernel is a mess and doesnt focus on security, and its insecure by design.

… etc. But what i give credit for qubes is that it contained the distros within VMs and made their packages/apps of these OSs to play with more easy with layer of security. Separation of hardware and user daily software with an offline layer. Yet there are many areas for improvements or maybe never going to be improved.

@arraybolt3

I don’t think seL4 will be very suitable for this because of its likely very lacking hardware support (unless there’s an army of developers making networking and graphics drivers for seL4 that I don’t know about).

Yeah this is hard problem, thats why i said if someone made it then this is like OS dropped from heaven.

[extraextra]

@nurmagoz

Qubes doesnt give the latest packages, Qubes relies on other OSs doing that, wether debian or fedora or…etc. So it doesnt solve the issue of anything related to packages issues (old, vulnerable…etc).

You just need to install a template that has the feature you’re looking for.

@nurmagoz

Qubes is not App-per-VM design, rather OS-per-VM

How you’re going to run an App inside a VM without an OS?

@nurmagoz

Qubes is not immutable distro.

Does it need to be?

@nurmagoz

Qubes doesnt support bootstrappable builds.

Good luck finding a usable distribution that is.

@nurmagoz

Qubes has hands to modify the distros that they have from the main distro producer/owners. So debian package case for example will be X (package developer) -> Y (debian package maintainer/s) -> Q (qubes-debian maintainer/s) -> User.

And how do you suppose to do that any other way without demanding the impossible that is a complete rewrite of everything?

@nurmagoz

Qubes doesnt harden the connection or remove old stuff in the kernel or even harden the kernel itself.

Use the Kicksecure template.

@nurmagoz

Qubes based itself on even deprecated versions of fedora, not even stable packages. Yes they upgrade xen,kernel and some other packages to mitigate some security issues or hardware compatibilities, but the concept itself is flawed.

Qubes argues it’s not part or the TCB. Can you show a vulnerability that affected the security of Qubes as a result of old dom0?

@nurmagoz

Yeah this is hard problem, thats why i said if someone made it then this is like OS dropped from heaven.

If you know it’s not realistic then why clogging up developer time with theoretical dreams from heaven?

[nurmagoz]

To not increase the subject into lengthy repetitive explanations, your questions are answered and can be found with search engine or AI or more reading.

[awr_d]

I just signed up to ask to actually reply for this.
I’ve been reading kicksecure forum and other related things for about half an hour now and none of these answers it.

I personally use Qubes, but I’m not an expert and I’m trying to dig as I can in order to understand the nature of the things as they are now, what is being done currently, what are the possibilities for the future development, and finally what is in my power to do right here and right now in order to harden as much as possible my setup/s.

I currently have Qubes and being not so much of an expert, couldn’t figure out microkernels and just left it for later, same with openBSD for sys-net, as there’s no drivers for my networking card there.
So I’m using Kicksecure for all of my templates(each per app whenever possible) and I try to, as I said earlier, mitigate what I can, but I still have high doubts my setup is secure.

I honestly don’t know neither of you, but you seem like some dudes who know stuff. I know Patrick from Qubes forum and I have huge respect for him for what he’s doing and how he does it.

[nurmagoz]

Im not sure whats your question/s specifically.

Nevertheless, qubes is good for now, qubes done pretty well in containing the operating systems (specially debian and fedora).

Futuristically this is not enough, it needs to be taken one step further, which is securing the packages within its own VMs. So instead of entire OS in a VM, it will be an app within a VM.

Full vision can be viewed here.

[extraextra]

@extraextra

@nurmagoz

Qubes based itself on even deprecated versions of fedora, not even stable packages. Yes they upgrade xen,kernel and some other packages to mitigate some security issues or hardware compatibilities, but the concept itself is flawed.

Qubes argues it’s not part or the TCB. Can you show a vulnerability that affected the security of Qubes as a result of old dom0?

@nurmagoz

To not increase the subject into lengthy repetitive explanations, your questions are answered and can be found with search engine or AI or more reading.

AI couldn’t show any issues other than xen or kernel. So the answer is old dom0 doesn’t affect the security of Qubes until evidence otherwise.

[nurmagoz]

@nurmagoz

but the concept itself is flawed.

Already explained, realistically can happen.

But this is an example anyway.