On Fri, May 09, 2025 at 09:03:11AM -0400, Mimi Zohar wrote:
[Cc'ing Roberto]
On Fri, 2025-05-09 at 13:59 +0800, Coiby Xu wrote:
On Tue, Apr 29, 2025 at 07:39:17AM -0400, Mimi Zohar wrote:
> On Mon, 2025-04-28 at 11:48 +0800, Coiby Xu wrote:
> > On Wed, Apr 16, 2025 at 11:22:52AM +0800, Baoquan He wrote:
> > > On 04/09/25 at 11:40am, Mimi Zohar wrote:
> > > > On Wed, 2025-04-09 at 10:42 +0800, Baoquan He wrote:
> > > ......snip..
> > > > > Thanks for confirming. I will consider how to fix it accordingly.
Maybe
> > > > > after Steven's patches are merged. That would be great if the buffer
> > > > > allocating and storing can be skiped for kdump in Steven's patch.
While
> > > > > I am worried that could disrupt the progress of Steven's patches.
> > > >
> > > > Agreed, let's get Steven's patch set upstreamed and then make the kdump
> > > > exceptions.
> > > >
> > > > - "ima: kexec: move IMA log copy from kexec load to execute" looks like
it
> > > > isn't
> > > > copying the IMA measurement list records (kexec_post_load), but the
memory
> > > > for
> > > > the IMA measurement list is being allocated (ima_alloc_kexec_file_buf).
> > > >
> > > > - Do you really want to totally disable IMA for kdump or would disabling
> > > > IMA-
> > > > measurement be sufficient? Remember there's already an option to
disable
> > > > IMA-
> > > > appraisal. Disabling just IMA-measurement would allow IMA-appraisal to
> > > > continue
> > > > to work. Meaning based on policy the integrity of files - executables,
> > > > kernel
> > > > image, etc - could still be verified.
> > > >
> > > > Without IMA-measurement:
> > > > - No adding records to the IMA measurement list
> > > > - No IMA measurement list pseudo securityfs files
> > > > - No extending the TPM
> > > >
> > > > With IMA-appraisal:
> > > > - Integrity verification of files based on keys, keyrings
> > > > - Loading keys
> >
> > Thanks for listing the impacts of disabling IMA measurement or
> > appraisal!
> >
> > kdump builds and loads its own initramfs as a cpio archive. After a
> > kernel crashes, the loaded initramfs will save the crashed kernel's
> > memory (vmcore) to specified location and then it will reboot the system
> > immediately. Since kdump merely copy files from existing fs into its
> > initramfs, I think at least majority of users don't need IMA for kdump.
>
> That's fine.
>
> > In fact, currently IMA-appraisal doesn't work for kdump because cpio
> > doesn't support xattr.
>
> Although CPIO doesn't support xattrs, tmpfs supports xattrs.
Thanks for pointing it out! I thought tmpfs doesn't support xattrs
because ima_policy=tcb excludes TMPFS_MAGIC. There are still many
interesting questions for me to explore. For example, I don't understand
how 1st kernel's initramfs is shown as ramfs (which doesn't support
xattrs) but kdump intiramfs without the squashfs module is shown as
tmpfs.
Try adding "rootfstype=tmpfs" to the boot command line. For a detailed
explanation,
take a look at commit 21528c69a0d8 ("rootfs: Fix support for rootfstype= when
root=
is given").
Thanks for pointing me to the above commit! I'll check it.
> I'm aware that some
> store the security xattr information in a file and write it out as xattrs.
If the built initramfs as a CPIO file doesn't carry xattrs, the loaded
initramfs still doesn't have xattrs. I just found the initramfs could
opt to use squashfs or erofs which supports xattrs but currently it's
hardcoded to disable xattrs. For example, recently the dracut erorfs
module also follows squashfs to disable xattrs [1]. So in the near
future, I don't expect xattrs to be supported in kdump.
[1] https://github.com/dracut-ng/dracut-ng/pull
Sorry, I didn't notice the link is incomplete. It should be
[1] https://github.com/dracut-ng/dracut-ng/pull/1296
Right, so the issue isn't the initramfs root filesystem, but CPIO. Either CPIO
would need to be extended, which multiple people have attempted to do, or the
xattrs
could be stored in a file and written out to the initramfs root filesystem. In
fact
Roberto's last attempts at adding CPIO xattr support did something like that.
https://lore.kernel.org/linux-integrity/20190523121803.21638-1-roberto.sa...@huawei.com/
Thanks for introducing Roberto's work to me!
Mimi
--
Best regards,
Coiby
