Insulating layer?

Posted Oct 15, 2024 10:42 UTC (Tue) by khim (subscriber, #9252)
In reply to: Insulating layer? by Wol
Parent article: On Rust in enterprise kernels

> You seem to be advocating that Rust behave like C(++) and just ignore it. Sorry if I've got that wrong.

I'm not “advocating” anything, I'm just explaining how things work. Not how they “should work”. But how they, inevitably, have to work (and thus how they actually work). If out of ten choices that one like or dislike only one is actually implementable then you are getting that one whether you like it or not.

> My understanding of the ethos of Rust is that if the compiler doesn't understand what you mean it's either unsafe, or an error.

We are talking the full Rust, not just “safe” Rust here. UB is UB, whether it's in safe code or unsafe code. And yes, you can trigger UB in safe Rust – and it would lead to the exact same outcome as in unsafe Rust.

> If a programmer accesses an uninitialised variable there's a whole bunch of reasons why they might have done it.

If programmer accesses an uninitialized variable without the use of special construct that is allowed to touch undef, then it's a bug. Period, end of story. If program includes such access then it have to be fixed, there are no any other sensible choice.

The only difference of safe Rust and unsafe Rust is decision of whose responsibility is it to fix such bug. If it's “safe” Rust then it's bug in the compiler (currently there are around 100 such bugs) and compiler developers have to fix it, if it's in unsafe Rust, then developer have to fix it.

Compiler may include warning for [potential] bugs in unsafe Rust, but ultimately it's resposibility of developer to fix them.

> Imho (in this particular case) Rust should come back at the programmer (like any sensible human being)

Impossible. Compilers are mindless (they literally have no mind and couldn't have it) and not sensible (they don't have “a common sense” and attempts to add it inevitable lead to even worse outcome). That's something “we code for the hardware” people simply just refuse to accept for some unfathomable reason.

> (1) you expect the data to come from somewhere the compiler doesn't know about

In that case you have to use volatile read or volatile write.

> (2) you forgot to explicitly request all variables are zeroed on declaration / read-before-write

This is bug and it should be fixed. If you managed to do that in normal, “safe” Rust then it's bug in the compiler and it have to be fixed in compiler, if you did that in unsafe Rust, then it's bug in your code and you have to fix it.

> (3) you're expecting random garbage.

Currently that's also a bug, although there are discussions about adding such capability to the language (to permit tricks like the one used in the Using Uninitialized Memory for Fun and Profit. Currently Rust's only offer for such access is the use of asm!.

> And if they don't, it won't compile.

Not possible, sorry. If you wrote the magic unsafe keyword then it's your responsibility to deal with UB now.

Compiler may still detect and report suspicious findings, but it couldn't be sure that it detected everything correctly thus such thing couldn't be a compile-time error, only and compile-time warning.