Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rng: Add prng, hwrng support #54

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Conversation

Remmirad
Copy link

@Remmirad Remmirad commented Mar 10, 2023

This is an idea to provide prngs seeded by RIOTs hwrng interface. This uses random as one prng.

In addition I implemented rand:RngCore and rand::SeedableRng with random to provide the rand::Rng interface to be usable here. Also a function is provided to seed an rand::StdRng (Seems not need std despite its name) with hwrng to have two different prngs at hand.

The rand part was mostly added because I like the interface of rand::Rng but it's just an idea and it definitely needs to be discussed if it is worth the extra dependencies. Or maybe should be behind a feature.

Structure looks like this:

  • hwrng.rs: Wrapper around hwrng interface
  • random.rs: Wrapper around random module + implementation of rand interfaces
  • prng.rs: User faced helper methods to create a prng via hwrng seeding

Edit: This needs a change in rust-riot-sys to create bindings to random (See RIOT-OS/rust-riot-sys#26)

Copy link
Member

@chrysn chrysn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't plowed through the random.rs yet, but do I get this right that while hwrng.rs and prng.rs's rand_prng already give the user all they need, the riot_prng (backed by random.rs) is "only" there to avoid pulling in code for StdRng in situations when RIOT's rng is either already there or for other reasons works better than the pure Rust version?

(The "only" is in quotes because these are legitimate reasons; I wonder though whether we should have unified API, and what can be done to make this more visible.)

src/hwrng.rs Outdated Show resolved Hide resolved
src/hwrng.rs Outdated Show resolved Hide resolved
src/prng.rs Outdated
/// See this modules description regarding quality of the used seeds.
pub fn rand_prng() -> StdRng {
let mut buffer = [0u8; 32];
unsafe {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for unsafe here; as per above the error type is uninhabited, the error handling will just collapse.

(And if the RIOT HWRNG ever does become fallible, we'll get a clean crash rather than UB).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed in 2b99ee5

src/random.rs Outdated Show resolved Hide resolved
* remove unsafe blocks
* make error type empty
* update comments
src/lib.rs Outdated
@@ -146,6 +146,15 @@ pub mod socket_embedded_nal_tcp;
#[cfg(riot_module_periph_gpio)]
pub mod gpio;

#[cfg(riot_module_periph_hwrng)]
pub mod hwrng;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I understand, the sensible way to use all of this is through the prng module.

Is there any good reason that the hwrng module and the random module are pub in the first place, or that RandomSeed::new_from_hwrng would be public?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it is intended to be used through prng. I just left the rest public in case someone might need it e.g to seed his own prng but we could make it private to make people use the "intended" way. I do not have a strong opinion on that matter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then please limit the public parts. Public APIs that are not used are a needless compatibility liability -- whereas the two functions that will stay pub can easily be maintained. If it turns out that any part of this is needed, it's still easy to make a few more parts pub, whereas going back on that is a breaking change.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made the two modules random and hwrng private

@Remmirad
Copy link
Author

Is this even still relevant with the other random module now present in the wrappers? As far as I can see they both do roughly the same with the main differences being:

  • This PR allows to overwrite the current Random state in safe Rust by instantiating multiple instances of it. (Should probably be changed to allow only a single creation)
  • This PR would allow to use different seed sizes (The relevant parts are private at the moment though)
  • Allows to seed the rand StdRng with RIOTs hwrng (Is that even needed? Maybe if multiple RNG instances are required?)
  • This tries to enforce sha256 and not allow to use sha1 (At least for the CryptoRng this might be desirable?)
  • Always forces the user to provide a seed or use the hwrng to create one (without the use of periph_hwrng the auto_init seed might be very bad according to RIOT docs?)

Depending on any of the above being desirable this PR could just be closed or some of the changes could be merged into the current solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants