On Mon, Jun 17, 2024 at 12:32:22PM -0700, Tim Harvey wrote: > 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?
Er, the first section is about Azure and non-custodians use that since it's just a matter of doing a PR against the github tree to trigger the run. -- Tom
signature.asc
Description: PGP signature
