linux-kernel - Re: C aggregate passing (Rust kernel policy)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250226230816.2c7bbc16@pumpkin>
Date: Wed, 26 Feb 2025 23:08:16 +0000
From: David Laight <david.laight.linux@...il.com>
To: Ralf Jung <post@...fj.de>
Cc: Ventura Jack <venturajack85@...il.com>, Kent Overstreet
 <kent.overstreet@...ux.dev>, Miguel Ojeda
 <miguel.ojeda.sandonis@...il.com>, Gary Guo <gary@...yguo.net>,
 torvalds@...ux-foundation.org, airlied@...il.com, boqun.feng@...il.com,
 ej@...i.de, gregkh@...uxfoundation.org, hch@...radead.org, hpa@...or.com,
 ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org
Subject: Re: C aggregate passing (Rust kernel policy)

On Wed, 26 Feb 2025 23:28:20 +0100
Ralf Jung <post@...fj.de> wrote:

...
> > Unions in C, C++ and Rust (not Rust "enum"/tagged union) are
> > generally sharp. In Rust, it requires unsafe Rust to read from
> > a union.  
> 
> Definitely sharp. At least in Rust we have a very clear specification though, 
> since we do allow arbitrary type punning -- you "just" reinterpret whatever 
> bytes are stored in the union, at whatever type you are reading things. There is 
> also no "active variant" or anything like that, you can use any variant at any 
> time, as long as the bytes are "valid" for the variant you are using. (So for 
> instance if you are trying to read a value 0x03 at type `bool`, that is UB.)

That is actually a big f***ing problem.
The language has to define the exact behaviour when 'bool' doesn't contain
0 or 1.
Much the same as the function call interface defines whether it is the caller
or called code is responsible for masking the high bits of a register that
contains a 'char' type.

Now the answer could be that 'and' is (or may be) a bit-wise operation.
But that isn't UB, just an undefined/unexpected result.

I've actually no idea if/when current gcc 'sanitises' bool values.
A very old version used to generate really crap code (and I mean REALLY)
because it repeatedly sanitised the values.
But IMHO bool just shouldn't exist, it isn't a hardware type and is actually
expensive to get right.
If you use 'int' with zero meaning false there is pretty much no ambiguity.

	David