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

[steven chen <chenste@linux.microsoft.com>]

On 11/27/2025 1:45 AM, Roberto Sassu wrote:
> 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.

Hi Roberto,

I will send "trim N entries" patch out this week.

Regards,

Steven

>> 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