[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aVD0qcGEaiTZYheF@fedora-g16.bne-home.net>
Date: Sun, 28 Dec 2025 19:13:13 +1000
From: Brendan Shephard <bshephar@...-home.net>
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
Subject: Re: [PATCH v3] rust: Add support for feeding entropy to randomness
pool
On Fri, Dec 26, 2025 at 07:15:10PM +0000, Matthew Maurer wrote:
> +/// Adds the given buffer to the entropy pool, but does not credit any entropy.
> +///
> +/// This is intended for use mixing in data that is likely to differ between devices or boots, but
Yeah, I agree with Alexandre here. I think this would probably be better
written as: "This function mixes in data that is likely to differ between
devices or boots". Or, "add_device_randomness mixes in data that is
likely to differ between devices or boots." If you would prefer to avoid
saying "this function".
> +/// may otherwise be predictable. Examples include MAC addresses or RTC values. This slightly
> +/// improves randomness in entropy-constrained environments (especially common for embedded
> +/// devices).
> +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()) };
> +}
>
> ---
> base-commit: 008d3547aae5bc86fac3eda317489169c3fda112
> change-id: 20251029-add-entropy-f57e12ebe110
>
> Best regards,
> --
> Matthew Maurer <mmaurer@...gle.com>
>
>
Powered by blists - more mailing lists