From: Mimi Zohar [mailto:zohar@linux.ibm.com]
Sent: Tuesday, June 16, 2020 8:11 PM
On Tue, 2020-06-16 at 17:29 +0000, Roberto Sassu wrote:

quoted

quoted

From: James Bottomley [mailto:jejb@linux.ibm.com]
Sent: Friday, June 12, 2020 7:14 PM
On Fri, 2020-06-12 at 15:11 +0000, Roberto Sassu wrote:

quoted

with recent patches, boot_aggregate can be calculated from non-SHA1
PCR banks. I would replace with:

Extend cumulative digest over ...

Given that with this patch boot_aggregate is calculated differently,
shouldn't we call it boot_aggregate_v2 and enable it with a new
option?

So here's the problem: if your current grub doesn't do any TPM
extensions (as most don't), then the two boot aggregates are the same
because PCRs 8 and 9 are zero and there's a test that doesn't add them
to the aggregate if they are zero.  For these people its a nop so we
shouldn't force them to choose a different version of the same thing.

If, however, you're on a distribution where grub is automatically
measuring the kernel and command line into PCRs 8 and 9 (I think

Fedora

quoted

quoted

32 does this), your boot aggregate will change.  It strikes me in that
case we can call this a bug fix, since the boot aggregate isn't
properly binding to the previous measurements without PCRs 8 and 9.

In

quoted

quoted

this case, do we want to allow people to select an option which doesn't
properly bind the IMA log to the boot measurements?  That sounds like

a

quoted

quoted

security hole to me.

However, since it causes a user visible difference in the grub already
measures case, do you have a current use case that would be affected?
As in are lots of people already running a distro with the TPM grub
updates and relying on the old boot aggregate?

I don't know how many people would be affected. However, if an
attestation tool processes both measurement lists from unpatched

kernels

quoted

and patched kernels, keeping the same name would be a problem as it
cannot be determined from the measurement list how boot_aggregate
was calculated.

Anyway, I agree this should be fixed. At least, I suggest to add a Fixes tag,
to ensure that this patch is applied to all stable kernels.

The boot aggregate on existing systems would be sha1.  Does it make
sense to limit this change to larger digests?  Anyone backporting
support for larger digests would also need to backport this change as
well.

Yes, it would be a safe choice.

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Li Jian, Shi Yanli