Document how to port *ring* to a `no_std`-only platform

[briansmith]

[Updated]: Currently the main issue is the need to implement fill_impl in ring::rand for each platform.

[briansmith]

The other, harder, issue, is how to get the test suite to run on such platforms, because the tests use libstd a lot currently. Some issues are probably, e.g. we could use ArrayVec or similar instead of std::vec::Vec in most cases, though we'd have to worry about stack overflows.

I suggest we prototype this first by solving it specifically for SGX, which seems to be a no_std platform that people are especially interested in. See https://github.com/baidu/rust-sgx-sdk#v104-release in particular; it would be nice to help Baidu avoid the need for forking ring.

[elichai]

@briansmith Are you working on this?
I would be glad to try and do this for sgx.

[jonas-schievink]

This solution is unlikely to work in general for embedded platforms. AFAIK, for SGX there is only one obvious implementation of a random number generator (namely the rdrand instruction) that can be used for the entire target.

This is not the case for eg. embedded ARM targets, which don't have a single random number generator. Instead, vendors often provide a peripheral for random number generation, which could implement SecureRandom.

For those targets I suggest #[cfg]ing the SystemRandom struct away, and expecting users (or microcontroller support crates) to implement the SecureRandom trait for specific peripherals. Would that be an acceptable solution?

EDIT: Just noticed that SecureRandom is sealed, why is that? Can that be removed or would that break any assumptions?

[briansmith]

EDIT: Just noticed that SecureRandom is sealed, why is that? Can that be removed or would that break any assumptions?

That way we can guarantee it is actually secure by ensuring all the implementations are in ring.

For those targets I suggest #[cfg]ing the SystemRandom struct away, and expecting users (or microcontroller support crates) to implement the SecureRandom trait for specific peripherals. Would that be an acceptable solution?

In such situations the peripherals are almost definitely implementing a raw, unmixed, entropy source. We should take the output of that and postprocess it with a DRBG.

In other words, for #[cfg(target_os="none")] we can provide an alternative API for plugging in an entropy source, which feeds a DRBG. Probably we should do that for SGX too, in particular.

[jonas-schievink]

Thanks, that makes sense!

In such situations the peripherals are almost definitely implementing a raw, unmixed, entropy source. We should take the output of that and postprocess it with a DRBG.

