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

[Mimi Zohar]

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.

-- 
thanks,

Mimi