undefined | Better HN

0 pointsthrow109203y ago0 comments

> I'd argue that this would be a bigger architectural revolution than porting the existing code and running it in user-land. MINIX3 went through such a change

MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning.

It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language.

> Rust code can still be vulnerable in many other ways

Sure, but not vulnerable in the way that the vulnerability under discussion is.

> memory leaks

Much harder in Rust than C, and also unlike in C, not going to result in security vulnerabilities.

> buggy/compromised toolchains

If you're going to assume that your toolchain is compromised, than anything is on the table, including the toolchain inserting a backdoor into the kernel and completely bypassing the proposed architectural change of moving drivers into user-space. And, needless to say, compiler bugs are rare in general, and compiler bugs that cause software vulnerabilities are nearly unheard of (and I've literally never seen one before).

Nobody thinking rationally is going to tell you that Rust is going to eliminate all your bugs or make your code secure. However, by far, the majority of security bugs in the Linux kernel are due to mistakes that the design of Rust either completely eliminates or massively reduces.

And security is intrinsically a tradeoff - the Linux kernel is not optimized for maximum security (which would be something formally-verified like seL4), but a compromise between security, performance, and development velocity. The claim is that Rust will provide significantly better security at basically the same performance and possibly modestly improved development velocity - the very least that one should do is rewrite the existing architecture in it (or, again, a language that meets or exceeds the specs of Rust) and then see what the bug rate is before deciding to take a guaranteed performance hit through an architectural change.

0 comments

boricj3y ago

> MINIX is a microkernel architecture - running drivers in userspace is one of its core features/selling points, and one that differentiates it from (modular) monolithic kernels such as Linux. So, this isn't a very solid line of reasoning.

The first two versions of MINIX ran drivers inside the context of the kernel. The migration of drivers to user-space and overall emphasis on reliability didn't happen before MINIX3 in 2006.

Given that Linux nowadays has FUSE and UIO, still calling it a strictly monolithic kernel is probably a bit of a misnomer at this point. The same goes for Windows, NetBSD and others by the way.

> It seems to me that the situation is the opposite - that moving drivers to userspace is an architectural change, which is more complex than porting an existing architecture to a new language.

Trying to do a straightforward port of a C code base to Rust will quickly grind to a halt due to Rust's borrow checker. On a highly-optimized code base such as the Linux network stack, untangling every last optimization trick and shortcut to make the Rust compiler happy would require a large-scale refactoring that'll end up looking nothing like the original code base, at which point you might as well rewrite it from scratch.

In comparison, migrating that C code base to user-land would be less of a disruptive change to the code base (as was the case when MINIX3 did so with its drivers). It's still the same old network stack, adapted to run on a different environment.

> Sure, but not vulnerable in the way that the vulnerability under discussion is.

Rust isn't a silver bullet against every class of bug. Code that runs inside the trusted computing base means that it's one security bug away from system compromise. Writing that code in Rust doesn't change that.

j / k navigate · click thread line to collapse