[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Heinrich Schuchardt
Subject: Re: [PATCH 0/2] efi: device tree fix-up
Date: Mon, 16 Aug 2021 10:58:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 8/16/21 9:04 AM, Ard Biesheuvel wrote:
On Sat, 14 Aug 2021 at 00:39, Heinrich Schuchardt <> wrote:

Am 13. August 2021 22:22:49 MESZ schrieb 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

Sure, I will try to do that next week.


The series conflicts with the RISC-V series patch
"linux: ignore FDT unless we need to modify it"

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.

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


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

Best regards


reply via email to

[Prev in Thread] Current Thread [Next in Thread]