[PATCH 0/2] efi: device tree fix-up

[PATCH 0/2] efi: device tree fix-up

[Heinrich Schuchardt]

Operating systems need a description of the hardware. This description can
either be supplied via ACPI tables or via device-trees. On the ARM
architecture ACPI tables are not avaialable for most devices.

In an ideal world device-trees would be defined once by the hardware
manufacturer and would not be subject to change.

In reality device-trees or subject to frequent changes. Linux has a long
record of breaking forward and backwards compatibility between device-
trees and the kernel. So for booting it is wise to use the specific device-
tree that comes with the operation system. This requires reading the
device-tree from file.

One approach is to leave loading the device-tree file to the firmware. This
works fine if the firmware is loading the triple of kernel, initrd, and
device-tree. This is what Debian does with the flash-kernel package. It
provides a boot script for U-Boot that loads the most recent kernel,
initrd, and device-tree.

Before passing the device-tree to the operating as an EFI configuration
table the firmware goes through the following steps:

* Fix-ups are applied to the device-tree. Examples of the changes include
  the memory size and the RISC-V boot hart. Without the changes the
  operating system may not boot at all or crash later.

* Memory reservations are added to the memory map according to the
  /reserved-memory node and the memory reservation block of the
  device-tree. Without these reservations the operating system may crash.

When using GRUB it is not known beforehand which operating system the user
will choose. To guarantee compatibility with the operating system GRUB has
to take control of the device-tree loading.

GRUB has a devicetree command to load a device-tree which is then passed as
EFI configuration table to the operating systems. But GRUB lacks the
information needed to apply fix-ups to the device-tree. Further memory
reservations are not executed.

What is needed is to pass the device-tree loaded by GRUB via the
devicetree command to the firmware to execute fix-ups and memory
reservations.

U-Boot v2020.04-rc1 provides an EFI protocol for this purpose which has
been defined in the EFI_DT_FIXUP_PROTOCOL specification [1].

With the first patch in the series the devicetree command is enhanced. It
checks if an instance of the EFI_DT_FIXUP_PROTOCOL is available. If yes,
the Fixup() method of the protocol is called when the boot command is
invoked. The fixed-up device-tree is passed to the operating system as
EFI configuration table.

The second patch adjusts the 10_linux template for grub-mkconfig. If
GRUB_LOAD_DEVICETREE=true in /etc/default/grub, it looks for file
dtb-${version} matching the Linux version. If the file (or file dtb as
fallback) is found, a devicetree command is added to grub.cfg.

[1] EFI_DT_FIXUP_PROTOCOL specification
    https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL

Heinrich Schuchardt (2):
  efi: EFI Device Tree Fixup Protocol
  10_linux: support loading device trees

 docs/grub.texi             |  6 ++++++
 grub-core/loader/efi/fdt.c | 35 ++++++++++++++++++++++++++++++++++-
 include/grub/efi/api.h     | 22 ++++++++++++++++++++++
 util/grub-mkconfig.in      |  1 +
 util/grub.d/10_linux.in    | 23 +++++++++++++++++++++++
 5 files changed, 86 insertions(+), 1 deletion(-)

--
2.30.0

[PATCH 1/2] efi: EFI Device Tree Fixup Protocol

[Heinrich Schuchardt]

Device-trees are used to convey information about hardware to the operating
system. Some of the properties are only known at boot time. (One example of
such a property is the number of the boot hart on RISC-V systems.) Therefore
the firmware applies fix-ups to the original device-tree. Some nodes and
properties are added or altered.

When using GRUB's device-tree command the same fix-ups have to be applied.
The EFI Device Tree Fixup Protocol allows to pass the loaded device tree
to the firmware for this purpose.

The protocol can

* add nodes and update properties
* reserve memory according to the /reserved-memory node and the memory
  reservation block
* install the device-tree as configuration table

With the patch GRUB checks if the protocol is installed and invokes it if
available.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 grub-core/loader/efi/fdt.c | 35 ++++++++++++++++++++++++++++++++++-
 include/grub/efi/api.h     | 22 ++++++++++++++++++++++
 2 files changed, 56 insertions(+), 1 deletion(-)

diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
index 57ee81686..58e95eb05 100644
--- a/grub-core/loader/efi/fdt.c
+++ b/grub-core/loader/efi/fdt.c
@@ -29,6 +29,7 @@

 static void *loaded_fdt;
 static void *fdt;
