You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's an open issue about no_std support for getrandom in general, including various ways it could potentially be integrated into core instead of std:
Curious of anyone has thoughts on this for embedded device use cases. Since embedded-hal generally eschews global state for things like device peripherals, I'm wondering if the existing rand_core API may actually be a better fit.
One example from my backyard is entropy for encryption (TLS). While getrandom's source is OS, I wonder how reaching TRNG peripheral of some of MCU could work in such case? If I correctly understand proposal from rust-random/getrandom#4 it would require own implementation to let the further code use a standard API. That's definitely worth consideration.
One thing that works is instantiate some seedable RNG (like ChaChaRng) and either seed it with TRNG data when booting up or periodically feed it with some entry e.g. using an interrupt.
@therealprof My point was about finding good pattern how to use the peripheral by the abstraction layer, so the use of standardised functions would still work. I'm mostly thinking about portability of the code.
i ran into this recently and ended up with a bunch of mutex and rng_core faff to support global use of rand_core::Rng objects while supporting platform initialisation. Unsure how to manage periodic re-seeding atm but it's here if it's useful ryankurte/rust-rand-facade.
i also completely missed that getrandom has a feature for defining a global random function getrandom#109, which may have done the job, but isn't obvious from any documentation, so leaving that here in case anyone else runs into it.
Activity
michalfita commentedon Jul 10, 2019
One example from my backyard is entropy for encryption (TLS). While
getrandom's source is OS, I wonder how reaching TRNG peripheral of some of MCU could work in such case? If I correctly understand proposal from rust-random/getrandom#4 it would require own implementation to let the further code use a standard API. That's definitely worth consideration.therealprof commentedon Jul 10, 2019
One thing that works is instantiate some seedable RNG (like
ChaChaRng) and either seed it with TRNG data when booting up or periodically feed it with some entry e.g. using an interrupt.michalfita commentedon Jul 11, 2019
@therealprof TRNG in ATSAMS70Q21 is fast enough to use directly as source of random numbers, we drop the need for cycles to calculate any PRNG.
therealprof commentedon Jul 11, 2019
@michalfita So what prevents you from using that directly?
michalfita commentedon Jul 11, 2019
@therealprof My point was about finding good pattern how to use the peripheral by the abstraction layer, so the use of standardised functions would still work. I'm mostly thinking about portability of the code.
ryankurte commentedon Jul 13, 2020
i ran into this recently and ended up with a bunch of mutex and
rng_corefaff to support global use ofrand_core::Rngobjects while supporting platform initialisation. Unsure how to manage periodic re-seeding atm but it's here if it's useful ryankurte/rust-rand-facade.i also completely missed that
getrandomhas a feature for defining a global random function getrandom#109, which may have done the job, but isn't obvious from any documentation, so leaving that here in case anyone else runs into it.newpavlov commentedon Jul 13, 2020
@ryankurte
Note that this
getrandomfeature is part of the (currently unreleased) v0.2 and is not present in v0.1.jannic commentedon Jun 11, 2024
rust-lang/rust#62079 (comment) suggests closing the ticket for std.
For no_std applications, https://crates.io/crates/rand_core provides good support, and implementations can be provided by HALs.
So I think this ticket can be closed.
jamesmunns commentedon Jun 11, 2024
Agreeing with @jannic, and closing as part of the 2024 triage efforts.