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: <bc969e02-6004-4216-be55-bdfc00e95702@ralfj.de>
Date: Fri, 28 Feb 2025 08:38:27 +0100
From: Ralf Jung <post@...fj.de>
To: Kent Overstreet <kent.overstreet@...ux.dev>,
 David Laight <david.laight.linux@...il.com>
Cc: Ventura Jack <venturajack85@...il.com>,
 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)

Hi,

>>> It's also less important to avoid ever breaking working code than it was
>>> 20 years ago: more of the code we care about is open source, everyone is
>>> using source control, and with so much code on crates.io it's now
>>> possible to check what the potential impact would be.
>>
>> Do you really want to change something that would break the linux kernel?
>> Even a compile-time breakage would be a PITA.
>> And the kernel is small by comparison with some other projects.
>>
>> Look at all the problems because python-3 was incompatible with python-2.
>> You have to maintain compatibility.
> 
> Those were big breaks.
> 
> In rust there's only ever little, teeny tiny breaks to address soundness
> issues, and they've been pretty small and localized.
> 
> If it did ever came up the kernel would be patched to fix in advance
> whatever behaviour the compiler is being changed to fix (and that'd get
> backported to stable trees as well, if necessary).

We actually had just such a case this month: the way the kernel disabled FP 
support on aarch64 turned out to be a possible source of soundness issues, so 
rustc started warning about that. Before this warning even hit stable Rust, 
there's already a patch in the kernel to disable FP support in a less 
problematic way (thus avoiding the warning), and this has been backported.
<https://lore.kernel.org/lkml/20250210163732.281786-1-ojeda@kernel.org/>

We'll wait at least a few more months before we turn this warning into a hard error.

> It's not likely to ever come up since we're not using stdlib, and they
> won't want to break behaviour for us if at all possible.

Note however that the kernel does use some unstable features, so the risk of 
breakage is higher than for typical stable Rust code. That said, you all get 
special treatment in our CI, and the Rust for Linux maintainers are in good 
contact with the Rust project, so we'll know about the breakage in advance and 
can prepare the kernel sources for whatever changes in rustc are coming.
Hopefully the number of nightly features used in the kernel can slowly be 
reduced to 0 and then this will be much less of a concern. :)

Kind regards,
Ralf