Re: [RFC] IMA: periodic runtime re-measurement of process .text/GOT

[Mimi Zohar <zohar@linux.ibm.com>]

On Mon, 2026-08-24 at 09:17 -0400, Mimi Zohar wrote:
> On Sat, 2026-08-22 at 21:38 +0200, Nicolai Kuntze wrote:
> [...]
> 
> > 
> > > This feature is continuous/periodic ... a different execution
> > > model, not an incremental addition to a hook-based architecture.
> > > The reference implementation ... bypasses IMA's measurement list
> > > and dedup entirely
> > 
> > This was the strongest objection, and rather than argue it away I
> > went back and changed the design -- v2 patches attached/linked below,
> > not just a response in prose. You were right that a self-scheduling
> > timer inside ima_main.c's dispatch is a materially different execution
> > model, not an incremental addition to a hook-based one; the fix wasn't
> > to defend the timer, it was to notice the actual requirement was never
> > "recheck on a schedule," it was "answer a verifier's request," the
> > same shape a TPM Quote already has. So v2 drops the timer and
> > `interval=` entirely: RUNTIME_TEXT_CHECK/RUNTIME_GOT_CHECK/
> > KERNEL_TEXT_CHECK are now dispatched from a one-shot trigger, a new
> > write-only securityfs file (`/sys/kernel/security/ima/runtime_measure`,
> > CAP_SYS_ADMIN-gated), the same event-triggered shape every other IMA
> > hook already has -- the event is just "a verifier asked" instead of
> > "a file was opened." Boot-tested under QEMU/KVM: a 5-second idle
> > window with no write to `runtime_measure` produces zero measurement
> > log lines; one write produces exactly one correctly-scoped batch;
> > a further idle wait leaves the count unchanged, confirming it's
> > genuinely one-shot and not a disguised timer restart.
> 
> Thank you.

Have you considered defining this as an IMA critical-data measurement, triggered
by the securityfs write?  That way the verifier wouldn't need any information
beyond what's already in the IMA measurement list.

Mimi

> 
> > 
> > The measurement-list/dedup bypass you also flagged is a separate
> > point from the execution-model one, and v2 does *not* change it: it's
> > still deliberate, for the reason given in the original RFC -- an
> > external verifier replaying the full PCR-extend chain needs every
> > extend the TPM actually performed, including repeats of unchanged
> > content, which is exactly what IMA's own digest-based dedup would
> > throw away. v1's dedicated per-mapping dedup table (built to bound log
> > growth from timer ticks nobody asked for) is dropped in v2 for the
> > same reason it's no longer needed: growth is now bounded by how often
> > a verifier actually requests a measurement, not by an on-device clock.
> 
> Extending the TPM is a performance concern — that's why IMA caches the result.
> CONFIG_IMA_DISABLE_HTABLE addresses the A-B-A case, where without it, a repeat
> of an earlier digest (A) gets skipped because it's already in the htable, making
> the log misleadingly show only A-B. It doesn't change consecutive-repeat
> behavior — if the last hash was B and the new hash is still B, there's still no
> need to add another B.
> 
> Why does this case need to be different? With extends now triggered per verifier
> request rather than per tick, why does an unchanged digest still need a fresh
> extend on every request?
> 
> 
> > It stays available, unchanged, for anyone who still wants periodic
> > mode -- v1 is kept as sent-and-tested history, not deleted, just not
> > the default.
> 
> Retaining v1 in your GitHub repo is up to you, but it wouldn't be upstreamed.
> 
> Mimi
> 
> > Does this address the concern, or is there a reason a request-driven
> > hook still doesn't belong in ima_main.c's dispatch at all? Genuinely
> > asking, not rhetorically -- if the list still prefers the
> > separate-mechanism route (kthread/LSM-adjacent/eBPF, reusing IMA's
> > measurement list and PCR extend chain as a pure data sink without
> > adopting its hook model), I'd rather hear that now than after more
> > patches build on the current shape.