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

Matthew Maurer posted 1 patch 1 month ago
MAINTAINERS           |  1 +
rust/kernel/lib.rs    |  1 +
rust/kernel/random.rs | 21 +++++++++++++++++++++
3 files changed, 23 insertions(+)
[PATCH v5] rust: Add support for feeding entropy to randomness pool
Posted by Matthew Maurer 1 month ago
Adds just enough support to allow device drivers to feed entropy to the
central pool.

Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Matthew Maurer <mmaurer@google.com>
---
This adds bindings for `add_device_randomness` to enable the conversion
of `qcom-socinfo` to Rust [1].

I'm trying to land it separately because it's much simpler and likely
usable by others. The conversation around this code is also likely to be
very different than the conversation about the socinfo driver.

[1]: https://lore.kernel.org/all/20251213-qcom-socinfo-v1-1-5daa7f5f2a85@google.com/
---
Changes in v5:
- Add wrapper to the randomness driver MAINTAINERS section
- Replace detailed docs with an identical copy of the C code comment.
  (The short docs remain, and the C comment had the one function name
  linkified.)
- Link to v4: https://lore.kernel.org/r/20251230-add-entropy-v4-1-fa9485b6d372@google.com

Changes in v4:
- Adjusted documentation phrasing.
- Renamed module from `rand` to `random` to be more in line with the
  header name.
- Link to v3: https://lore.kernel.org/r/20251226-add-entropy-v3-1-a3440823a07d@google.com

Changes in v3:
- Fixed doclink to be srctree-based instead of relative.
- Switched to prelude import instead of fine-grained imports.
- Link to v2: https://lore.kernel.org/r/20251216-add-entropy-v2-1-4d866f251474@google.com

Changes in v2:
- Added more details in the docs about the API, specifically about it
  not crediting entropy and when it ought to be used.
- Link to v1: https://lore.kernel.org/r/20251212-add-entropy-v1-1-e70ad1bc9c65@google.com
---
 MAINTAINERS           |  1 +
 rust/kernel/lib.rs    |  1 +
 rust/kernel/random.rs | 21 +++++++++++++++++++++
 3 files changed, 23 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c5a7cda26c600e49c7ab0d547306d3281333f672..72b912c0bc068d2a304bc8eb1cd080ba9bcdd9c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21751,6 +21751,7 @@ F:	drivers/char/random.c
 F:	include/linux/random.h
 F:	include/uapi/linux/random.h
 F:	drivers/virt/vmgenid.c
+F:	rust/kernel/random.rs
 N:	^.*/vdso/[^/]*getrandom[^/]+$
 
 RAPIDIO SUBSYSTEM
diff --git a/rust/kernel/lib.rs b/rust/kernel/lib.rs
index f812cf12004286962985a068665443dc22c389a2..c82e6747043e2472d6b5e4d9043fa8bc6d3c8434 100644
--- a/rust/kernel/lib.rs
+++ b/rust/kernel/lib.rs
@@ -130,6 +130,7 @@
 pub mod ptr;
 #[cfg(CONFIG_RUST_PWM_ABSTRACTIONS)]
 pub mod pwm;
+pub mod random;
 pub mod rbtree;
 pub mod regulator;
 pub mod revocable;
diff --git a/rust/kernel/random.rs b/rust/kernel/random.rs
new file mode 100644
index 0000000000000000000000000000000000000000..3bffe07f5837fc5d9ff5b1959247d9028d45fd44
--- /dev/null
+++ b/rust/kernel/random.rs
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+
+//! Randomness.
+//!
+//! C header: [`include/linux/random.h`](srctree/include/linux/random.h)
+
+use crate::prelude::*;
+
+/// Adds the given buffer to the entropy pool, but does not credit any entropy.
+///
+/// [`add_device_randomness`] adds data to the input pool that
+/// is likely to differ between two devices (or possibly even per boot).
+/// This would be things like MAC addresses or serial numbers, or the
+/// read-out of the RTC. This does *not* credit any actual entropy to
+/// the pool, but it initializes the pool to different values for devices
+/// that might otherwise be identical and have very little entropy
+/// available to them (particularly common in the embedded world).
+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@google.com>
Re: [PATCH v5] rust: Add support for feeding entropy to randomness pool
Posted by Jason A. Donenfeld 2 weeks, 1 day ago
On Fri, Jan 02, 2026 at 06:50:16PM +0000, Matthew Maurer wrote:
> Adds just enough support to allow device drivers to feed entropy to the
> central pool.
> 
> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> Signed-off-by: Matthew Maurer <mmaurer@google.com>
> ---
> This adds bindings for `add_device_randomness` to enable the conversion
> of `qcom-socinfo` to Rust [1].
> 
> I'm trying to land it separately because it's much simpler and likely
> usable by others. The conversation around this code is also likely to be
> very different than the conversation about the socinfo driver.

Okay, I can take this. But I just wanted to confirm: is that RFC patch
definitely happening? Should I wait until there's a v1 or something?

Jason
Re: [PATCH v5] rust: Add support for feeding entropy to randomness pool
Posted by Matthew Maurer 2 weeks ago
On Thu, Jan 22, 2026 at 3:27 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Fri, Jan 02, 2026 at 06:50:16PM +0000, Matthew Maurer wrote:
> > Adds just enough support to allow device drivers to feed entropy to the
> > central pool.
> >
> > Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> > Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> > Signed-off-by: Matthew Maurer <mmaurer@google.com>
> > ---
> > This adds bindings for `add_device_randomness` to enable the conversion
> > of `qcom-socinfo` to Rust [1].
> >
> > I'm trying to land it separately because it's much simpler and likely
> > usable by others. The conversation around this code is also likely to be
> > very different than the conversation about the socinfo driver.
>
> Okay, I can take this. But I just wanted to confirm: is that RFC patch
> definitely happening? Should I wait until there's a v1 or something?

I can promise that the patch will be updated (I have a significantly
changed draft locally), but it will still be up to the maintainer
whether it actually lands.

>
> Jason