On 2020-12-11 06:01:54, 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.
AFAIK, there's nothing that prevents the non-SHA1 TPM 2.0 PCR banks from
being used even before v5.8, albeit with zero padded SHA1 digests.
Existing attestation servers that already support that configuration are
broken by this stable backport.
> To prevent this or something similar from happening again, what should
> have been the proper way of including PCRs 8 & 9?
I don't think that commits like 6f1a1d103b48 ("ima: Switch to
ima_hash_algo for boot aggregate") and 20c59ce010f8 ("ima: extend
boot_aggregate with kernel measurements") should be backported to
stable.
Including PCRs 8 and 9 definitely makes sense to include in the
boot_aggregate value but limiting such a change to "starting in 5.8",
rather than "starting in 5.8 and 5.4.82", is the safer approach when
attestation server modifications are required.
Tyler
>
> thanks,
>
> Mimi
>
