[PATCH 1/1] efi_leader: delete rng-seed if having EFI RNG protocol
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.
Additionally remove /chosen/rng-seed provided by QEMU or U-Boot.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h index f84852e384f..511281e150e 100644 --- a/include/efi_loader.h +++ b/include/efi_loader.h @@ -567,7 +567,7 @@ efi_status_t EFIAPI efi_convert_pointer(efi_uintn_t debug_disposition, /* Carve out DT reserved memory ranges */ void efi_carve_out_dt_rsv(void *fdt); /* Purge unused kaslr-seed */ -void efi_try_purge_kaslr_seed(void *fdt); +void efi_try_purge_rng_seed(void *fdt); /* Called by bootefi to make console interface available */ efi_status_t efi_console_register(void); /* Called by efi_init_obj_list() to proble all block devices */ diff --git a/lib/efi_loader/efi_dt_fixup.c b/lib/efi_loader/efi_dt_fixup.c index 9d017804eea..8f9e8dbd1ec 100644 --- a/lib/efi_loader/efi_dt_fixup.c +++ b/lib/efi_loader/efi_dt_fixup.c @@ -41,7 +41,7 @@ static void efi_reserve_memory(u64 addr, u64 size, bool nomap) }
/** - * efi_try_purge_kaslr_seed() - Remove unused kaslr-seed + * efi_try_purge_rng_seed() - Remove unused kaslr-seed, rng-seed * * Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization * and completely ignores the kaslr-seed for its own randomness needs @@ -51,8 +51,9 @@ static void efi_reserve_memory(u64 addr, u64 size, bool nomap) * * @fdt: Pointer to device tree */ -void efi_try_purge_kaslr_seed(void *fdt) +void efi_try_purge_rng_seed(void *fdt) { + const char * const prop[] = {"kaslr-seed", "rng-seed"}; const efi_guid_t efi_guid_rng_protocol = EFI_RNG_PROTOCOL_GUID; struct efi_handler *handler; efi_status_t ret; @@ -67,9 +68,13 @@ void efi_try_purge_kaslr_seed(void *fdt) if (nodeoff < 0) return;
- err = fdt_delprop(fdt, nodeoff, "kaslr-seed"); - if (err < 0 && err != -FDT_ERR_NOTFOUND) - log_err("Error deleting kaslr-seed\n"); + for (const char * const *pos = prop; pos < &prop[ARRAY_SIZE(prop)]; + ++pos) { + err = fdt_delprop(fdt, nodeoff, *pos); + if (err < 0 && err != -FDT_ERR_NOTFOUND) + log_err("Error deleting %s\n", *pos); + log_debug("Deleted /chosen/%s\n", *pos); + } }
/** diff --git a/lib/efi_loader/efi_helper.c b/lib/efi_loader/efi_helper.c index 96f847652ec..a481eb4b7e3 100644 --- a/lib/efi_loader/efi_helper.c +++ b/lib/efi_loader/efi_helper.c @@ -522,7 +522,7 @@ efi_status_t efi_install_fdt(void *fdt) /* Create memory reservations as indicated by the device tree */ efi_carve_out_dt_rsv(fdt);
- efi_try_purge_kaslr_seed(fdt); + efi_try_purge_rng_seed(fdt);
if (CONFIG_IS_ENABLED(EFI_TCG2_PROTOCOL_MEASURE_DTB)) { ret = efi_tcg2_measure_dtb(fdt);
Hi Heinrich,
On Sat, 14 Sept 2024 at 18:06, Heinrich Schuchardt heinrich.schuchardt@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.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
On 19.09.24 16:10, Simon Glass wrote:
Hi Heinrich,
On Sat, 14 Sept 2024 at 18:06, Heinrich Schuchardt heinrich.schuchardt@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.
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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.
Regards /Ilias
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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?
Regards, Simon
Regards /Ilias
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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.
Best regards
Heinrich
Regards, Simon
Regards /Ilias
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt < heinrich.schuchardt@canonical.com> wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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
Thanks Ilias
Best regards
Heinrich
Regards, Simon
Regards /Ilias
Best regards
Heinrich
Signed-off-by: Heinrich Schuchardt <
heinrich.schuchardt@canonical.com>
include/efi_loader.h | 2 +- lib/efi_loader/efi_dt_fixup.c | 15 ++++++++++----- lib/efi_loader/efi_helper.c | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-)
[..]
Regards, Simon
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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?
Regards, Simon
On 19.09.24 17:19, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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?
kaslr-seed can be added via cmd/kaslrseed.c and arch/arm/cpu/armv8/sec_firmware.c. Both is before the user decides if he wants to boot via EFI or via legacy boot.
Best regards
Heinrich
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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.
Regards /Ilias
Regards, Simon
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi all,
On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt heinrich.schuchardt@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.schuchardt@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.
Regards, Simon
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote:
Hi,
On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas ilias.apalodimas@linaro.org wrote: > > Hi all, > > On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt > heinrich.schuchardt@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.schuchardt@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
Hi Ilias,
On Thu, 19 Sept 2024 at 17:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 19.09.24 17:00, Simon Glass wrote: > Hi, > > On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas > ilias.apalodimas@linaro.org wrote: >> >> Hi all, >> >> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt >> heinrich.schuchardt@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.schuchardt@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
But then I don't see what problem that causes...I'm just going to leave this madness to you :-)
Regards, Simon
Hi Simon,
On Fri, 20 Sept 2024 at 10:25, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Thu, 19 Sept 2024 at 17:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote: > > On 19.09.24 17:00, Simon Glass wrote: > > Hi, > > > > On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas > > ilias.apalodimas@linaro.org wrote: > >> > >> Hi all, > >> > >> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt > >> heinrich.schuchardt@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.schuchardt@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
But then I don't see what problem that causes...I'm just going to leave this madness to you :-)
The problem is that in theory, we need to measure a DT as early as possible, but that's not doable in U-Boot yet. The TCG specs have no guidance on measuring DTs, but do have on ACPI tables and we basically copy what's done for ACPI.
The DT is more fragile though. As Heinrich said if you decide to measure it, you can't have random values -- whether that comes from U-Boot injecting those or a previous loader is irrelevant. The result is the same, if you have random values in the measured DT, e.g a mac address or a kaslr-seed the measurements we take on PCR1 will be different and as a result kind of useless.
For the reasons above, measuring a DT is not in any default config. It's up to the user whether he wants to measure it or not. But for the kaslr-seed, since the kernel does not use it when booting via EFI and the EFI_RNG protocol is installed, we remove it.
Hope that clarifies things a bit
Regards /Ilias
Regards, Simon
Hi Ilias,
On Fri, 20 Sept 2024 at 09:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Fri, 20 Sept 2024 at 10:25, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Thu, 19 Sept 2024 at 17:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas ilias.apalodimas@linaro.org wrote: > > > > On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote: >> >> On 19.09.24 17:00, Simon Glass wrote: >> > Hi, >> > >> > On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas >> > ilias.apalodimas@linaro.org wrote: >> >> >> >> Hi all, >> >> >> >> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt >> >> heinrich.schuchardt@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.schuchardt@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
But then I don't see what problem that causes...I'm just going to leave this madness to you :-)
The problem is that in theory, we need to measure a DT as early as possible, but that's not doable in U-Boot yet. The TCG specs have no guidance on measuring DTs, but do have on ACPI tables and we basically copy what's done for ACPI.
The DT is more fragile though. As Heinrich said if you decide to measure it, you can't have random values -- whether that comes from U-Boot injecting those or a previous loader is irrelevant. The result is the same, if you have random values in the measured DT, e.g a mac address or a kaslr-seed the measurements we take on PCR1 will be different and as a result kind of useless.
For the reasons above, measuring a DT is not in any default config. It's up to the user whether he wants to measure it or not. But for the kaslr-seed, since the kernel does not use it when booting via EFI and the EFI_RNG protocol is installed, we remove it.
Hope that clarifies things a bit
Yes it does, thank you.
IMO measuring the devicetree should really be done using a hash of only part of the tree, for example excluding the /options node and perhaps /chosen as well. I just looked to refresh my memory, and adding then removing a property does not result in the same DT as before the addition.
There are several reasons I have this opinion: - The DT is used for things which don't relate to Linux, such as /options/u-boot - The DT may have overlays applied - Some DT nodes may have been 'fixed' up by U-Boot
So if we want to 'measure' the DT, we should probably provide in the DT an indication of which part is hashed, so Linux etc. can take that into account. Also we may want to have multiple hashes, to deal with the case of additions being made. We have something similar to this with FIT signatures, but that mechanism is not suitable here (although it could perhaps help inspire a solution).
Regards, Simon
On 20.09.24 17:58, Simon Glass wrote:
Hi Ilias,
On Fri, 20 Sept 2024 at 09:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Fri, 20 Sept 2024 at 10:25, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Thu, 19 Sept 2024 at 17:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote: > > Hi, > > On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas > ilias.apalodimas@linaro.org wrote: >> >> >> >> On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote: >>> >>> On 19.09.24 17:00, Simon Glass wrote: >>>> Hi, >>>> >>>> On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas >>>> ilias.apalodimas@linaro.org wrote: >>>>> >>>>> Hi all, >>>>> >>>>> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt >>>>> heinrich.schuchardt@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.schuchardt@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
But then I don't see what problem that causes...I'm just going to leave this madness to you :-)
The problem is that in theory, we need to measure a DT as early as possible, but that's not doable in U-Boot yet. The TCG specs have no guidance on measuring DTs, but do have on ACPI tables and we basically copy what's done for ACPI.
The DT is more fragile though. As Heinrich said if you decide to measure it, you can't have random values -- whether that comes from U-Boot injecting those or a previous loader is irrelevant. The result is the same, if you have random values in the measured DT, e.g a mac address or a kaslr-seed the measurements we take on PCR1 will be different and as a result kind of useless.
For the reasons above, measuring a DT is not in any default config. It's up to the user whether he wants to measure it or not. But for the kaslr-seed, since the kernel does not use it when booting via EFI and the EFI_RNG protocol is installed, we remove it.
Hope that clarifies things a bit
Yes it does, thank you.
IMO measuring the devicetree should really be done using a hash of only part of the tree, for example excluding the /options node and perhaps /chosen as well. I just looked to refresh my memory, and adding then removing a property does not result in the same DT as before the addition.
We must not exclude the /chosen node as it may contain:
* /chosen/bootargs - Command line arguments must be measured. * /chosen/initrd - Filename of the initial RAM disk.
For more items see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt.
There are several reasons I have this opinion:
- The DT is used for things which don't relate to Linux, such as /options/u-boot
- The DT may have overlays applied
- Some DT nodes may have been 'fixed' up by U-Boot
So if we want to 'measure' the DT, we should probably provide in the DT an indication of which part is hashed, so Linux etc. can take that into account. Also we may want to have multiple hashes, to deal with the case of additions being made. We have something similar to this with FIT signatures, but that mechanism is not suitable here (although it could perhaps help inspire a solution).
Current Linux just expects the measurement. It would not to be able to consume any information describing which part of the DT has been measured.
The idea of measurement is that it should capture the whole state. We cannot generally exclude fix-ups:
If memory is added and U-Boot changes the device-tree accordingly, this should change the measurement.
If the network card is replaced with a different card resulting in a different MAC address copied to the device-tree, this should change the measurement, too.
Best regards
Heinrich
Hi Heinrich,
On Sun, 22 Sept 2024 at 15:43, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
On 20.09.24 17:58, Simon Glass wrote:
Hi Ilias,
On Fri, 20 Sept 2024 at 09:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Simon,
On Fri, 20 Sept 2024 at 10:25, Simon Glass sjg@chromium.org wrote:
Hi Ilias,
On Thu, 19 Sept 2024 at 17:51, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Thu, 19 Sept 2024 at 18:39, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 19 Sept 2024 at 17:37, Ilias Apalodimas ilias.apalodimas@linaro.org wrote: > > On Thu, 19 Sept 2024 at 18:19, Simon Glass sjg@chromium.org wrote: >> >> Hi, >> >> On Thu, 19 Sept 2024 at 17:13, Ilias Apalodimas >> ilias.apalodimas@linaro.org wrote: >>> >>> >>> >>> On Thu, Sep 19, 2024, 18:05 Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote: >>>> >>>> On 19.09.24 17:00, Simon Glass wrote: >>>>> Hi, >>>>> >>>>> On Thu, 19 Sept 2024 at 16:32, Ilias Apalodimas >>>>> ilias.apalodimas@linaro.org wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> On Thu, 19 Sept 2024 at 17:20, Heinrich Schuchardt >>>>>> heinrich.schuchardt@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.schuchardt@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
But then I don't see what problem that causes...I'm just going to leave this madness to you :-)
The problem is that in theory, we need to measure a DT as early as possible, but that's not doable in U-Boot yet. The TCG specs have no guidance on measuring DTs, but do have on ACPI tables and we basically copy what's done for ACPI.
The DT is more fragile though. As Heinrich said if you decide to measure it, you can't have random values -- whether that comes from U-Boot injecting those or a previous loader is irrelevant. The result is the same, if you have random values in the measured DT, e.g a mac address or a kaslr-seed the measurements we take on PCR1 will be different and as a result kind of useless.
For the reasons above, measuring a DT is not in any default config. It's up to the user whether he wants to measure it or not. But for the kaslr-seed, since the kernel does not use it when booting via EFI and the EFI_RNG protocol is installed, we remove it.
Hope that clarifies things a bit
Yes it does, thank you.
IMO measuring the devicetree should really be done using a hash of only part of the tree, for example excluding the /options node and perhaps /chosen as well. I just looked to refresh my memory, and adding then removing a property does not result in the same DT as before the addition.
We must not exclude the /chosen node as it may contain:
- /chosen/bootargs - Command line arguments must be measured.
- /chosen/initrd - Filename of the initial RAM disk.
For more items see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt.
There are several reasons I have this opinion:
- The DT is used for things which don't relate to Linux, such as /options/u-boot
- The DT may have overlays applied
- Some DT nodes may have been 'fixed' up by U-Boot
So if we want to 'measure' the DT, we should probably provide in the DT an indication of which part is hashed, so Linux etc. can take that into account. Also we may want to have multiple hashes, to deal with the case of additions being made. We have something similar to this with FIT signatures, but that mechanism is not suitable here (although it could perhaps help inspire a solution).
Current Linux just expects the measurement. It would not to be able to consume any information describing which part of the DT has been measured.
The idea of measurement is that it should capture the whole state. We cannot generally exclude fix-ups:
If memory is added and U-Boot changes the device-tree accordingly, this should change the measurement.
If the network card is replaced with a different card resulting in a different MAC address copied to the device-tree, this should change the measurement, too.
Yes, anything that is used must be measured.
But removing things from the devicetree does not generally put it back to the state before they were added. That's really the main point I was trying to get across.
Regards, Simon
participants (3)
-
Heinrich Schuchardt -
Ilias Apalodimas -
Simon Glass