On Fri, 2020-12-11 at 09:46 -0800, James Bottomley wrote: > On Fri, 2020-12-11 at 06:01 -0500, Mimi Zohar wrote: > > On Thu, 2020-12-10 at 21:10 -0600, Tyler Hicks wrote: > > > On 2020-11-29 08:17:38, Mimi Zohar wrote: > > > > Hi Sasha, > > > > > > > > On Wed, 2020-07-08 at 21:27 -0400, Sasha Levin wrote: > > > > > On Wed, Jul 08, 2020 at 12:13:13PM -0400, Mimi Zohar wrote: > > > > > > Hi Sasha, > > > > > > > > > > > > On Wed, 2020-07-08 at 11:40 -0400, Sasha Levin wrote: > > > > > > > From: Maurizio Drocco <maurizio.drocco@xxxxxxx> > > > > > > > > > > > > > > [ 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
