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. > > So, maybe we should keep the HMAC protection enabled, and if the > number > of PCR extends is above a certain threshold, we can print a warning > message in the kernel log. > > Roberto BR, Jarkko