Nordic employs optional bias correction in their RNGs, so I think this step would not be needed for their devices (provided that the correction is actually turned on, of course - nrf-rs/nrf-hal#85).

That way we can guarantee it is actually secure by ensuring all the implementations are in ring.

That would not be the case if you'd accept external entropy sources though, right?

[briansmith]

Nordic employs optional bias correction in their RNGs, so I think this step would not be needed for their devices (provided that the correction is actually turned on, of course - nrf-rs/nrf52-hal#85).

Interesting. I don't know if that would be sufficient without reading more about it.

That way we can guarantee it is actually secure by ensuring all the implementations are in ring.

That would not be the case if you'd accept external entropy sources though, right?

First, let me walk back what I said a bit: In ring we don't guarantee anything. We try to make things as safe as we can given limited resources.

Your issue nrf-rs/nrf-hal#85 shows exactly why I've avoided providing a way to swap in an entropy source so far. Perhaps, instead of providing an extension point for entropy sources, we should provide explicit features that enable specific implementations. So, for example, we could have a nrf52-hal feature that enabled an implementation of SecureRandom that delegates its entropy collection to the nrf52-hal library. This way we can work with all the HAL providers to ensure that things like nrf-rs/nrf-hal#85 are properly addressed before people use them (through ring).

[briansmith]

From #813:

• Lots of files refer to libc::c_int and friends, which aren't present (the libc crate is empty on this family of targets...). I believe the standard approach here is to use https://github.com/japaric/cty?

Why not just implement the size types in the libc crate for that target? That's what the libc crate is for.

Researching this, it seems the libc crate maintainers don't want to port libc to platforms that need the C types defined but which don't have a libc. See rust-lang/libc#1092 for example.

The cty crate is basically the libc-types crate that was proposed in rust-lang/rfcs#1783. I left a comment (rust-lang/rfcs#1783 (comment)) about reopening that issue. I think having a libc-types crate that is type-compatible with libc's definitions of the same-named types is the right solution. If you agree, please comment over there.

[josephlr]

The cty crate is basically the libc-types crate that was proposed in rust-lang/rfcs#1783. I left a comment (rust-lang/rfcs#1783 (comment)) about reopening that issue. I think having a libc-types crate that is type-compatible with libc's definitions of the same-named types is the right solution. If you agree, please comment over there.

So after my attempt in rust-lang/libc#1244 and a later attempt in rust-lang/libc#1285, the conclusion was to keep cty and libc separate for now (rust-lang/libc#1285 (comment)), but to make sure that the types between the crates will remain compatible (rust-lang/libc#1286). So it seems like using cty (if that's all we need) is the best way forward.

In other words, for #[cfg(target_os="none")] we can provide an alternative API for plugging in an entropy source, which feeds a DRBG. Probably we should do that for SGX too, in particular.

To make things easier, we could simply have three (mutually exclusive) Cargo features that determine how SystemRandom is implemented:

• os_rng (default for most platforms): SystemRandom gets randomness directly from the OS, using OS-dependent features. No need to change the currently implementation here (for OSes that currently work).
  • For simplicity, it might make sense to eliminate the dev_urandom_fallback features as it is not necessary.
• cpu_rng (default for UEFI and SGX): SystemRandom gets randomness directly from the CPU.
  • Would check for CPU support on first invocation (similar to how we check for getrandom support on Linux).
  • Could start with just x86 support
  • Lots of architectures now have support for this functionality:
    • x86/x86_64 - RDRAND
    • ARM (64 bit) - RNDR (added in ARMv8.5)
    • POWER - the darn instruction, search for "darn" in the POWER9 manual (page 368)
    • s390 - PRNO trng subfunction, see the Linux kernel implementation
    • RISC-V - has seen proposals to add such a feature
• ext_rng: SystemRandom gains an additional method allowing it to accept randomness from an external source.
  • External randomness would feed a CSPRNG (to avoid the above issues).
  • SecureRandom::fill() would only succeed once enough entropy (256 bits) had been fed to the CSPRNG.
  • This allows ring to work on platforms that only have external RNG devices without drivers for those devices having to live in the ring repo.
• If none of the above features are on, the SystemRandom struct will not exist.
  • In this scenario, none of ring's APIs that use randomness would be usable.
  • This is still useful for platforms that only need a subset of ring's functionality:
    • Hashing
    • HMAC verification
    • Signature verification

[josephlr]

Also, @briansmith is there a reason we don't just use getrandom (the implementation crate for rand::OsRng) for SystemRandom? It seems like:

• It does the right things security-wise
• It would solve a lot of the existing RNG problems for ring
• SystemRandom and rand::OsRng would have the same implementation.
• It's been proposed for inclusion into core/std

[briansmith]

So after my attempt in rust-lang/libc#1244 and a later attempt in rust-lang/libc#1285, the conclusion was to keep cty and libc separate for now (rust-lang/libc#1285 (comment)), but to make sure that the types between the crates will remain compatible (rust-lang/libc#1286). So it seems like using cty (if that's all we need) is the best way forward.

Generally ring doesn't depend on third-party crates. We had made an exception for spin because it was already a dependency of a rust-lang crate. As far as I understand those previous attempts to integrate cty and libc, I don't think they've failed but rather they just need more effort (political and technical) put into them. I think the correct approach is to write a new RFC, probably based on rust-lang/rfcs#1783 (comment). I think there will be a lot of political support for the libc-types crate and I think it will get accepted. I think it will be a lot smoother than getting the getrandom crate accepted into libcore/libstd.

[briansmith]

Also, @briansmith is there a reason we don't just use getrandom

ring's doesn't use getrandom primarily because: (1) ring predates that crate by several years, (2) ring avoids depending on third-party crates to minimize risk, (3) I haven't reviewed the getrandom code, so it's not clear how correct it is. This is something that should be revisited if/when getrandom() actually does make it into libcore. I'm not holding my breath while that happens, though, since that idea has been discussed for about as long as ring has existed.

A bigger problem is that it isn't clear that ring's current API (which is similar to the getrandom crate's API) is sufficient for the lowest-level embedded use cases. When there is an external peripheral that provides a hardware RNG, what kind of API do we need that works in conjunction with the the embedded HAL to manage access to the hardware RNG? When a long-running task needs intermittent access to a CSPRNG, how can we provide that access without blocking access to other peripherals? (Somebody made a comment to this effect before, but I can't find where it was.) Note that in ring's API, every function that uses a CSPRNG takes a &SecureRandom parameter and nothing needs to hold a long-lived reference to the CSPRNG. I think this is the kind of API that is needed to handle the trickiest embedded use cases. Unfortunately, I know many ring-based libraries hold references to SystemRandom across many operations, which kind of undoes that benefit of ring's design. OTOH, they are doing that because there doesn't seem to be a clear benefit to them to doing things a different way. I hope this can be sorted out in this issue.