mbedtls fails to initialize if run under qemu which does not support getrandom #1212
Comments
|
@randombit Thank you for reporting this issue! |
|
ARM Internal Ref: IOTSSL-1948 |
|
@RonEld This is armv7 (based on my kernel headers, aarch64 uses 278 for The problem is the code is being built on a machine with recent kernel headers (so |
|
Thanks @randombit bit raising this, and apologies this issue was silent for so long. For reference, I reproduced the issue on my Ubuntu 16.04 machine in the following way:
Observe failure propagated from I tested the fix proposed by @randombit and it works fine. I will open a PR for it where we can continue the discussion. |
This commit fixes issue Mbed-TLS#1212 related to platform-specific entropy polling in an syscall-emulated environment. Previously, the implementation of the entropy gathering function `mbedtls_platform_entropy_poll()` for linux machines used the following logic to determine how to obtain entropy from the kernel: 1. If the getrandom() system call identifier SYS_getrandom is present and the kernel version is 3.17 or higher, use syscall( SYS_getrandom, ... ) 2. Otherwise, fall back to reading from /dev/random. There are two issues with this: 1. Portability: When cross-compiling the code for a different architecture and running it through system call emulation in qemu, qemu reports the host kernel version through uname but, as of v.2.5.0, doesn't support emulating the getrandom() syscall. This leads to `mbedtls_platform_entropy_poll()` failing even though reading from /dev/random would have worked. 2. Style: Extracting the linux kernel version from the output of `uname` is slightly tedious. This commit fixes both by implementing the suggestion in Mbed-TLS#1212: - It removes the kernel-version detection through uname(). - Instead, it checks whether `syscall( SYS_getrandom, ... )` fails with errno set to ENOSYS indicating an unknown system call. If so, it falls through to trying to read from /dev/random. Fixes Mbed-TLS#1212.
|
@randombit I opened #2117 to address this. Thanks again for your report and the suggested fix. Could you please let me know how you would like to be credited in the |
This commit fixes issue Mbed-TLS#1212 related to platform-specific entropy polling in an syscall-emulated environment. Previously, the implementation of the entropy gathering function `mbedtls_platform_entropy_poll()` for linux machines used the following logic to determine how to obtain entropy from the kernel: 1. If the getrandom() system call identifier SYS_getrandom is present and the kernel version is 3.17 or higher, use syscall( SYS_getrandom, ... ) 2. Otherwise, fall back to reading from /dev/random. There are two issues with this: 1. Portability: When cross-compiling the code for a different architecture and running it through system call emulation in qemu, qemu reports the host kernel version through uname but, as of v.2.5.0, doesn't support emulating the getrandom() syscall. This leads to `mbedtls_platform_entropy_poll()` failing even though reading from /dev/random would have worked. 2. Style: Extracting the linux kernel version from the output of `uname` is slightly tedious. This commit fixes both by implementing the suggestion in Mbed-TLS#1212: - It removes the kernel-version detection through uname(). - Instead, it checks whether `syscall( SYS_getrandom, ... )` fails with errno set to ENOSYS indicating an unknown system call. If so, it falls through to trying to read from /dev/random. Fixes Mbed-TLS#1212.
This commit fixes issue Mbed-TLS#1212 related to platform-specific entropy polling in an syscall-emulated environment. Previously, the implementation of the entropy gathering function `mbedtls_platform_entropy_poll()` for linux machines used the following logic to determine how to obtain entropy from the kernel: 1. If the getrandom() system call identifier SYS_getrandom is present and the kernel version is 3.17 or higher, use syscall( SYS_getrandom, ... ) 2. Otherwise, fall back to reading from /dev/random. There are two issues with this: 1. Portability: When cross-compiling the code for a different architecture and running it through system call emulation in qemu, qemu reports the host kernel version through uname but, as of v.2.5.0, doesn't support emulating the getrandom() syscall. This leads to `mbedtls_platform_entropy_poll()` failing even though reading from /dev/random would have worked. 2. Style: Extracting the linux kernel version from the output of `uname` is slightly tedious. This commit fixes both by implementing the suggestion in Mbed-TLS#1212: - It removes the kernel-version detection through uname(). - Instead, it checks whether `syscall( SYS_getrandom, ... )` fails with errno set to ENOSYS indicating an unknown system call. If so, it falls through to trying to read from /dev/random. Fixes Mbed-TLS#1212.
Expected behavior
That it is possible to run an application using mbedtls under qemu.
Actual behavior
The problem is that the version of qemu in Ubuntu 16.04 does not support
getrandomsyscall. But mbedtls expects that as long as the uname is at least 3.17 thengetrandommust work, and just fails when qemu returns an error. Instead, it should fall back to trying/dev/random, which works fine under qemu.Doing this would actually seem to simplify the code by allowing to completely remove the version check (calling
uname, parsing the output, etc) - try calling the syscall, if it returns ENOSYS then mark getrandom as unavailable and continue with /dev/urandom.Steps to reproduce
Compile mbedtls using ARM cross compiler. Then cross-compile curl, linking against mbedtls. Run it under qemu 2.5.0, trying to access an https url.
The text was updated successfully, but these errors were encountered: