Re: [RFC PATCH 1/5] doc: rust: create safety standard

Re: [RFC PATCH 1/5] doc: rust: create safety standard

[Boqun Feng]

Hi Benno,

On Wed, Jul 17, 2024 at 10:12:29PM +0000, Benno Lossin wrote:
[...]
> @@ -0,0 +1,246 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +.. highlight:: rust
> +
> +====================
> +Rust Safety Standard
> +====================
> +
> +Safe Rust code cannot have memory related bugs. This is a guarantee by the Rust compiler. Of course
> +it is not without caveats: no compiler bugs, no bugs in the specification etc. But the possibly most
> +important caveat is that of ``unsafe`` code. ``unsafe`` code needs to follow certain rules in order
> +for safe code to enjoy the no-memory-bugs privilege. A simple example of such a rule is that
> +references must be valid for the duration of their lifetime. If any rule is violated, it can lead
> +to undefined behavior even in safe code! The term undefined behavior in Rust has a lot stricter
> +meaning than in C or C++: UB in Rust is totally forbidden. In C one might rely on the compiler
> +implementation to ensure correct code generation, but that is not the case for Rust. You can read

I don't disagree with your intention here (i.e. we should seek for
UB-free program), however, during the discussion on memory model, I got
response like in [1]:

	... they are technically wrong (violating the C standard), but
	practically well-tested. (and then above I added that there's
	good reasons for why they don't go wrong: volatile compilation
	strategies and reordering constraints relating volatile, inline
	asm, and non-atomics make it so that this almost 'has to' work,
	I think.)

which suggests that we should rely on the compiler implementation to
ensure the "correct" code generation.

Basically, since LKMM relies on a few things that C standard dosen't
say, e.g. votatile accesses on certain types are atomic, behaviors of
asm blocks, dependencies. Let alone we have data_race() where for
example, the diagnostic code accesses the shared variable out of the
core synchronization design.

All of the above is difficult to implement purely UB-free in Rust IIUC.
Of course you could argue the ideal way is to teach Rust how to model
these useful operations/patterns as non-UBs, but that's a relatively
high task:

	Or do we want to go well beyond what happens in C, and actually
	define a memory model that both has the performance
	characteristics required by Linux, and can be defined precisely
	as a language-level graph-based (or ideally operational)
	concurrency memory model? This is a monumental task and a large
	open problem, and should not be on the list of blocking issues
	for anything that needs to get done in the next 5 years. ;)

from Ralf [2].

Again, I don't want to rely on compiler's behaviors on UBs, it's just
the langauge is not ready for some jobs and programmers have to be
"creative".

Regards,
Boqun

[1]: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/.E2.9C.94.20Rust.20and.20the.20Linux.20Kernel.20Memory.20Model/near/422193212	
[2]: https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1221376388

> +more about UB in Rust
> +`here <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>`_.
> +
[...]

Re: [RFC PATCH 1/5] doc: rust: create safety standard

[Benno Lossin]

On 20.07.24 00:11, Boqun Feng wrote:
> Hi Benno,
> 
> On Wed, Jul 17, 2024 at 10:12:29PM +0000, Benno Lossin wrote:
> [...]
>> @@ -0,0 +1,246 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +.. highlight:: rust
>> +
>> +====================
>> +Rust Safety Standard
>> +====================
>> +
>> +Safe Rust code cannot have memory related bugs. This is a guarantee by the Rust compiler. Of course
>> +it is not without caveats: no compiler bugs, no bugs in the specification etc. But the possibly most
>> +important caveat is that of ``unsafe`` code. ``unsafe`` code needs to follow certain rules in order
>> +for safe code to enjoy the no-memory-bugs privilege. A simple example of such a rule is that
>> +references must be valid for the duration of their lifetime. If any rule is violated, it can lead
>> +to undefined behavior even in safe code! The term undefined behavior in Rust has a lot stricter
>> +meaning than in C or C++: UB in Rust is totally forbidden. In C one might rely on the compiler
>> +implementation to ensure correct code generation, but that is not the case for Rust. You can read
> 
> I don't disagree with your intention here (i.e. we should seek for
> UB-free program), however, during the discussion on memory model, I got
> response like in [1]:
> 
> 	... they are technically wrong (violating the C standard), but
> 	practically well-tested. (and then above I added that there's
> 	good reasons for why they don't go wrong: volatile compilation
> 	strategies and reordering constraints relating volatile, inline
> 	asm, and non-atomics make it so that this almost 'has to' work,
> 	I think.)
> 
> which suggests that we should rely on the compiler implementation to
> ensure the "correct" code generation.

I disagree, why can't we get the specification to specify what we need?
I would rather have a compiler and standard that are in sync and give us
what we need, than have a standard that says we aren't allowed to do X,
but compilers still allow you to do X. I don't understand why this is
the case for C (I would bet this is is because of history/legacy).

> Basically, since LKMM relies on a few things that C standard dosen't
> say, e.g. votatile accesses on certain types are atomic, behaviors of
> asm blocks, dependencies. Let alone we have data_race() where for
> example, the diagnostic code accesses the shared variable out of the
> core synchronization design.
> 
> All of the above is difficult to implement purely UB-free in Rust IIUC.
> Of course you could argue the ideal way is to teach Rust how to model
> these useful operations/patterns as non-UBs, but that's a relatively
> high task:
> 
> 	Or do we want to go well beyond what happens in C, and actually
> 	define a memory model that both has the performance
> 	characteristics required by Linux, and can be defined precisely
> 	as a language-level graph-based (or ideally operational)
> 	concurrency memory model? This is a monumental task and a large
> 	open problem, and should not be on the list of blocking issues
> 	for anything that needs to get done in the next 5 years. ;)
> 
> from Ralf [2].
> 
> Again, I don't want to rely on compiler's behaviors on UBs, it's just
> the langauge is not ready for some jobs and programmers have to be
> "creative".

I think this is something that we need to very carefully evaluate on a
case-by-case basis. I think that with Rust we have a clean slate and can
try from the beginning to ensure that there is no
compiler-but-not-specification behavior that we rely upon. AFAIK the
Rust standard moves quicker than the C standard, so we might be able to
influence it more easily.

So what I am trying to say is: let UB be an actually useful term of
forbidden behavior. If you want to convince me otherwise, I think we
should talk specifics and not in this general way, since "sometimes UB
is actually ok" is something that I don't want to accept in Rust as a
general statement. If we have an exception, it should have a damn good
reason to be an exception and then still I don't like it one bit. Can't
we just ask the Rust folks to implement some compiler magic for us that
achieves what we need without relying one some weird compiler quirk?

---
Cheers,
Benno

> Regards,
> Boqun
> 
> [1]: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-opsem/topic/.E2.9C.94.20Rust.20and.20the.20Linux.20Kernel.20Memory.20Model/near/422193212
> [2]: https://github.com/rust-lang/unsafe-code-guidelines/issues/348#issuecomment-1221376388
> 
>> +more about UB in Rust
>> +`here <https://doc.rust-lang.org/reference/behavior-considered-undefined.html>`_.
>> +
> [...]