On Mon, 28 Oct 2019 at 09:42, Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > > Hello Ard, > > On Mon, Oct 28, 2019 at 08:46:28AM +0100, Ard Biesheuvel wrote: > > Hello Dominik, > > > > On Mon, 28 Oct 2019 at 08:30, Dominik Brodowski > > <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Ard, Mario, > > > > > > in theory, invoking EFI_RNG_PROTOCOL on a Dell Inc. Latitude 7390/09386V, > > > BIOS 1.9.2 04/03/2019, should work fine as the system provides EFI v2.60. > > > Using my patch from a few weeks ago[1], efi_random_get_seed() is called from > > > arch/x86/boot/compressed/eboot.c::efi_main(). In efi_random_get_seed(), the > > > calls to > > > > > > status = efi_call_early(locate_protocol, &rng_proto, NULL, > > > (void **)&rng); > > > > > > and > > > > > > status = efi_call_early(allocate_pool, EFI_RUNTIME_SERVICES_DATA, > > > sizeof(*seed) + EFI_RANDOM_SEED_SIZE, > > > (void **)&seed); > > > > > > succeed. However, > > > > > > status = rng->get_rng(rng, &rng_algo_raw, EFI_RANDOM_SEED_SIZE, > > > seed->bits); > > > > > > returns EFI_INVALID_PARAMETER, though I can't see why one of these > > > parameters is invalid. > > > > The UEFI spec defines the conditions under which this function may > > return EFI_INVALID_PARAMETER as > > > > """ > > RNGValue is null or RNGValueLength is zero. > > > > """ > > > > > > > When trying to use the default rng algorithm (by > > > modifying the test to "(status != EFI_SUCCESS)"), > > > > > > status = rng->get_rng(rng, NULL, EFI_RANDOM_SEED_SIZE, > > > seed->bits); > > > > > > the call doesn't seem to return. > > > > > > Any ideas? > > > > > > > Try running this from the UEFI shell: > > > > http://people.linaro.org/~ard.biesheuvel/RngTest-X64.efi > > Interestingly, this succeeds -- with the default algorithm, SP800-90-CTR-256 > and RAW. So I am more confused than before on why the call to ->get_rng() > fails in efi_random_get_seed(). > It might be an issue with the size of the output. The original RDRAND based driver in EDK2 contains an apparent misconception that, due to the fact that certain SP800-90-CTR-256 DRBGs require 32 bytes of raw entropy as a seed, it is only valid for the RAW algorithm to be called with an output size of 32. So in this case, it might be that 32 is treated as a magic number too, and any other size is rejected by the RAW algorithm. Not sure why the other one fails, though, but the fact that RAW and SP800-90-CTR-256 are the only supported algorithms suggests that your implementation is at least similar to the RDRAND based RngDxe implementation in EDK2.
