[PATCH 1/1] IMA event log trimming

[Roberto Sassu]

On Mon, 2025-12-08 at 09:21 -0800, Gregory Lumen wrote:
> > Rather than designing the interface absent use cases, could we give use
> > cases first so we know it fits?
> 
> I would also like to request that we include operational considerations in 
> the interface design; specifically, which additional signals can or should 
> be made available to UM to assist in diagnosing log validation failures. 
> This seems called for as any form of log trimming will introduce a new 
> potential cause for validation failures (unexpected trimming).
> 
> With the proposed changes, the only signal available to system operators 
> is the validation failure itself, with no signal that could be used to 
> determine if the failure was the result of an unexpected trim or a loss of 
> synchronization between the log and the PCRs (either through an unexpected 
> PCR extend, or tampering with the measurement list). Any of these may 
> indicate malicious activity, but they may also result from system 
> configuration issues that operators would need to diagnose and resolve.

I don't agree with this. User space can keep a persistent state, and
resume from where it was interrupted. There is no risk of loss of data,
if user space deletes staged measurements only after the read is
complete.

The same comment applies for coordination between different user space
agents. It would not be too hard to expose an interface managed by a
new user space component, providing similar data as IMA (even showing
the full measurements list without its users being aware of the
snapshots). The other agents can fetch the data from the new interface.

And also, I don't see the problem in developing more complex user space
programs which link the measurement entries to PCR values, and anything
that is desirable.

And if from the kernel perspective all we need to do is a list replace,
for me that is the most efficient solution.

Roberto

> Tracking and exposing either the total number of trimmed measurements or 
> the most recent trimmed-to PCR values by the kernel would allow system 
> operators to determine whether a failure was caused by unexpected trimming 
> or integrity issues. (Storing the PCR values also enables validation of 
> the retained measurements even after an unexpected trim, though I’m unsure 
> how often that signal would prove useful.)
> 
> Neither approach appears to add any additional attack surface beyond 
> raising the likelihood of incorrectly or insecurely implemented UM 
> attestation agents. Though that risk (and the additional kernel 
> complexity) should be weighed against the value of the additional 
> diagnostic signals.
> 
> -Gregory Lumen