On Thu, Jun 13, 2024 at 3:18 PM Tom Rini <tr...@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