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

[Roberto Sassu]

On Wed, 2025-11-26 at 15:40 -0800, Gregory Lumen wrote:
> Greetings Roberto,
> 
> If I may chime in a bit:
> 
> > The only way to make the verification of measurements list snapshots
> > work is that the verification state is stored outside the system to
> > evaluate (which can be assumed to be trusted), so that you are sure
> > that the system is not advancing the PCR starting value by itself.
> 
> You are correct; to make the described approach work, an external source 
> of trust is required in order to detect unexpected or unauthorized 
> trimming of the event log (for example, by signing the trim-to PCR values 
> from the previous verification/attestation cycle). This should be true 
> regardless of the mechanism of trimming. More generally, I will go so far 
> as to suggest that any attempt to attest the integrity of a system using 
> IMA will likely fall into one of two general approaches: either the entire 
> IMA event log is retained (either in kernel or user space) from boot and 
> claims of system integrity are built by validating and examining the 
> entire log for signs of tampering, or an external source of trust is 
> introduced to allow incremental validation and examination of the log. 
> Other more innovative approaches may exist, but we make no such claims.
> 
> I will also say that it should be possible to implement either approach to 
> attestation (retaining the entire log, or relying on an external source of 
> trust) with any sane implementation for IMA log trimming.
> 
> As for our proposed implementation, storing the starting PCR values in the 
> kernel preserving the ability for any arbitrary user space entity to 
> validate the retained portion of the IMA event log against the TPM PCRs at 
> any time, without requiring awareness of other user space mechanisms 
> implemented by other entities that may be initiating IMA trimming 
> operations. My personal sense is that this capability is worth preserving, 
> but it is entirely possible the general consensus is that the value 
> offered does not balance against the additional technical complexity when 
> compared to simpler alternatives (discussed in a moment). To stress the 
> point, this capability would only enable validation of the integrity of 
> the retained portion of the event log and its continuity with the PCRs, 
> and could not be used to make any claims as to the overall integrity of 
> the system since, as you observed, an attacker who has successfully 
> compromised the system could simply trim the event log in order to discard 
> evidence of the compromise.

Hi Gregory

all you said can be implemented by maintaining the PCR starting value
outside the system, in a trusted entity. This would allow the
functionality you are hoping for to validate the retained portion of
the measurement list.

Keeping the PCR starting value in the kernel has the potential of
misleading users that this is an information they can rely on. I would
rather prefer to not run in such risk.

> If the ability to validate the retained portion of the IMA event log is 
> not worth designing for, we could instead go with a simpler "Trim-to-N" 
> approach, where the user space interface allows for the specification of 
> an absolute index into the IMA log to be used as the trim position (as 
> opposed to using calculated PCR values to indicate trim position in our 
> current proposal). To protect against unexpected behavior in the event of 

>From implementation point of view, it looks much simpler to me to
specify N relative to the current measurement list.

> concurrent trims, index counting would need to be fixed (hence absolute) 
> such that index 0 would always refer to the very first entry written 
> during boot, even if that entry has already been trimmed, with the number 
> of trimmed entries (and thus starting index of the retained log) exposed 
> to use space via a pseudo-file.

In my draft patch [1] (still need to support trimming N entries instead
of the full measurement list), the risk of concurrent trims does not
exist because opening of the snapshot interface is exclusive (no one
else can request trimming concurrently).

If a more elaborated contention of remote attestation agent is
required, that could be done at user space level. I'm hoping to keep in
the kernel only the minimum code necessary for the remote attestation
to work.

Roberto

[1] https://github.com/robertosassu/linux/commit/b0bd002b6caa9d5d4f4d0db2a041b1fd91f33f8a

> With such a trim approach, it should be possible to implement either 
> general attestation approach: retaining the entire log (copy the log to 
> user space, then trim the copied entries), or relying on an external 
> source of trust (quote, determine the log index corresponding to the quote 
> plus PCRs, trim, then securely store the trim position/starting PCRs for 
> future cycles).
> 
> -Gregory Lumen