Closed Ayush1325 closed 5 months ago
Right now we recommend to use the rdrand
backend on UEFI targets (IIRC most UEFI implementations use it under the hood to get randomness), alternatively, you can use the custom backend.
we generate a custom entry function and store the SystemTable and ImageHandle which can then be accessed from the following nightly APIs: https://github.com/rust-lang/rust/issues/100499
I don't think we should rely on these APIs. Not only they are std
-only, but also being unstable.
I see. While rdrand
should work for x86 and x86_64, what should be done form aarch64?
As I mentioned, you can use a custom backend in cases like this.
I think you can start with creating an experimental custom backend crate which uses the unstable std
API to make it easier for users to use it.
I want to add support for UEFI targets, which now have some support for Rust std. Almost every cryptography crate seems to depend on
getrandom
, so it is kinda essential to have platform support here.However, I don't know how to go about it. UEFI is unique in that there is no syscall or a global extern function you can call. Instead, each application gets a copy of SystemTable and you use functions from that to do anything.
In Rust std, we generate a custom entry function and store the SystemTable and ImageHandle which can then be accessed from the following nightly APIs: https://github.com/rust-lang/rust/issues/100499 . But in a
no_std
context, there probably needs to be a way to register SystemTable withgetrandom
.I would be fine just to have support when std is enabled for now, but it will still require nightly features, and I am not sure about the policy getrandom has for nightly-only targets. So, I would like to get some insight.