What is the expected way to get randomness on hermitcore?

[josephlr]

I'm one of the maintainers for getrandom, a no_std library which attempts to define the "standard" way to get cryptographic entropy on every Rust target. The rand crate and others use this crate under the hood.

As far as I can tell HermitCore doesn't expose or have a way to get OS-based randomness. For that reason, we don't currently support Hermit.

Are users simply expected to call RDRAND? This is reasonable, provided that HermitCore is x86_64 only.

[stlankes]

You find at https://github.com/hermitcore/libhermit-rs/blob/master/src/syscalls/random.rs#L20-L31 our generator of random numbers. If RDRAND is available, it will use RDRAND. Otherwise, you het only pseudo random number. But you are right, I should add a function in hermit-abi.

[josephlr]

Sounds good, we will just call RDRAND directly in getrandom (we already have the implementation). Also, the fallback Hermit RNG mechanism is not cryptographicly secure, is that a problem?

[jbreitbart]

I am afraid directly calling RDRAND will not work well for the upcoming releases, as there is same work for AARCH64 see e.g. #61 Do we have a plan on how to do that on arm @stlankes? And yes, the fallback isn't great, we should be sure that this is at least clearly exposed to the users...

[stlankes]

Sounds good, we will just call RDRAND directly in getrandom (we already have the implementation). Also, the fallback Hermit RNG mechanism is not cryptographicly secure, is that a problem?

We use also RDRAND to generate random numbers. However, our fallback on systems without RDRAND support is currently not cryptographicly secure.

Do we have a plan on how to do that on arm @stlankes?

AARCH64 has also hardware support for random numbers. For instance RDNR could be solution. I will look in the specification.

[jbreitbart]

@josephlr can you a look at hermit-os/kernel#98 Is calling the syscall fine for you?

[josephlr]

@josephlr can you a look at hermitcore/libhermit-rs#98 Is calling the syscall fine for you?

One issue there is the fallback, getrandom's API is "fail if you can't get good RNG", so with the current implementation in libhermit, we would have to use our RDRAND implementation instead of calling the syscall (which is easy for us to do).

AARCH64 has also hardware support for random numbers. For instance RDNR could be solution. I will look in the specification.

We looked into this briefly for getrandom, one issue we found is that ARM chips (prior to RDNR being common) all have a different way to get cryptographic randomness, so you end up having an explosion of different implementations (depending on what you're targeting).

[josephlr]

One thing some OSes do is provide a way to know if the RNG is secure/seeded/whatever. That could work, or have a separate secure_rand() function that won't ever give insecure RNG.

Example for vxworks: https://github.com/rust-random/getrandom/blob/5d2a4a2e56df3e4fc997695faa52d8ff0e2da203/src/vxworks.rs#L16

[stlankes]

Yeah, this approach is really good. I will add a similar syscall.

[stlankes]

I add an interface in #64. Does it meet your requirements?

[josephlr]

I add an interface in #64. Does it meet your requirements?

Yes! That interface looks great (and would allow getrandom to work on aarch64 without needing any additional changes).

[stlankes]

I merged #64 and close this issue. Please reopen this issue, if the interface is not suitable for your use case.