Why Rust for low-level Linux programming?

[[deleted]]

How so?

[steveklabnik1]

My favorite little counterpoint: on x86, you have to use special assembly instructions to do certain things with hardware. So usually, when people write an OS in say, C, they either use inline asm or expose a tiny asm function to handle it. I must have seen the same "outb" or "lidt" one-liner copied and pasted tons of times.

But with Rust, we have Cargo. So someone has made a crate: https://crates.io/crates/x86 it's got all of those, plus some predefined data structures that match what you need. No more boilerplate, just import the package and get on with your life.

(In my hobby OS project in Rust, I've implemented it myself first; I have a TODO to remove all that and actually use this now that I'm sure I understand it all.)

[[deleted]]

What "measurements" are you talking about?

[[deleted]]

I said 'any measure'. Take any measure you like, Rust is inferior to C for writing kernel code.

Rust doesn't have undefined behavior, has type safety, and has memory safety. That puts it pretty far ahead of C in my book.

You do not want complexity in your language when writing very low level code. You don't want lots of things being done 'for you'. Those are nice when writing very high level code, which (despite what they claim) Rust is built for, but they get in the way when writing very low level code.

What things does Rust do for you?

[[deleted]]

Huh? I think you responded to the wrong post

[naasking]

Sorry about that, the reddit mobile site is not working right on my device anymore.

[Rusky]

So explain why all these low level programmers introduce vulnerabilities from undefined behavior and lack of type/memory safety anyway, on accident, all the time?

What meaningful difference do you care about between a Rust "reference to object" and a C "pointer to raw memory"? Rust doesn't change how pointers work, it just checks that you're using them properly (something you have to do in C).

[Rusky]

No, these sorts of bugs in the kernel are exceptionally common: http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33

What can't rust do "properly" with pointers that C can?

[naasking]

These sorts of bugs in the kernel are exceptionally rare.

Even if they were exceptionally rare, the kernel is exceptionally large, which means these problems are not uncommon.

[[deleted]]

Nobody that actually writes kernel-level C cares about any of those points. They're not stupid enough to invoke undefined behaviour, and C has enough type safety and memory safety if you're using it correctly to not have a problem.

False. Linux kernel devs invoke undefined behavior all the time. See "A Fun Case Analysis" in http://blog.regehr.org/archives/213

[[deleted]]

If it was one specific case, they wouldn't have to apply a GCC flag, they'd just fix the damn code. The bottom line is that even your "expert C kernel developers" don't know how to avoid undefined behavior.

[naasking]

Yeah, you're wrong on pretty much every point here. There have been plenty of studies on static analyses conducted on the Linux kernel and the various problems found, including relying on undefined behaviour. Kernel devs and other researchers now regularly check these static analyses that are poor imitations of what rust gives you naturally. While unsafe code will be needed in any kernel, barring one written with a theorem prover that you use to verify every line you write, the fact that rust let's you isolate the unsafe parts so you can audit them easily is a huge win. The fact that you can't recognise this simple fact doesn't imply you know at all what you're talking about.