From: Mimi Zohar <zohar@linux.ibm.com>
To: Danny Hu <dannyhu@arista.com>, linux-integrity@vger.kernel.org
Cc: roberto.sassu@huawei.com, dmitry.kasatkin@gmail.com,
eric.snowberg@oracle.com, Pierre De Abreu <pierre@arista.com>,
Julien Gomes <julien@arista.com>,
Kunal Bharathi <kbharathi@arista.com>
Subject: Re: [QUESTION] IMA: kexec appraisal and the unauthenticated target command line
Date: Thu, 24 Sep 2026 22:27:20 -0400 [thread overview]
Message-ID: <55d240d39dfbdac4d034380dd02f78838d09f061.camel@linux.ibm.com> (raw)
In-Reply-To: <CAFn2k5AwOoHesnqB42kpfAGx0Wf-CtQbpU3px7LMj8PeiACvZg@mail.gmail.com>
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
next prev parent reply other threads:[~2026-09-25 2:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 23:34 [QUESTION] IMA: kexec appraisal and the unauthenticated target command line Danny Hu
2026-09-25 2:27 ` Mimi Zohar [this message]
2026-09-25 17:08 ` Danny Hu
2026-10-02 18:18 ` Danny Hu
2026-10-06 19:00 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55d240d39dfbdac4d034380dd02f78838d09f061.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=dannyhu@arista.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=julien@arista.com \
--cc=kbharathi@arista.com \
--cc=linux-integrity@vger.kernel.org \
--cc=pierre@arista.com \
--cc=roberto.sassu@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox