From: Coiby Xu <coxu@redhat.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Baoquan He <bhe@redhat.com>,
linux-integrity@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, pmenzel@molgen.mpg.de,
ruyang@redhat.com, chenste@linux.microsoft.com
Subject: Re: [PATCH] ima: add a knob ima= to make IMA be able to be disabled
Date: Wed, 4 Jun 2025 11:34:34 +0800 [thread overview]
Message-ID: <hn455nyrp65bb23ltub4tet6ixfcggshgerxm2bhun4ubv2iau@eanh3ka67irf> (raw)
In-Reply-To: <c0f1df02160138d0782cb897eda844287b3d7792.camel@linux.ibm.com>
On Thu, May 22, 2025 at 07:08:04AM -0400, Mimi Zohar wrote:
>On Thu, 2025-05-22 at 11:24 +0800, Baoquan He wrote:
>> On 05/21/25 at 08:54am, Mimi Zohar wrote:
>> > On Fri, 2025-05-16 at 08:22 +0800, Baoquan He wrote:
>> > > CC kexec list.
>> > >
>> > > On 05/16/25 at 07:39am, Baoquan He wrote:
>> > > > Kdump kernel doesn't need IMA functionality, and enabling IMA will cost
>> > > > extra memory. It would be very helpful to allow IMA to be disabled for
>> > > > kdump kernel.
>>
>> Thanks a lot for careufl reviewing and great suggestions.
>>
>> >
>> > The real question is not whether kdump needs "IMA", but whether not enabling
>> > IMA in the kdump kernel could be abused. The comments below don't address
>> > that question but limit/emphasize, as much as possible, turning IMA off is
>> > limited to the kdump kernel.
>>
>> Are you suggesting removing below paragraph from patch log because they
>> are redundant? I can remove it in v2 if yes.
>
>"The comments below" was referring to my comments on the patch, not the next
>paragraph. "don't address that question" refers to whether the kdump kernel
>could be abused.
>
>We're trying to close integrity gaps, not add new ones. Verifying the UKI's
>signature addresses the integrity of the initramfs. What about the integrity of
>the kdump initramfs (or for that matter the kexec initramfs)? If the kdump
>initramfs was signed, IMA would be able to verify it before the kexec.
Hi Mimi,
I thought you were asking that the commit message should address the
question why disabling IMA should be limited to the kdump kernel. It
turns out I misunderstood your concern.
Currently there is no way provided to verify the kdump initramfs as a
whole file or to verify individual files in the kdump initramfs.
As you have already known, the kdump initramfs is always generated on
the fly and will be re-generated when the dumping target changes or
some important files change. We try to generate a minimal initramfs in
order to save memory. So yes, it's impossible to sign it as a whole file
beforehand.
And since xattrs like security.ima are not supported in the kdump
initramfs, we have no way to use IMA to verify individual file's
integrity. In fact, we have to stop IMA from working otherwise it's
very likely kdump will break.
So far, I'm not aware of any bug report that complains kdump stops
working because of IMA. So it indicates very few users are trying to use
IMA in kdump.
If users do have concerns on the integrity of kdump initramfs, I think
we can advice users to make sure the deployed IMA policy will verify the
integrity of the files while they are being collected and copied into
the kdump initramfs by tools like dracut.
--
Best regards,
Coiby
next prev parent reply other threads:[~2025-06-04 3:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-15 23:39 [PATCH] ima: add a knob ima= to make IMA be able to be disabled Baoquan He
2025-05-16 0:22 ` Baoquan He
2025-05-21 12:54 ` Mimi Zohar
2025-05-21 12:58 ` Mimi Zohar
2025-05-22 3:49 ` Baoquan He
2025-05-22 3:14 ` Coiby Xu
2025-05-22 3:24 ` Baoquan He
2025-05-22 6:02 ` Coiby Xu
2025-05-22 11:08 ` Mimi Zohar
2025-05-22 14:52 ` Baoquan He
[not found] ` <CAF+s44QHJs8J27TEy0AW1m2wT=LRSz59nHf-8AuqL8px_zKGUg@mail.gmail.com>
2025-05-27 14:17 ` Mimi Zohar
2025-05-29 4:13 ` Pingfan Liu
2025-05-29 14:31 ` Mimi Zohar
2025-05-30 4:14 ` Pingfan Liu
2025-06-04 3:34 ` Coiby Xu [this message]
2025-06-04 22:53 ` 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=hn455nyrp65bb23ltub4tet6ixfcggshgerxm2bhun4ubv2iau@eanh3ka67irf \
--to=coxu@redhat.com \
--cc=bhe@redhat.com \
--cc=chenste@linux.microsoft.com \
--cc=kexec@lists.infradead.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmenzel@molgen.mpg.de \
--cc=ruyang@redhat.com \
--cc=zohar@linux.ibm.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;
as well as URLs for NNTP newsgroup(s).