[PATCH] ima: debugging late_initcall_sync measurements

[Mimi Zohar]

On Thu, 2026-05-14 at 13:42 +0100, Yeoreum Yun wrote:
> 
> I wonder what's going on for discussion to resolve these problem:
>   1) measurement event (via file operation)  before IMA initialisation.
>   2) deferred TPM device initailisation and IMA.
> 
> Might someone could think it wouldn't be a problem since initrd is
> measuared in PCR9 by boot loader (e.x) grub, but it still has a problem
> for the case uses root= boot option where it doesn't use initrd
> but use specified block dev with a filesystem.
> 
> I think soluation would be determined whether IMA neglects the
> measurement event before its initialisation or not in current state:
> 
>   a) Case for neglecting measurement event before IMA initailisation.
> 
>     In this case, As you suggeested, IMA initialisation should be
>     determined by build config whether it initialises at late_initcall
>     or late_initcall_sync so that make user can choice upto their
>     platform.
> 
>   b) Case for considering measurement event event before IMA
>      initialisation.
> 
>     I couldn't image any other solution except queuing those event
>     and extend them after generating boot_aggregate log and if those
>     event can be queued, it wouldn't a problem to move IMA initialisation
>     to late_initcall_sync.
> 
> But you mention there are some thoughts from Roberto, might there was
> some discussion with him. If you don't mind, would you let me know
> how the discussion is going on and your thought to fix this all?

Adding support for "missing early IMA measurements" would be considered a new
feature.  Queueing early measurements before IMA is enabled, as previously
mentioned, breaks the "measure before use" principle and could therefore be
exploited to bypass it.

One alternative being considered is denying access to anything that would be
measured/appraised based on a builtin IMA policy, though it remains unclear
whether this approach would break boot on existing systems.

Mimi