[PATCH 1/1] IMA event log trimming

[James Bottomley]

On Fri, 2025-12-05 at 10:30 +0100, Roberto Sassu wrote:
> On Tue, 2025-12-02 at 15:28 -0800, steven chen wrote:
> > This patch is for trimming N entries of the IMA event logs as well
> > as cleaning the hash table.
> > 
> > It provides a userspace interface ima_trim_log that can be used to
> > input number N to let kernel to trim N entries of IMA event logs.
> > When read this interface, it returns number of entries trimmed last
> > tim.
> 
> High-level comments:
> - It does not offer the possibility to keep the hash table
> - There is no coordination between taking a snapshot and the readers
> of
>   the measurements list (I think it is necessary, since reading is
>   based on *pos, which contains the entries read until a given point;
>   if there is a truncate in the middle of the read, *pos would still
>   refer to the non-truncated list and the next read will skip some
>   measurement entries)

Rather than designing the interface absent use cases, could we give use
cases first so we know it fits?  I really only have one: the keylime
agent, but I believe it's pattern, which would be get TPM quote of
logging PCRs, certify quote and then trim the log up to the point the
quote was obtained will be a common pattern (at least I don't think
anyone would trim the log without quoting it).  If you're trimming
based on a quote, you know the end hash of all the PCRs and you want to
trim up to that.  Since the log is fixed, you can work out what the
index offset is, but it does seem a bit suboptimal to have to compute
that, which is why I think trimming by end PCR hash is useful.  The
main point in all of this is, I think, that you don't really get to
decide which point in the log the TPM will quote: it always quotes it's
current PCR values, so no-one who cares about log quotes can select the
number of entries first, they all have to see what PCR values the quote
returns.

> - While trimming per se is ok, I like more the idea of staging
> changes and letting the user delete the staged measurements list
> later

I'm not averse to this, but keylime won't care ... it gets the quote
and the log and it will verify the log before it will get the agent to
issue a trim.  Is there a use case that would actually need this
behaviour?

I also think having the base PCRs stored in the kernel after the trim
(in a way that's easily consumed, like a non measured log entry), thus
allowing verification from the log up to any current quote is useful. 
The reason I think it's useful is the attestation token one: I can see
the keylime verifier giving an I've verified the log up to here and all
the entries look good token that contains the base PCRs and if there
are quite a few of these floating around (especially if the log isn't
always trimmed) I could see the kernel base PCR storage being used to
ask which is the relevant attestation token I should use to verify the
rest of the log (or even used to detect nefarious trimming designed to
hide records).

Regards,

James