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