Hacker News Reader

> 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

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

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.

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.

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.

> 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.

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/

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.

> 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?