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
