linux-kernel - Re: [PATCH v4] rust: Add support for feeding entropy to randomness pool

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: <aVUbqo4wS7_47wmt@zx2c4.com>
Date: Wed, 31 Dec 2025 13:48:42 +0100
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Matthew Maurer <mmaurer@...gle.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, 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>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org,
	Alexandre Courbot <acourbot@...dia.com>, tytso@....edu
Subject: Re: [PATCH v4] rust: Add support for feeding entropy to randomness
 pool

Hi,

Thanks for CCing me Miguel. I find it strange that it was left out on
apparently 4 revisions of it. Yes, this should be added to the
MAINTAINER's normal rng section. I'm happy to maintain this.

However...

On Tue, Dec 30, 2025 at 05:53:57PM +0000, Matthew Maurer wrote:
> Adds just enough support to allow device drivers to feed entropy to the
> central pool.
> [...]
> +/// This function mixes in data that is likely to differ between devices or boots, but may
> +/// otherwise be predictable. Examples include MAC addresses or RTC values. This slightly improves
> +/// randomness in entropy-constrained environments (especially common for embedded devices).

Small nit: There are two existing comments in the C source (one of which
I know you know about because your text is almost that text). Why not
just use those verbatim? Or improve those and sync that to here? I'm not
a big fan of bifurcation.

> +pub fn add_device_randomness(buf: &[u8]) {
> +    // SAFETY: We just need the pointer to be valid for the length, which a slice provides.
> +    unsafe { bindings::add_device_randomness(buf.as_ptr().cast::<c_void>(), buf.len()) };
> +}

Bigger question, perhaps for Miguel: what's the convention for adding
these bindings? Is it, (A) "this is a useful API surface, so let's add the
functions so driver writers can use them later" or is it (B) "add useful
APIs as they're needed by driver writers"?

If (A), then why only add one single function from include/linux/random.h?
Shouldn't you add them all?

If (B), then shouldn't this patch be in a series alongside code that
actually calls this one function that is added? Usually the kernel
doesn't add code "just for the sake of it". APIs need in-tree users.

I think case (B) is closer to what I'm used to seeing, but Rust is a
brave new world so maybe (A) is desirable for bootstrapping it. However,
this patch accomplishes neither (A) nor (B).

Jason