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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Mon, 2026-08-17 at 12:23 +0200, Nicolai Kuntze wrote:
> Hi,
> 
> This is a design RFC, not a patch submission -- I'd like feedback on
> the approach before polishing the patch series further. A working
> reference implementation exists today for demonstration; details and
> links below.
> 
> Problem
> 
> Every existing IMA hook (FILE_CHECK, MMAP_CHECK, BPRM_CHECK,
> MODULE_CHECK, ...) measures once, at load time: file open, exec,
> mmap, module load, or an explicit ima_measure_critical_data() call.
> Nothing in IMA today re-measures an object after it's already
> resident. A process's .text

A processes text segment is mapped ro and cannot change.  We're looking
to apply the kernel ROX guarantees to user processes, which would make
it very hard even for someone with privilege to modify the text
segment, but if you're looking to fix something like the copy fail
cache corruption, then a strengthened ROX mechanism would be way better
than trying to detect it.

>  or GOT can be modified in memory after load

The GOT (and GOT.PLT) sections are updated by the dynamic linker
*after* the binary is measured.  They're also often constructed lazily
by just in time symbol resolution meaning they change throughout the
lifetime of the process ... therefore if you include them, practically
every measurement will be different and there'll be no way to
reconstruct what measurement you should have seen or relate it back to
the original measurement.  It is possible to do non-lazy linking and
then seal the GOT read only, but that incurs a huge startup cost, so
what is the actual threat model here?

>  (ptrace(), a kernel exploit writing through /proc/pid/mem, or
> similar) without IMA ever re-examining it

Those are all privileged operations, so what is the threat model you're
guarding against?  because if it's something like container mutations,
then using dm-verity and proper ROX handling is likely a better
guarantor.

Regards,

James