On Sat, 2024-10-12 at 13:56 +0300, Jarkko Sakkinen wrote: > 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. Sounds good. > > 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. Are you backtracking on having a boot parameter here specifically to turn on/off HMAC encryption for IMA? Mimi
