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.