* [PATCH 0/2] efi: device tree fix-up
@ 2021-02-04 13:15 Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 1/2] efi: EFI Device Tree Fixup Protocol Heinrich Schuchardt
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-02-04 13:15 UTC (permalink / raw)
To: Daniel Kiper; +Cc: Leif Lindholm, Grant Likely, grub-devel, 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] efi: EFI Device Tree Fixup Protocol
2021-02-04 13:15 [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
@ 2021-02-04 13:15 ` Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 2/2] 10_linux: support loading device trees Heinrich Schuchardt
2021-08-02 13:00 ` [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2 siblings, 0 replies; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-02-04 13:15 UTC (permalink / raw)
To: Daniel Kiper; +Cc: Leif Lindholm, Grant Likely, grub-devel, 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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/2] 10_linux: support loading device trees
2021-02-04 13:15 [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 1/2] efi: EFI Device Tree Fixup Protocol Heinrich Schuchardt
@ 2021-02-04 13:15 ` Heinrich Schuchardt
2021-08-02 13:00 ` [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2 siblings, 0 replies; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-02-04 13:15 UTC (permalink / raw)
To: Daniel Kiper; +Cc: Leif Lindholm, Grant Likely, grub-devel, 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
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-02-04 13:15 [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 1/2] efi: EFI Device Tree Fixup Protocol Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 2/2] 10_linux: support loading device trees Heinrich Schuchardt
@ 2021-08-02 13:00 ` Heinrich Schuchardt
2021-08-02 15:18 ` Daniel Kiper
2 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-08-02 13:00 UTC (permalink / raw)
To: Daniel Kiper; +Cc: Leif Lindholm, Grant Likely, grub-devel, 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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-02 13:00 ` [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
@ 2021-08-02 15:18 ` Daniel Kiper
2021-08-13 16:22 ` Heinrich Schuchardt
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Kiper @ 2021-08-02 15:18 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Daniel Kiper, Leif Lindholm, Grant Likely, grub-devel,
Heinrich Schuchardt
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-02 15:18 ` Daniel Kiper
@ 2021-08-13 16:22 ` Heinrich Schuchardt
2021-08-13 20:22 ` Daniel Kiper
0 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-08-13 16:22 UTC (permalink / raw)
To: Daniel Kiper
Cc: Daniel Kiper, Leif Lindholm, Grant Likely, grub-devel,
Heinrich Schuchardt, Ard Biesheuvel, Nikita Ermakov
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-13 16:22 ` Heinrich Schuchardt
@ 2021-08-13 20:22 ` Daniel Kiper
2021-08-13 22:38 ` Heinrich Schuchardt
0 siblings, 1 reply; 11+ messages in thread
From: Daniel Kiper @ 2021-08-13 20:22 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Leif Lindholm, Grant Likely, grub-devel, Heinrich Schuchardt,
Ard Biesheuvel, Nikita Ermakov
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-13 20:22 ` Daniel Kiper
@ 2021-08-13 22:38 ` Heinrich Schuchardt
2021-08-16 7:04 ` Ard Biesheuvel
0 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-08-13 22:38 UTC (permalink / raw)
To: Daniel Kiper, Heinrich Schuchardt
Cc: Leif Lindholm, Grant Likely, grub-devel, Ard Biesheuvel, Nikita Ermakov
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-13 22:38 ` Heinrich Schuchardt
@ 2021-08-16 7:04 ` Ard Biesheuvel
2021-08-16 8:58 ` Heinrich Schuchardt
0 siblings, 1 reply; 11+ messages in thread
From: Ard Biesheuvel @ 2021-08-16 7:04 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Daniel Kiper, Heinrich Schuchardt, Leif Lindholm, Grant Likely,
The development of GNU GRUB, Nikita Ermakov
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-16 7:04 ` Ard Biesheuvel
@ 2021-08-16 8:58 ` Heinrich Schuchardt
2021-08-16 9:26 ` Ard Biesheuvel
0 siblings, 1 reply; 11+ messages in thread
From: Heinrich Schuchardt @ 2021-08-16 8:58 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Daniel Kiper, Leif Lindholm, Grant Likely,
The development of GNU GRUB, Nikita Ermakov, 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
>>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 0/2] efi: device tree fix-up
2021-08-16 8:58 ` Heinrich Schuchardt
@ 2021-08-16 9:26 ` Ard Biesheuvel
0 siblings, 0 replies; 11+ messages in thread
From: Ard Biesheuvel @ 2021-08-16 9:26 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Daniel Kiper, Leif Lindholm, Grant Likely,
The development of GNU GRUB, Nikita Ermakov, Heinrich Schuchardt
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-08-16 9:26 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-04 13:15 [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 1/2] efi: EFI Device Tree Fixup Protocol Heinrich Schuchardt
2021-02-04 13:15 ` [PATCH 2/2] 10_linux: support loading device trees Heinrich Schuchardt
2021-08-02 13:00 ` [PATCH 0/2] efi: device tree fix-up Heinrich Schuchardt
2021-08-02 15:18 ` Daniel Kiper
2021-08-13 16:22 ` Heinrich Schuchardt
2021-08-13 20:22 ` Daniel Kiper
2021-08-13 22:38 ` Heinrich Schuchardt
2021-08-16 7:04 ` Ard Biesheuvel
2021-08-16 8:58 ` Heinrich Schuchardt
2021-08-16 9:26 ` Ard Biesheuvel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.