+static grub_efi_guid_t dt_fixup_guid = GRUB_EFI_DT_FIXUP_PROTOCOL_GUID;

 #define FDT_ADDR_CELLS_STRING "#address-cells"
 #define FDT_SIZE_CELLS_STRING "#size-cells"
@@ -36,6 +37,38 @@ static void *fdt;
                              sizeof (FDT_ADDR_CELLS_STRING) + \
                              sizeof (FDT_SIZE_CELLS_STRING))

+static void *grub_fdt_fixup (void)
+{
+  grub_efi_dt_fixup_t *dt_fixup_prot;
+  grub_efi_uintn_t size = 0;
+  grub_efi_status_t status;
+  void *fixup_fdt;
+
+  dt_fixup_prot = grub_efi_locate_protocol (&dt_fixup_guid, 0);
+  if (! dt_fixup_prot)
+    return loaded_fdt;
+
+  grub_dprintf ("linux", "EFI_DT_FIXUP_PROTOCOL available\n");
+
+  status = efi_call_4 (dt_fixup_prot->fixup, dt_fixup_prot, loaded_fdt, &size,
+		       GRUB_EFI_DT_APPLY_FIXUPS | GRUB_EFI_DT_RESERVE_MEMORY);
+  if (status != GRUB_EFI_BUFFER_TOO_SMALL)
+    return loaded_fdt;
+
+  fixup_fdt = grub_realloc (loaded_fdt, size);
+  if (!fixup_fdt)
+    return loaded_fdt;
+  loaded_fdt = fixup_fdt;
+
+  status = efi_call_4 (dt_fixup_prot->fixup, dt_fixup_prot, loaded_fdt, &size,
+		       GRUB_EFI_DT_APPLY_FIXUPS | GRUB_EFI_DT_RESERVE_MEMORY);
+
+  if (status == GRUB_EFI_SUCCESS)
+    grub_dprintf ("linux", "Device tree fixed up via EFI_DT_FIXUP_PROTOCOL\n");
+
+  return loaded_fdt;
+}
+
 void *
 grub_fdt_load (grub_size_t additional_size)
 {
@@ -49,7 +82,7 @@ grub_fdt_load (grub_size_t additional_size)
     }

   if (loaded_fdt)
-    raw_fdt = loaded_fdt;
+    raw_fdt = grub_fdt_fixup();
   else
     raw_fdt = grub_efi_get_firmware_fdt();

diff --git a/include/grub/efi/api.h b/include/grub/efi/api.h
index 34109861a..8101df0df 100644
--- a/include/grub/efi/api.h
+++ b/include/grub/efi/api.h
@@ -334,6 +334,11 @@
     { 0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, 0xe0 } \
   }

+#define GRUB_EFI_DT_FIXUP_PROTOCOL_GUID \
+  { 0xe617d64c, 0xfe08, 0x46da, \
+    { 0xf4, 0xdc, 0xbb, 0xd5, 0x87, 0x0c, 0x73, 0x00 } \
+  }
+
 #define GRUB_EFI_VENDOR_APPLE_GUID \
   { 0x2B0585EB, 0xD8B8, 0x49A9,	\
     { 0x8B, 0x8C, 0xE2, 0x1B, 0x01, 0xAE, 0xF2, 0xB7 } \
@@ -1641,6 +1646,13 @@ enum
     GRUB_EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST = 0x10,
   };

+enum
+  {
+    GRUB_EFI_DT_APPLY_FIXUPS		= 0x01,
+    GRUB_EFI_DT_RESERVE_MEMORY		= 0x02,
+    GRUB_EFI_EFI_DT_INSTALL_TABLE	= 0x04,
+  };
+
 struct grub_efi_simple_network
 {
   grub_uint64_t revision;
@@ -1704,6 +1716,16 @@ struct grub_efi_block_io
 };
 typedef struct grub_efi_block_io grub_efi_block_io_t;

