Dominik, > -----Original Message----- > From: Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> > Sent: Monday, October 28, 2019 2:21 AM > To: Ard Biesheuvel; Limonciello, Mario > Cc: linux-efi@xxxxxxxxxxxxxxx > Subject: efistub: EFI_RNG_PROTOCOL on Dell Inc. Latitude 7390 > > > [EXTERNAL EMAIL] > > Ard, Mario, I had some discussion to one of our BIOS guys and wanted to point a few things out. > > 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 Just providing UEFI 2.6 doesn't guarantee an implementation of particular protocols. the protocols are still "optional" but the spec prescribes how they should behave if implemented. > > 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. 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? You should call RngGetInfo() to find the supported protocols instead of making assumptions on which algorithms are supported. On the particular platform you mentioned above, these are the only two algorithms supported (which you of course also mentioned in a follow up). o EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID o EFI_RNG_ALGORITHM_RAW > > 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. I would agree it's unlikely to have changed in any significant way.
