On Thu, 19 Sept 2024 at 18:39, Simon Glass <s...@chromium.org> wrote: > > Hi, > > On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas > <ilias.apalodi...@linaro.org> wrote: > > > > On Thu, 19 Sept 2024 at 18:19, Simon Glass <s...@chromium.org> wrote: > > > > > > Hi, > > > > > > On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas > > > <ilias.apalodi...@linaro.org> wrote: > > > > > > > > > > > > > > > > On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt > > > > <heinrich.schucha...@canonical.com> wrote: > > > >> > > > >> On 19.09.24 17:00, Simon Glass wrote: > > > >> > Hi, > > > >> > > > > >> > On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas > > > >> > <ilias.apalodi...@linaro.org> wrote: > > > >> >> > > > >> >> Hi all, > > > >> >> > > > >> >> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt > > > >> >> <heinrich.schucha...@canonical.com> wrote: > > > >> >>> > > > >> >>> On 19.09.24 16:10, Simon Glass wrote: > > > >> >>>> Hi Heinrich, > > > >> >>>> > > > >> >>>> On Sat, 14 Sept 2024 at 18:06, Heinrich Schuchardt > > > >> >>>> <heinrich.schucha...@canonical.com> wrote: > > > >> >>>>> > > > >> >>>>> For measured be boot we must avoid any volatile values in the > > > >> >>>>> device-tree. > > > >> >>>>> We already delete /chosen/kaslr-seed if we provide and EFI RNG > > > >> >>>>> protocol. > > > >> >>>> > > > >> >>>> Could you explain a bit why this is, and where this is checked? > > > >> >>>>> > > > >> >>>>> Additionally remove /chosen/rng-seed provided by QEMU or U-Boot. > > > >> >>> > > > >> >>> Measured boot relies on creating hashes of artifacts and writing > > > >> >>> these > > > >> >>> to TPM. If the hashes don't match the OS will either warn or > > > >> >>> refuse to > > > >> >>> boot. The device-tree is one of the artifacts that are measured. > > > >> >>> > > > >> >>> If we have random values in /chosen, measured boot will fail. > > > >> >>> > > > >> >>> When an EFI RNG protocol is provided by the firmware, GRUB and the > > > >> >>> kernel will use it instead of /chosen/rng-seed and > > > >> >>> /chosen/kaslr-seed. > > > >> >> > > > >> >> There's a comment on top of that function that explains what > > > >> >> happens as well. > > > >> >> In short the EFI stub does not even look at the KASLR seed and never > > > >> >> randomizes the physical placement of the kernel. It only does that > > > >> >> when the EFI_RNG protocol is there. > > > >> > > > > >> > OK thank you. I suppose I am more just wondering why it got added in > > > >> > the first place? > > > >> > > > >> For booting via the legacy Linux entry point adding kaslr-seed allows > > > >> to > > > >> randomize addresses. QEMU adds rng-seed instead of kaslr-seed. > > > > > > > > > > > > Not the kernel physical placement. It randomizes only the virtual > > > > placement > > > > > > So, are you saying that U-Boot adds this field into the FDT and then > > > removes it? > > > > Yes. As Heinrich said, the rng seed is still usable for some > > randomization. If we boot with EFI and have an RNG protocol, we dont > > need it and it also messes up the TPM measurements, so we remove it. > > But the code that injects it to u-boot, or the prior bootloader that > > handed you over a DT, does not know if you plan to boot with EFI. > > I'm actually surprised that this works. Normally, removing a property > does not drop that property from the string table, so adding a > property and deleting it is not normally the same as never adding it. > But perhaps that has changed? > > Anyway, I think we should add the property when we know it is OK to do > so, which is just before we boot. If you agree I can take a look at > that.
Sure, but we won't be able to remove this code. There are still first-stage boot loaders that might send you a DT over a bloblist, that has a kaslr-seed Thanks /Ilias > > Regards, > Simon
