Hello all, Today's pull of random.c changes caused a regression on arm64 UEFI systems that invoke EFI_RNG_PROTOCOL to obtain strong entropy from the platform. (arm64 does not have an architected instruction a la RDRAND) Before (grep'ing dmesg for entropy, rng, random): efi: ... RNG=0xff7bc898 efi: seeding entropy pool random: fast init done ... random: crng init done After: efi: ... RNG=0xff7ac898 efi: seeding entropy pool ... random: get_random_bytes called from start_kernel+0xb4/0x48c with crng_init=0 ... random: fast init done ... random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) random: systemd: uninitialized urandom read (16 bytes read) ... random: crng init done The current EFI code uses add_device_randomness() to pass the firmware provided strong random seed to the kernel, for lack of a more appropriate interface (at the time, at least). I tried to switch to add_hwgenerator_randomness(), which seems more appropriate, but it appears to me that it is impossible to get the kernel entropy pool into the fully initialized state (crng_init=2) using that without some dodgy tricks. Comments and ideas welcome. Thanks, Ard. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
