Re: [RFC v1 0/1] Implement IMA Event Log Trimming

[Anirudh Venkataramanan <anirudhve@linux.microsoft.com>]

On 11/20/2025 2:58 PM, Mimi Zohar wrote:
> On Wed, 2025-11-19 at 13:33 -0800, Anirudh Venkataramanan wrote:
>>
>>
>>   2. The kernel uses the userspace supplied PCR values to trim the IMA
>>      measurements list at a specific point, and so these are referred to as
>>      "trim-to PCR values" in this context.
>>
>>      Note that the kernel doesn't really understand what these userspace
>>      provided PCR values mean or what IMA event they correspond to, and so
>>      it does its own IMA event replay till either the replayed PCR values
>>      match with the userspace provided ones, or it runs out of events.
>>
>>      If a match is found, the kernel can proceed with trimming the IMA
>>      measurements list. This is done in two steps, to keep locking context
>>      minimal.
>>
>>      step 1: Find and return the list entry (as a count from head) of exact
>>              match. This does not lock the measurements list mutex, ensuring
>>              new events can be appended to the log.
>>
>>      step 2: Lock the measurements list mutex and trim the measurements list
>>              at the previously identified list entry.
>>
>>     If the trim is successful, the trim-to PCR values are saved as "starting
>>     PCR values". The next time userspace wants to replay the IMA event log,
>>     it will use the starting PCR values as the base for the IMA event log
>>     replay.
> 
> Depending on the IMA policy, the IMA measurement list may contain integrity
> violations, such as "ToM/ToU" (Time of Measurement/Time of Use) or "open-
> writer". Either the userspace supplied PCR values will not match any measurement
> record or the PCR values will be "fixed" to match the well known violation hash
> value extended into the TPM.  Depending on how the userspace PCR values will
> subsequently be used, saving the "fixed" PCR values could result in whitewashing
> the integrity of the measurement list.
> 

Yes, we account for this. IMA documentation [1] notes that:

"An all zeros hash indicates a measurement log violation. IMA is 
invalidating an entry. Trust in entries after that are up to the end 
user. If the Template Data Hash is all zeros, an all ones digest is 
extended."

A userspace verifier could be designed with a user option like 
"--ignore-violations". This would extend a digest of all ones in the 
event replay process and arrive at the same per-event PCR values that 
the TPM originally did. The trimming logic in the kernel would do the 
same thing.

By "whitewashing", you mean that violations will also get trimmed? Given 
that trust in entries post violation is up to the user, is this a 
problem? The IMA log itself can still be saved by userspace for further 
analysis, auditing, etc. The point of trimming is to get it out of the 
kernel memory.

Thanks!
Ani

[1] 
https://ima-doc.readthedocs.io/en/latest/event-log-format.html#template-data-hash