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

["Jason A. Donenfeld" <Jason@zx2c4.com>]

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