Re: [edk2-devel] measurement to command-line/initrd for loading kernel via -kernel option

["Ard Biesheuvel" <ardb@kernel.org>]

On Tue, 20 Sept 2022 at 15:44, James Bottomley <jejb@linux.ibm.com> wrote:
>
> [pjones added because he's done a huge amount of work to get shim to
> measure stuff correctly]
> On Tue, 2022-09-20 at 13:24 +0000, Lu, Ken wrote:
> > > > Hi Ard, I think it better let creator to measure instead of
> > > > consumer to measure
> > > like today's implementation in grub[1]. The creator here means who
> > > load/create it. In direct boot, it is OVMF read kernel command line
> > > and initrd image. In grub boot, it is grub2.  Because the number of
> > > consumer like Linux kernel could be more than 1, but the creator is
> > > single.
> > >
> > > I agree with this in principle.
> >
> > So you are not against to do measurement in loader like current does
> > in grub and OVMF, correct? I think it is OK even do twice
> > measurements on cmdline and initrd for the corner case.
> > In past month, I just submit patch in grub to do CC measurement at
> > https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4c76565b6cb885b7e144dc27f3612066844e2d19
>
> Wait, we have two separate cases: when the kernel boots via grub, which
> is not direct boot and grub measures eveything and when we do direct
> boot and grub is not involved.  Ideally, we should be able to get to a
> stable PCR8,9 for measurement, but grub isn't hugely helpful there
> since it dumps every grub command into the PCRs so direct boot can
> never match that whatever the EFI stub does.  The TCG spec isn't very
> helpful on some things, but it is very clear that once you've measured
> something, you don't measure it again, so we do want to avoid measuring
> the same thing twice.
>

Of course, in a vertically integrated boot stack design, you would
never measure the same thing twice.

However, we have created such a spectacular mess for ourselves, with
loaders that call load/startimage, loaders that call loadimage but not
startimage, loaders that call neither, loaders that measure the initrd
and command line but not the kernel, loaders that measure everything,,
loaders that only are broken unless they were invoked by shim etc etc,
that we simply cannot rely on anything from the EFI stub's point of
view.

So to me, measuring the initrd and command line from the EFI stub
seems like a reasonable (if somewhat belt-and-braces) approach in this
case.

> >
> > > However, there are corner cases that we would like
> > > to cover, such as booting Linux from the EFI shell.
> >
> > I remember Bottomley or someone mentioned to use CONFIG_CMDLINE and
> > CONFIG_INITRAMFS_SOURCE, such as
> > https://blog.decentriq.com/swiss-cheese-to-cheddar-securing-amd-sev-snp-early-boot-2/
> > for this corner case, especially for confidential container use case
> > without grub.
>
> Well, you know, when you talk of the devil he bites your heels ...
>
> Part of the problem is that if you look at the protocol, the LoadImage
> measurement seems not to measure the command line.  If we can fix that,
> then we can get something that will work both with direct boot (cmdline
> is passed to the image) as well as direct executions of the kernel from
> the EFI shell.  I think that's what we should aim for.  It would be too
> disruptive now to try to get grub also to measure thisorrectly.
>
> I think the key is agreeing with TCG that the argument list of an
> executable, loaded by LoadImage should be measured separately.  There
> are parts of the spec that hint at this, but by and large it seems to
> assume that the measurement of the boot volume entry (which does
> contain the command line [usually empty] is sufficient).
>

I think this is something that should be fixed. Measuring the Boot####
variable that the BDS chose to boot instead of what LoadImage()
actually consumes seems like a huge oversight to me.