Linking error when using rand::thread_rng()
#23
Comments
|
@arnauorriols thank you fore reporting the issue. Our team made initial analysis with following result: Some pointers to source code: |
|
Thanks for reporting this @arnauorriols! As to your comment that this should be a compile time rather than link time error — I think while being correct this would put us further away from reaching the desired state where everything works as expected. To make all such situations compile time errors, we would need to get a real list of posix/unix APIs implemented in ESP-IDF, and exclude everything that's not implemented in libc crate. Then, realize that half of them actually can be implemented or stubbed out, make the changes in IDF, and then un-exclude them in libc. The latter will probably take more time. I think once we do the initial pass of implementing the missing things in IDF, we can look at the list of functions declared in (sorry, have crossed posts with @georgik!) |
espidf targets have libstd available through ESP-IDF framework. This framework provides most but not all of the POSIX standard API. In particular, ESP-IDF does not provide a means to fork threads, and cannot implement `pthread_atfork` (see espressif/rust-esp32-example#23). This means `rand::thread_rng()` is not available on those targets, as it is based on storing the rng in the thread-local storage, accessed through a thread handle. For these targets, this commit specializes the random_key and random_nonce generators to use `StdRng::from_entropy()` instead. In practice, given the coldness of these 2 functions, the same level of security and performance is to be expected. Note that currently `getrandom` does not support `espidf` targets and requires a small patch.
espidf targets have libstd available through ESP-IDF framework. This framework provides most but not all of the POSIX standard API. In particular, ESP-IDF does not provide a means to fork threads, and cannot implement `pthread_atfork` (see espressif/rust-esp32-example#23). This means `rand::thread_rng()` is not available on those targets, as it is based on storing the rng in the thread-local storage, accessed through a thread handle. For these targets, this commit specializes the random_key and random_nonce generators to use `StdRng::from_entropy()` instead. In practice, given the coldness of these 2 functions, the same level of security and performance is to be expected. Note that currently `getrandom` does not support `espidf` targets and requires a small patch.
|
@igrr Is this issue still relevant with 1.55 and installation instructions from https://github.com/esp-rs/rust-build project? |
I'm using this example as boilerplate for a PoC I'm conducting. I'm compiling with the docker image
georgikrocks/esp-idf-rust:latest(2e95100a412d). When my Rust code callsrand::thread_rng(), compilation fails withI noticed ESP-IDF
pthread.cimplementation does not implementpthread_atfork. Am I right in assuming there's nothing I can do ATM? Is it a bug, pending implementation, or can't be implemented?In any case, this should probably be caught at compile time rather than link time. If you could point me to the right repository to where report this issue I'd appreciated it.
The text was updated successfully, but these errors were encountered: