[QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[Danny Hu]

Hello,

I have a question about the intended security properties of IMA
appraisal across kexec_file_load(). I am trying to understand why IMA
supports appraisal of the kexec kernel and initramfs through
KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK, while KEXEC_CMDLINE is
measurement-only and cannot reject an unauthorized target command
line. Requiring a signer-approved kernel implies that CAP_SYS_BOOT
alone is not sufficient authority to boot a target kernel. Then why
are command-line parameters capable of weakening the target kernel’s
enforcement state not similarly bound to the signer’s approval?

This appears to leave a gap when IMA is the mechanism enforcing kexec
integrity. A caller permitted to perform kexec could use the signed
kernel as a downgrade trampoline:

1. Supply an approved, signed kernel and initramfs.
2. Supply an unauthenticated command line that prevents IMA
enforcement in the target kernel. An example of such is through
“initcall_blacklist=init_ima”.
3. Boot into the approved kernel without effective IMA enforcement.
4. An attacker is then free to execute unsigned code or kexec into any
other unsigned kernel.

A few questions for the IMA maintainers:

- Is the lack of KEXEC_CMDLINE appraisal simply an architectural
constraint of IMA’s inode-based appraisal model, or an intentional
part of the security model?
- Is command-line integrity expected to be provided by another subsystem?
- Have there been any discussions around a concept of “IMA continuity”
across kexec? By continuity, I mean preserving the appraisal invariant
across the transition so that every accepted target kernel
re-establishes equivalent enforcement.
- If policy continuity was not intended, what threat model gives
appraisal of the kernel and initramfs its intended security value when
their execution environment can be weakened through an unauthenticated
command line?

Thank you for any historical context or guidance on the intended design!

Thanks again,
Danny

Re: [QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[Mimi Zohar]

On Thu, 2026-09-24 at 16:34 -0700, Danny Hu wrote:
> Hello,
> 
> I have a question about the intended security properties of IMA
> appraisal across kexec_file_load(). I am trying to understand why IMA
> supports appraisal of the kexec kernel and initramfs through
> KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK, while KEXEC_CMDLINE is
> measurement-only and cannot reject an unauthorized target command
> line. Requiring a signer-approved kernel implies that CAP_SYS_BOOT
> alone is not sufficient authority to boot a target kernel. Then why
> are command-line parameters capable of weakening the target kernel’s
> enforcement state not similarly bound to the signer’s approval?
> 
> This appears to leave a gap when IMA is the mechanism enforcing kexec
> integrity. A caller permitted to perform kexec could use the signed
> kernel as a downgrade trampoline:
> 
> 1. Supply an approved, signed kernel and initramfs.
> 2. Supply an unauthenticated command line that prevents IMA
> enforcement in the target kernel. An example of such is through
> “initcall_blacklist=init_ima”.
> 3. Boot into the approved kernel without effective IMA enforcement.
> 4. An attacker is then free to execute unsigned code or kexec into any
> other unsigned kernel.
> 
> A few questions for the IMA maintainers:
> 
> - Is the lack of KEXEC_CMDLINE appraisal simply an architectural
> constraint of IMA’s inode-based appraisal model, or an intentional
> part of the security model?
> - Is command-line integrity expected to be provided by another subsystem?
> - Have there been any discussions around a concept of “IMA continuity”
> across kexec? By continuity, I mean preserving the appraisal invariant
> across the transition so that every accepted target kernel
> re-establishes equivalent enforcement.
> - If policy continuity was not intended, what threat model gives
> appraisal of the kernel and initramfs its intended security value when
> their execution environment can be weakened through an unauthenticated
> command line?
> 
> Thank you for any historical context or guidance on the intended design!

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.

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.

We would welcome proposals for addressing these gaps.

Mimi

Re: [QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[Danny Hu]

On Thu, Sep 24, 2026 at 7:27 PM Mimi Zohar <zohar@linux.ibm.com> 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.
>
> 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.
>
> We would welcome proposals for addressing these gaps.

Thank you, Mimi. This clarifies the current security guarantees and
limitations and gives us a clearer direction for investigating a
solution. I’ll continue working on this and hope to follow up with
some concrete proposals.

Re: [QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[Danny Hu]

On Thu, Sep 24, 2026 at 7:27 PM Mimi Zohar <zohar@linux.ibm.com> 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

Re: [QUESTION] IMA: kexec appraisal and the unauthenticated target command line

[Mimi Zohar]

Hi Danny,

On Fri, 2026-10-02 at 11:18 -0700, Danny Hu wrote:
> On Thu, Sep 24, 2026 at 7:27 PM Mimi Zohar <zohar@linux.ibm.com> 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.

The original IMA buffer was limited to measuring the buffer, but that changed
with appended signature support for the kexec kernel image.  So signing the boot
command line with an appended signature should be possible.

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

AI mentioned a couple of issues, but none necessarily blockers:
- Size: boot command line size limitation (defined on per arch basis), might not
be large enough for the appended signature.

- Ordering: the NUL-termination check and length handling are in generic kexec
code, so the signature would have to be stripped before that check, which means
changes outside IMA.

- Final cmdline: several arch loaders append to the buffer after it is passed
in, so the signature would cover the user-supplied portion, not necessarily what
the new kernel finally sees.

- Binding: the signed cmdline should be bound to a specific kernel; otherwise a
validly signed cmdline could be used with any kernel.

In lieu of generic cmdline signature support, a forced built-in cmdline (e.g.
CONFIG_CMDLINE_OVERRIDE on x86) lets the kernel signature cover the string, if
that fits your use case. The tradeoff is that any change to the cmdline requires
rebuilding and re-signing the kernel.
 
> 
> > 
> > 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.

Refer to https://github.com/linux-integrity/linux/issues/11 for a more recent
version.

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

Any help in reviewing and testing Roberto's patch set would be appreciated.

thanks,

Mimi