On Thu, Sep 24, 2026 at 7:27 PM Mimi Zohar <[email protected]> wrote:
>
> The lack of KEXEC_CMDLINE appraisal is an architectural constraint of IMA's
> inode-based appraisal model. The kexec command line is a plain buffer passed
> directly to kexec_file_load() via syscall. Unlike the kernel image or 
> initramfs,
> it is not a file. There is no natural way to associate a signature with it,
> whether via xattr or as an appended signature. This is not an intentional
> security decision but a consequence of how IMA appraisal works.

Would appended-signature appraisal for KEXEC_CMDLINE be a reasonable
extension, or is it deemed out of scope for IMA? I see code comments
stating that buffers can only be measured and not appraised and
recognize that IMA was architectured to appraise file backed objects,
however, it appears technically feasible to use ima_read_modsig() to
parse an appended signature from the cmdline buffer. The signature can
then be verified by existing modsig verification helpers, and excluded
before validating the terminating NUL and loading the cmdline.

I understand this would require extending the current appraisal path,
policy support, and error handling. Are there additional architectural
reasons that would make this approach unsuitable?

>
> The threat model concern you raise is valid — a caller with access to
> kexec_file_load() can supply an unauthenticated command line that weakens the
> target kernel's enforcement state, even when the kernel and initramfs are
> appraised. This gap is real and currently unaddressed.
>
> IMA continuity across kexec has not been discussed. Appraising the kernel 
> image
> and initramfs does not guarantee the target kernel will enforce an equivalent
> IMA policy after boot.

I agree that appraising a kernel image alone does not guarantee
equivalent IMA enforcement after boot. However, the deployment would
be responsible for signing and trusting only kernels that implement
and require IMA continuity. It would also need to exclude older
trusted images that lack this support.

>
> We would welcome proposals for addressing these gaps.

An idea that does not involve signing the cmdline is to preserve IMA
enforcement across kexec. The source kernel could hand over its active
policy, which the target would restore during IMA initialization. To
ensure the IMA subsystem has initialized in the target kernel, we
could imagine a CONFIG_IMA_REQUIRE_ENABLED that ntroduces a readiness
flag that init_ima() would set only after initialization and policy
restoration. An unconditional check in kernel_init_freeable() would
panic if the flag remained false, indicating that IMA has been
tampered with.

If the inherited policy appraises /init, initramfs signatures and
xattrs would also need to be available before execution. I saw the
earlier initramfs xattr proposal (https://lwn.net/Articles/788922/)
but it seemed never to have merged, so it will likely need revisiting.
This idea would prevent weakening IMA enforcement across the
transition, although the problem of broader cmdline authentication
still remains open. Would this be a reasonable direction to
investigate?

Thanks,
Danny

Reply via email to