Re: [PATCH] tpm: Don't propagate measurement failures to the verifiers layer

[James Bottomley]

On Sun, 2021-02-28 at 23:42 +0100, Javier Martinez Canillas wrote:
> On 2/28/21 7:25 PM, James Bottomley wrote:
> > On Sun, 2021-02-28 at 18:58 +0100, Javier Martinez Canillas wrote:
> 
> [snip]
> 
> > > I don't see how that would be the case. For anyone doing measured
> > > boot, they can check the TPM event log to verify what has been
> > > measured during the boot path.
> > 
> > No, they can't ... that's the point, the log will no longer verify
> > because of the failure.  That's why this is a break in the
> > measurement
> 
> Yes, my point was that the attestation software can verify if there
> are any gaps in the TPM logs due the failure to measure the boot
> components.

Right, but there's no way to match the log pieces to any value in the
PCRs: that's why verification fails.

> > chain.  If you're requesting verified boot, which is an opt-in by
> > inserting the TPM grub module, this is an unrecoverable failure.
> > 
> 
> But it's not really optional, since most distros disable module
> loading in GRUB if Secure Boot is enabled. Instead, a curated list of
> modules are built-in the signed EFI binary. The tpm module is one of
> these that we include in Fedora.

Heh, well, don't get me started on how the different distributions
package grub differently ... it would be really nice if everyone could
agree on the right, or at least reasonable, way of doing it.  However,
my understanding, from having to do an annoying amount of boot
debugging on various systems, is that you all package the grub elements
to somewhere in the host root fileystem.  Then you have a grub
installer which picks the necessary elements out of the root filesystem
and installs them in the EFI partition, which may or may not be
permanently mounted.

The problem, as you see it, is that the EFI version of grub-mkimage
creates a unitary PE/COFF binary which consists of the core plus the
curated modules and which must be secure boot signed in its entirety. 
This signed unitary binary is usually what is installed by the grub
installer.

The reason you don't like modules for secure boot is that the grub
module system, at present, is unsigned and thus violates the secure
boot trust model which requires all code executed in the boot sequence
to be approved either by the machine owner or the software supplier. 
Incorporating a module signature system, like the kernel has, is orders
of magnitude more effort than you want to invest in external patching,
and likely would take several developer lifetimes to get upstream.

Hopefully, I have all this right so far?

How about a more simple solution: you sign two grub unitary EFI
binaries, one of which does measured boot and one of which doesn't. 
Your installer is already config file driven, so by default it would
install the measured boot one, but if there's a failure you can tell
the user to add the config option to install the unmeasured boot one
... this could also be useful for various other situations where you
want secure but not measured boot?  I'm fairly certain you could design
a distro installer test for the problem and thus always install a
working system.  There's no security issue because anyone who does
attested measured boot will instantly detect someone booting via the
signed unmeasured boot grub.

Note: I'm certainly not presenting this as the optimal solution, merely
the least effort solution that looks like it will work with the current
grub upstream.

James