On Fri, 2020-12-11 at 09:46 -0800, James Bottomley wrote:

On Fri, 2020-12-11 at 06:01 -0500, Mimi Zohar wrote:

quoted

On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote:

quoted

On 2020-11-29 08:17:38, Mimi Zohar wrote:

quoted

Hi Sasha,

On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote:

quoted

On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote:

quoted

Hi Sasha,

On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote:

quoted

From: Maurizio Drocco <redacted>

[ Upstream commit 20c59ce010f84300f6c655d32db2610d3433f85c
]

Registers 8-9 are used to store measurements of the kernel
and its command line (e.g., grub2 bootloader with tpm
module enabled). IMA should include them in the boot
aggregate. Registers 8-9 should be only included in non-
SHA1 digests to avoid ambiguity.

Prior to Linux 5.8, the SHA1 template data hashes were padded
before being extended into the TPM.  Support for calculating
and extending the per TPM bank template data digests is only
being upstreamed in Linux 5.8.

How will attestation servers know whether to include PCRs 8 &
9 in the the boot_aggregate calculation?  Now, there is a
direct relationship between the template data SHA1 padded
digest not including PCRs 8 & 9, and the new per TPM bank
template data digest including them.

Got it, I'll drop it then, thank you!

After re-thinking this over, I realized that the attestation
server can verify the "boot_aggregate" based on the quoted PCRs
without knowing whether padded SHA1 hashes or per TPM bank hash
values were extended into the TPM[1], but non-SHA1 boot aggregate
values [2] should always include PCRs 8 & 9.

I'm still not clear on how an attestation server would know to
include PCRs 8 and 9 after this change came through a stable kernel
update. It doesn't seem like something appropriate for stable since
it requires code changes to attestation servers to handle the
change.

I know this has already been released in some stable releases, so
I'm too late, but perhaps I'm missing something.

The point of adding PCRs 8 & 9 only to non-SHA1 boot_aggregate values
was to avoid affecting existing attestation servers.  The intention
was when attestation servers added support for the non-sha1
boot_aggregate values, they'd also include PCRs 8 & 9.  The existing
SHA1 boot_aggregate value remains PCRs 0 - 7.

To prevent this or something similar from happening again, what
should have been the proper way of including PCRs 8 & 9?

Just to be pragmatic: this is going to happen again.  Shim is already
measuring the Mok variables through PCR 14, so if we want an accurate
boot aggregate, we're going to have to include PCR 14 as well (or
persuade shim to measure through a PCR we're already including, which
isn't impossible since I think shim should be measuring the Mok
variables using the EV_EFI_VARIABLE_DRIVER_CONFIG event and, since it
affects secure boot policy, that does argue it should be measured
through PCR 7).

Ok.   Going forward, it sounds like we need to define a new
"boot_aggregate" record.  One that contains a version number and PCR
mask.

Mimi