Re: [PATCH v5 0/5] Lazy flush for the auth session
From: Jarkko Sakkinen
Date: Sat Oct 12 2024 - 06:56:18 EST
On Fri, 2024-10-11 at 19:25 +0300, Jarkko Sakkinen wrote:
> On Fri, 2024-10-11 at 18:10 +0200, Roberto Sassu wrote:
> > Initially, I thought that maybe it would not be good to have an
> > event
> > log with unmodified and altered measurement entries. Then, I tried
> > to
> > think if we can really prevent an active interposer from injecting
> > arbitrary PCR extends and pretending that those events actually
> > happened.
> >
> > If I understood James's cover letter correctly, the kernel can
> > detect
> > whether a TPM reset occurred, but not that a PCR extend occurred
> > (maybe
> > with a shadow PCR?).
>
> We can detect TPM reset indirectly. I.e. null seed re-randomizes
> per reset.
>
> >
> > Second point, do we really want to take the responsibility to
> > disable
> > the protection on behalf of users? Maybe a better choice is to let
> > them
> > consciously disable HMAC protection.
>
> So when IMA is not used already with these fixes we get good
> results. And for tpm2_get_random() we can make the algorithm
> smarter. All in all we have good path ongoing for "desktop
> use case" that I would keep thing way there are or at least
> postpone any major decisions just a bit.
>
> For server/IMA use case I'll add a boot parameter it can be
> either on or off by default, I will state that in the commit
> message and we'll go from there.
Up until legit fixes are place distributors can easily disable
the feature. It would be worse if TCG_TPM2_HMAC did not exist.
So I think it is better to focus on doing right things right,
since the feature itself is useful objectively, and make sure
that those fixes bring the wanted results.
BR, Jarkko