linux-kernel - Re: [PATCH v2 1/7] rust: build_assert: add instructions for use with function arguments

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] [day] [month] [year] [list]

Message-ID: <CANiq72kAnY2035vc2vvXDpUV-_vM=0W2_-mBts846jHo1ri3Yw@mail.gmail.com>
Date: Mon, 1 Dec 2025 17:43:35 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: John Hubbard <jhubbard@...dia.com>
Cc: Alexandre Courbot <acourbot@...dia.com>, Danilo Krummrich <dakr@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Daniel Almeida <daniel.almeida@...labora.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Viresh Kumar <viresh.kumar@...aro.org>, Will Deacon <will@...nel.org>, 
	Peter Zijlstra <peterz@...radead.org>, Mark Rutland <mark.rutland@....com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 1/7] rust: build_assert: add instructions for use with
 function arguments

On Mon, Dec 1, 2025 at 5:36 AM John Hubbard <jhubbard@...dia.com> wrote:
>
> This seems strange: something called build_assert!() should not be
> put in places where it might not be possible to verify at build-time.
> It's built right into the name.

The build prefix means the assert is done at build time, not that it
can always be verified. Even other asserts could also "fail" in a
certain sense (diverging, conditional compilation...).

Detecting "unreasonable" uses that are likely to fail would be nice, of course.

> So now we have to go around and annotate the functions that *contain*
> uses of build_assert!().

Only for those that need it.

> Otherwise we end up with an unreliable tool
> chain for developers. This is not where we should want to be, in the
> long run.

It is not a black or white issue. Conditional compilation also breaks
if someone misuses it, and that alone doesn't mean we stop using it.
It is a tradeoff at the end of the day.

Nevertheless, also note that the C side also relies on optimizations.

> Is there proc macro magic we can come up with? Or rustc or clippy
> changes? So that this is becomes a better foundation upon which to
> build?

Converting more code to macros has their own set of tradeoffs, but it
depends on what you mean. Do you have something in mind?

And yes, I have had it in our usual lists for a long time and we
mentioned it to upstream Rust and so on. We are well aware that
`build_assert!` isn't ideal, and in many cases it is best to avoid it
when there is a better approach.

Now, if a company has the means to improve the situation, e.g. by
sponsoring someone upstream to work on features like this, then by all
means, please go ahead! That would be very welcome, and we have some
contacts that could be interested in working on things like that, so
please feel free to ping.

Cheers,
Miguel