+struct grub_efi_dt_fixup
+{
+  grub_efi_uint64_t revision;
+  grub_efi_status_t (*fixup) (struct grub_efi_dt_fixup *this,
+			      void *fdt,
+			      grub_efi_uintn_t *buffer_size,
+			      grub_uint32_t flags);
+};
+typedef struct grub_efi_dt_fixup grub_efi_dt_fixup_t;
+
 struct grub_efi_shim_lock_protocol
 {
   grub_efi_status_t (*verify) (void *buffer, grub_uint32_t size);
--
2.30.0

[PATCH 2/2] 10_linux: support loading device trees

[Heinrich Schuchardt]

If in /etc/default/grub GRUB_LOAD_DEVICE_TREE=true, the boot directory
is scanned for files dtb-${version} and dtb. If such a file exists,
a devicetree command is added per Linux menu entry.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 docs/grub.texi          |  6 ++++++
 util/grub-mkconfig.in   |  1 +
 util/grub.d/10_linux.in | 23 +++++++++++++++++++++++
 3 files changed, 30 insertions(+)

diff --git a/docs/grub.texi b/docs/grub.texi
index eeac9b2ce..64cf95e6f 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -1560,6 +1560,12 @@ This option may be set to a list of GRUB module names separated by spaces.
 Each module will be loaded as early as possible, at the start of
 @file{grub.cfg}.

+@item GRUB_LOAD_DEVICE_TREE
+If this option is set to @samp{true}, a devicetree command will be added
+to the Linux menu entries in @file{grub.cfg}. Device-trees require fix-ups
+by the firmware. You should use this option only if your firmware supports
+the EFI Device Tree Fixup Protocol.
+
 @end table

 The following options are still accepted for compatibility with existing
diff --git a/util/grub-mkconfig.in b/util/grub-mkconfig.in
index d3e879b8e..3d7fd54f3 100644
--- a/util/grub-mkconfig.in
+++ b/util/grub-mkconfig.in
@@ -230,6 +230,7 @@ export GRUB_DEFAULT \
   GRUB_CMDLINE_GNUMACH \
   GRUB_EARLY_INITRD_LINUX_CUSTOM \
   GRUB_EARLY_INITRD_LINUX_STOCK \
+  GRUB_LOAD_DEVICETREE \
   GRUB_TERMINAL_INPUT \
   GRUB_TERMINAL_OUTPUT \
   GRUB_SERIAL_COMMAND \
diff --git a/util/grub.d/10_linux.in b/util/grub.d/10_linux.in
index e8b01c0d0..15bc26ba8 100644
--- a/util/grub.d/10_linux.in
+++ b/util/grub.d/10_linux.in
@@ -143,6 +143,15 @@ linux_entry ()
 	echo	'$(echo "$message" | grub_quote)'
 	linux	${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args}
 EOF
+  if [ "x${GRUB_LOAD_DEVICETREE}" = "xtrue" ]; then
+    if test -n "${dtb}" ; then
+      message="$(gettext_printf "Loading device tree ...")"
+      sed "s/^/$submenu_indentation/" << EOF
+	echo	'$(echo "$message" | grub_quote)'
+	devicetree	${rel_dirname}/${dtb}
+EOF
+    fi
+  fi
   if test -n "${initrd}" ; then
     # TRANSLATORS: ramdisk isn't identifier. Should be translated.
     message="$(gettext_printf "Loading initial ramdisk ...")"
@@ -244,6 +253,20 @@ while [ "x$list" != "x" ] ; do
     fi
   done

+  if [ "x${GRUB_LOAD_DEVICETREE}" = "xtrue" ]; then
+    dtb=
+    for i in "dtb-${version}" "dtb" ; do
+      if test -e "${dirname}/${i}" ; then
+        dtb="${i}"
+        break
+      fi
+    done
+
+    if test -n "${dtb}" ; then
+      gettext_printf "Found dtb: %s\n" "${dirname}/${dtb}" >&2
+    fi
+  fi
+
   initramfs=
   if test -n "${config}" ; then
       initramfs=`grep CONFIG_INITRAMFS_SOURCE= "${config}" | cut -f2 -d= | tr -d \"`
--
2.30.0

Re: [PATCH 0/2] efi: device tree fix-up

[Heinrich Schuchardt]

Hello Daniel,

I sent this series when you were in the middle of getting GRUB-2.06 out. 
Unfortunately I did not see any feedback yet. Could you, please, share 
your thoughts.

Best regards

Heinrich

On 04.02.21 14:15, Heinrich Schuchardt wrote:
> Operating systems need a description of the hardware. This description can
> either be supplied via ACPI tables or via device-trees. On the ARM
> architecture ACPI tables are not avaialable for most devices.
> 
> In an ideal world device-trees would be defined once by the hardware
> manufacturer and would not be subject to change.
> 
> In reality device-trees or subject to frequent changes. Linux has a long
> record of breaking forward and backwards compatibility between device-
> trees and the kernel. So for booting it is wise to use the specific device-
> tree that comes with the operation system. This requires reading the
> device-tree from file.
> 
> One approach is to leave loading the device-tree file to the firmware. This
> works fine if the firmware is loading the triple of kernel, initrd, and
> device-tree. This is what Debian does with the flash-kernel package. It
> provides a boot script for U-Boot that loads the most recent kernel,
> initrd, and device-tree.
> 
> Before passing the device-tree to the operating as an EFI configuration
> table the firmware goes through the following steps:
> 
> * Fix-ups are applied to the device-tree. Examples of the changes include
>    the memory size and the RISC-V boot hart. Without the changes the
>    operating system may not boot at all or crash later.
> 
> * Memory reservations are added to the memory map according to the
>    /reserved-memory node and the memory reservation block of the
>    device-tree. Without these reservations the operating system may crash.
> 
> When using GRUB it is not known beforehand which operating system the user
> will choose. To guarantee compatibility with the operating system GRUB has
> to take control of the device-tree loading.
> 
> GRUB has a devicetree command to load a device-tree which is then passed as
> EFI configuration table to the operating systems. But GRUB lacks the
> information needed to apply fix-ups to the device-tree. Further memory
> reservations are not executed.
> 
> What is needed is to pass the device-tree loaded by GRUB via the
> devicetree command to the firmware to execute fix-ups and memory
> reservations.
> 
> U-Boot v2020.04-rc1 provides an EFI protocol for this purpose which has
> been defined in the EFI_DT_FIXUP_PROTOCOL specification [1].
> 
> With the first patch in the series the devicetree command is enhanced. It
> checks if an instance of the EFI_DT_FIXUP_PROTOCOL is available. If yes,
> the Fixup() method of the protocol is called when the boot command is
> invoked. The fixed-up device-tree is passed to the operating system as
> EFI configuration table.
> 
> The second patch adjusts the 10_linux template for grub-mkconfig. If
> GRUB_LOAD_DEVICETREE=true in /etc/default/grub, it looks for file
> dtb-${version} matching the Linux version. If the file (or file dtb as
> fallback) is found, a devicetree command is added to grub.cfg.
> 
> [1] EFI_DT_FIXUP_PROTOCOL specification
>      https://github.com/U-Boot-EFI/EFI_DT_FIXUP_PROTOCOL
> 
> Heinrich Schuchardt (2):
>    efi: EFI Device Tree Fixup Protocol
>    10_linux: support loading device trees
> 
>   docs/grub.texi             |  6 ++++++
>   grub-core/loader/efi/fdt.c | 35 ++++++++++++++++++++++++++++++++++-
>   include/grub/efi/api.h     | 22 ++++++++++++++++++++++
>   util/grub-mkconfig.in      |  1 +
>   util/grub.d/10_linux.in    | 23 +++++++++++++++++++++++
>   5 files changed, 86 insertions(+), 1 deletion(-)
> 
> --
> 2.30.0
> 

Re: [PATCH 0/2] efi: device tree fix-up

[Daniel Kiper]

Hi Heinrich,

On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
> Hello Daniel,
>
> I sent this series when you were in the middle of getting GRUB-2.06 out.
> Unfortunately I did not see any feedback yet. Could you, please, share your
> thoughts.

Sure, I will try to do that next week.

Daniel

Re: [PATCH 0/2] efi: device tree fix-up

[Heinrich Schuchardt]

On 8/2/21 5:18 PM, Daniel Kiper wrote:
> Hi Heinrich,
> 
> On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
>> Hello Daniel,
>>
>> I sent this series when you were in the middle of getting GRUB-2.06 out.
>> Unfortunately I did not see any feedback yet. Could you, please, share your
>> thoughts.
> 
> Sure, I will try to do that next week.
> 
> Daniel
> 

The series conflicts with the RISC-V series patch
"linux: ignore FDT unless we need to modify it"
https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html

My priority would be to have the RISC-V series merged first. Then I can 
rebase my series upon it.

But anyhow feedback for the concept of devicetree fixups will be helpful.

Best regards

Heinrich

Re: [PATCH 0/2] efi: device tree fix-up

[Daniel Kiper]

On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
> On 8/2/21 5:18 PM, Daniel Kiper wrote:
> > Hi Heinrich,
> >
> > On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
> > > Hello Daniel,
> > >
> > > I sent this series when you were in the middle of getting GRUB-2.06 out.
> > > Unfortunately I did not see any feedback yet. Could you, please, share your
> > > thoughts.
> >
> > Sure, I will try to do that next week.
> >
> > Daniel
> >
>
> The series conflicts with the RISC-V series patch
> "linux: ignore FDT unless we need to modify it"
> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html
>
> My priority would be to have the RISC-V series merged first. Then I can
> rebase my series upon it.

OK...

> But anyhow feedback for the concept of devicetree fixups will be helpful.

At first sight it looks good to me. Though it would be nice if somebody
more familiar with DT than I would check the patches too. Leif?

Heinrich, are you aware that devicetree command is disabled when UEFI
Secure Boot is enabled? I think you should take into account that
somehow in the next version of the patches.

Daniel

Re: [PATCH 0/2] efi: device tree fix-up

[Heinrich Schuchardt]

Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper <dkiper@net-space.pl>:
>On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
>> On 8/2/21 5:18 PM, Daniel Kiper wrote:
>> > Hi Heinrich,
>> >
>> > On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
>> > > Hello Daniel,
>> > >
>> > > I sent this series when you were in the middle of getting GRUB-2.06 out.
>> > > Unfortunately I did not see any feedback yet. Could you, please, share your
>> > > thoughts.
>> >
>> > Sure, I will try to do that next week.
>> >
>> > Daniel
>> >
>>
>> The series conflicts with the RISC-V series patch
>> "linux: ignore FDT unless we need to modify it"
>> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html
>>
>> My priority would be to have the RISC-V series merged first. Then I can
>> rebase my series upon it.
>
>OK...
>
>> But anyhow feedback for the concept of devicetree fixups will be helpful.
>
>At first sight it looks good to me. Though it would be nice if somebody
>more familiar with DT than I would check the patches too. Leif?
>
>Heinrich, are you aware that devicetree command is disabled when UEFI
>Secure Boot is enabled? I think you should take into account that
>somehow in the next version of the patches.

I wonder why the devicetree command is disabled while the initrd command is not. For an attacker the initrd is much more attractive.

For both the initrd and the dt it would be good to introduce signatures.

A devicetree before fixups is invariant and could be signed together with the kernel and checked against shims certificate database.

Best regards

Heinrich

Re: [PATCH 0/2] efi: device tree fix-up

[Ard Biesheuvel]

On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper <dkiper@net-space.pl>:
> >On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
> >> On 8/2/21 5:18 PM, Daniel Kiper wrote:
> >> > Hi Heinrich,
> >> >
> >> > On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
> >> > > Hello Daniel,
> >> > >
> >> > > I sent this series when you were in the middle of getting GRUB-2.06 out.
> >> > > Unfortunately I did not see any feedback yet. Could you, please, share your
> >> > > thoughts.
> >> >
> >> > Sure, I will try to do that next week.
> >> >
> >> > Daniel
> >> >
> >>
> >> The series conflicts with the RISC-V series patch
> >> "linux: ignore FDT unless we need to modify it"
> >> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html
> >>
> >> My priority would be to have the RISC-V series merged first. Then I can
> >> rebase my series upon it.
> >
> >OK...
> >
> >> But anyhow feedback for the concept of devicetree fixups will be helpful.
> >
> >At first sight it looks good to me. Though it would be nice if somebody
> >more familiar with DT than I would check the patches too. Leif?
> >
> >Heinrich, are you aware that devicetree command is disabled when UEFI
> >Secure Boot is enabled? I think you should take into account that
> >somehow in the next version of the patches.
>
> I wonder why the devicetree command is disabled while the initrd command is not. For an attacker the initrd is much more attractive.
>

The initrd is user space, whereas the DT affects the internal plumbing
of the kernel.

> For both the initrd and the dt it would be good to introduce signatures.
>

How the kernel authenticates the initrd is out of scope for secure boot.

> A devicetree before fixups is invariant and could be signed together with the kernel and checked against shims certificate database.
>
> Best regards
>
> Heinrich
>

Re: [PATCH 0/2] efi: device tree fix-up

[Heinrich Schuchardt]

On 8/16/21 9:04 AM, Ard Biesheuvel wrote:
> On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper <dkiper@net-space.pl>:
>>> On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
>>>> On 8/2/21 5:18 PM, Daniel Kiper wrote:
>>>>> Hi Heinrich,
>>>>>
>>>>> On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
>>>>>> Hello Daniel,
>>>>>>
>>>>>> I sent this series when you were in the middle of getting GRUB-2.06 out.
>>>>>> Unfortunately I did not see any feedback yet. Could you, please, share your
>>>>>> thoughts.
>>>>>
>>>>> Sure, I will try to do that next week.
>>>>>
>>>>> Daniel
>>>>>
>>>>
>>>> The series conflicts with the RISC-V series patch
>>>> "linux: ignore FDT unless we need to modify it"
>>>> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html
>>>>
>>>> My priority would be to have the RISC-V series merged first. Then I can
>>>> rebase my series upon it.
>>>
>>> OK...
>>>
>>>> But anyhow feedback for the concept of devicetree fixups will be helpful.
>>>
>>> At first sight it looks good to me. Though it would be nice if somebody
>>> more familiar with DT than I would check the patches too. Leif?
>>>
>>> Heinrich, are you aware that devicetree command is disabled when UEFI
>>> Secure Boot is enabled? I think you should take into account that
>>> somehow in the next version of the patches.
>>
>> I wonder why the devicetree command is disabled while the initrd command is not. For an attacker the initrd is much more attractive.
>>
> 
> The initrd is user space, whereas the DT affects the internal plumbing
> of the kernel.

If you are able to modify initrd, you will gain root access. Who would 
call this secure?

> 
>> For both the initrd and the dt it would be good to introduce signatures.
>>
> 
> How the kernel authenticates the initrd is out of scope for secure boot.

Does it authenticate initrd?

Best regards

Heinrich

> 
>> A devicetree before fixups is invariant and could be signed together with the kernel and checked against shims certificate database.
>>
>> Best regards
>>
>> Heinrich
>>

Re: [PATCH 0/2] efi: device tree fix-up

[Ard Biesheuvel]

On Mon, 16 Aug 2021 at 10:58, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> On 8/16/21 9:04 AM, Ard Biesheuvel wrote:
> > On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> Am 13. August 2021 22:22:49 MESZ schrieb Daniel Kiper <dkiper@net-space.pl>:
> >>> On Fri, Aug 13, 2021 at 06:22:49PM +0200, Heinrich Schuchardt wrote:
> >>>> On 8/2/21 5:18 PM, Daniel Kiper wrote:
> >>>>> Hi Heinrich,
> >>>>>
> >>>>> On Mon, Aug 02, 2021 at 03:00:55PM +0200, Heinrich Schuchardt wrote:
> >>>>>> Hello Daniel,
> >>>>>>
> >>>>>> I sent this series when you were in the middle of getting GRUB-2.06 out.
> >>>>>> Unfortunately I did not see any feedback yet. Could you, please, share your
> >>>>>> thoughts.
> >>>>>
> >>>>> Sure, I will try to do that next week.
> >>>>>
> >>>>> Daniel
> >>>>>
> >>>>
> >>>> The series conflicts with the RISC-V series patch
> >>>> "linux: ignore FDT unless we need to modify it"
> >>>> https://lists.gnu.org/archive/html/grub-devel/2021-06/msg00010.html
> >>>>
> >>>> My priority would be to have the RISC-V series merged first. Then I can
> >>>> rebase my series upon it.
> >>>
> >>> OK...
> >>>
> >>>> But anyhow feedback for the concept of devicetree fixups will be helpful.
> >>>
> >>> At first sight it looks good to me. Though it would be nice if somebody
> >>> more familiar with DT than I would check the patches too. Leif?
> >>>
> >>> Heinrich, are you aware that devicetree command is disabled when UEFI
> >>> Secure Boot is enabled? I think you should take into account that
> >>> somehow in the next version of the patches.
> >>
> >> I wonder why the devicetree command is disabled while the initrd command is not. For an attacker the initrd is much more attractive.
> >>
> >
> > The initrd is user space, whereas the DT affects the internal plumbing
> > of the kernel.
>
> If you are able to modify initrd, you will gain root access. Who would
> call this secure?
>

Gaining root access is very different from having direct control over
code which runs with kernel privileges.

initrd signing may be problematic in distro deployment scenarios,
where initrd measurements involving a TPM are more suitable. The
reason is that the initrd is generated on the target, and so the
signing key should be available on the target as well, which is
obviously not feasible for distros.

> >
> >> For both the initrd and the dt it would be good to introduce signatures.
> >>
> >
> > How the kernel authenticates the initrd is out of scope for secure boot.
>
> Does it authenticate initrd?

I don't understand the question. Secure boot can be deployed in many
different ways: some deployments may decide to authenticate the initrd
by relying on public key crypto, others may tie the root filesystem
decryption key to a successful measurement of the initrd into the TPM.