[martamoreno]

It's a fun idea and many people have had it first thing when they heard of Rust... So why did no one do it?

Quite simply: No one is going to rewrite the Linux Kernel in Rust. It is far too big and also you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust. Even for a browser, Rust is only a band-aid. The amount of logical errors and security holes in something as complex as a modern web-browser is more than enough of an attack surface. No need for a rouge pointer to weird memory.

What is MUCH more viable though is a project to compartmentalize the Linux Kernel into HVMs. I forgot the name but there are efforts to put nearly everything into its own HVM. Which means if the printer driver goes nuts, it can't really do anything to your system except not print anymore. If your graphics driver goes nuts, well then you won't see anything... And so on.

This means, almost no code rewrites and still MUCH higher protection than RUST. Rust does not compartmentalize. If any of your system components is fucked, your whole system is still fucked. That is why it's pointless to rewrite a kernel because of a language. You need to compartmentalize it...

Look at QubesOS for an early user-space effort. Would be nice to have a Qubes-Kernel too.

[vog]

> No one is going to rewrite the Linux Kernel in Rust. It is far too big ...

Please refrain from using strawman arguments. Nobody proposed to rewrite everything at once. This is what TFA actually wrote:

| So the idea would rather be to rewrite pieces of the Linux kernel in Rust, so the change can be incremental and one doesn’t need to rewrite the whole OS

See also: https://news.ycombinator.com/item?id=14479559

(It puzzles me what this strawman was good for, given that the remaining arguments are independent from the "too big" argument anyway.)

[i336_]

You're referring to microkernel/nanokernel architectures.

Linus famously shunned Andrew Tanenbaum's MINIX kernel design and argued in favor of a monolithic kernel, where buggy printer drivers live in the same memory space and have the same elevated privileges as the code that manages the kernel's secure crypto key ring.

Linus is also noted in this thread as not being interested in security issues.

I do agree with you about Rust not solving the hardware problem.

[martamoreno]

Yes it also makes sense. Because no matter what you do, it is unlikely that your are able to compartmentalize something so critical and raw as a device driver. If that one is fucked, the reason is likely that your system is already compromised. It was just an example of what WOULD be more viable and effective than rewriting it in Rust.

I still think that QubesOS is taking the right approach. Initially assume hardware & kernel as trusted and make sure that this trust then can not be violated from the outside (TPM, SecureBoot, VMs for each app, etc.). I just wish more people would focus on that promising approach.

[nine_k]

> able to compartmentalize something so critical and raw as a device driver.

QNX did this quite successfully; you could kill and reload e.g. a buggy network or disk driver. All that on top of being a realtime OS.

[i336_]

I agree.

Writing in Rust might make the iteration/development process itself a little easier, I'll give it that.

I also like the idea about creating a system that does its best to isolate components and create a trustworthy environment. I'd probably pull the enforcement into the kernel though - not quite SELinux/grsecurity/AppArmor, more a system that completely isolates everything.

Kind of like the direction Linux is going with containerization, but developed that way from the start.

[hatmatrix]

Isn't that what Redox-OS [1] does? Though it is not fully POSIX compliant for decisions the development team made.

[1] https://www.redox-os.org/

[youdontknowtho]

Once Rust has been available as the main attack surface in a browser for several rounds of "pwn-to-own" I think people will come to grips with it not being a magic bullet.

I think you are right about the Qubes approach. Microsoft has started adopting that model in Windows. They started by moving parts of LSASS to a compartmentalized trusted code base in a VM. (Credential Guard). I think the next thing is actually running Edge with some hypervisor protections. Can't remember the feature name, though.

But that kind of thing is the future. You have to assume that things will be breached and deal with that upfront.

[kqr]

> you are not solving any real issues either. Rust only protects you from a small fraction of errors and while for an application like a browser, this can be a big gain, I would argue that it is negligible for a kernel in general. Reasons being that all the device IO, component interaction, privilege escalations, logical errors, hardware errors, firmware errors/bugs all can NOT be addressed by rust.

Would something like Ada SPARK be more helpful here? And what critical parts of that is Rust missing?