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.
