Hermit is not currently supported by getrandom

[josephlr]

Hermitcore is a unikernel OS, written in Rust, with Tier 3 libstd support for aarch64-unknown-hermit and x86_64-unknown-hermit.

See #198 and #183 for previous attempts at this.

Other PRs/issues of note:

• My initial question to the Hermit folks about their RNG: What is the expected way to get randomness on hermitcore? hermit-os/hermit-rs#63
• Change that adds Cryptographic RNG support to Hermit (x86 only): syscall to set the seed of the random number generator hermit-os/kernel#98
• Change that exposes RNG APIs as part of hermit-abi: add functions to create random numbers hermit-os/hermit-rs#64
• Making hermit-abi always no_std: Allow hermit-abi to build without std hermit-os/hermit-rs#103
• Fix for the RDRAND implementation in libhermit-rs: Fix broken rdrand implementation hermit-os/kernel#154
• Feature request to have hermit use a buffer-based API: Improve randomness syscalls hermit-os/kernel#143

We should figure out:

• How/when we want to add support to getrandom
• Is the existing secure_rand64 API sufficient?
• Hermit's RNG apis current don't work on aarch64, is that an issue?

[newpavlov]

Hermit's RNG apis current don't work on aarch64, is that an issue?

Yes, it's an issue, since it causes workarounds like this. In user code it can be worked around slightly more elegantly using the custom feature, but we can not rely on it in std. Note that currently Hermit's std simply uses a constant seed on all targets.

[josephlr]

I think the most reasonable approach here is the following:

1. Simply add support for hermit using their secure_rand64 API and the hermit-abi crate. Given that hermit is a unikernel, I don't see any reason to push them for a buffer-based API (so Improve randomness syscalls hermit-os/kernel#143 isn't too important).
2. Keep the aarch64+hermit workaround in Use getrandom for generating HashMap seed rust-lang/rust#80149 for now (to keep existing behavior).
3. Eventually, change std's use of getrandom to emit a fallback seed if the getrandom function fails. Then, a user on aarch64-unknown-hermit will:
   • Call getrandom::getrandom, which will call secure_rand64, which will fail, causing the function to return an error.
   • The std implementation will then return a fallback seed, preserving the existing behavior.

[newpavlov]

Given that hermit is a unikernel, I don't see any reason to push them for a buffer-based API

Buffer-based API is not important here, it's the fact that Hermit randomness API always fails on ARM targets. To say the least, it's not normal and should be fixed.

The std implementation will then return a fallback seed, preserving the existing behavior.

I don't think it's a good behavior for all targets. It effectively means introduction of potential silent failures just because one target has an always failing randomness source.

[josephlr]

Fixed by #333