On Thu, Jun 13, 2024 at 3:18 PM Tom Rini trini@konsulko.com wrote:
On Thu, May 30, 2024 at 03:06:31PM -0700, Tim Harvey wrote:
This series will automatically add /chosen/kaslr-seed to the dt if DM_RNG is enabled during the boot process.
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to randomize the virtual address at which the kernel image is loaded, it expects entropy to be provided by the bootloader by populating /chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT is enabled as its implementation uses a different source of entropy that is not yet implemented as DM_RNG. We also skip this if MEASURED_BOOT is enabled as in that case any modifications to the dt will cause measured boot to fail (although there are many other places the dt is altered).
As this fdt node is added elsewhere create a library function and use it to deduplicate code. We will provide a parameter to overwrite the node if present.
For our automatic injection, we will use the first rng device and not overwrite if already present with a non-zero value (which may have been populated by an earlier boot stage). This way if a board specific ft_board_setup() function wants to customize this behavior it can call fdt_kaslrseed with a rng device index of its choosing and set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now but left in place in case boot scripts exist that rely on this command existing and returning success. An informational message is printed to alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well.
This needs to be reworked / update the test that now breaks: https://source.denx.de/u-boot/u-boot/-/jobs/849988#L264
Tom,
Sorry about that. I sent a v6 with a patch to take care of this.
I still haven't quite figured out how to use CI locally to catch things like this. It looks like I need to use gitlab according to [1] but I'm not familiar with Gitlab and creating a uboot project there and pushing my branch failed with a 'pre-receive hook declined'. I'm not sure if anyone has any documentation on how to get started with U-Boot CI?
Best Regards,
Tim [1] https://github.com/u-boot/u-boot/blob/master/doc/develop/ci_testing.rst