On Thu, May 29, 2025 at 10:32 PM Mimi Zohar <zo...@linux.ibm.com> wrote:
>
> On Thu, 2025-05-29 at 12:13 +0800, Pingfan Liu wrote:
> > On Tue, May 27, 2025 at 10:18 PM Mimi Zohar <zo...@linux.ibm.com> wrote:
> > >
> > > On Tue, 2025-05-27 at 11:25 +0800, Pingfan Liu wrote
> > > > > >
> > > > > >
> > > > > > 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.
> > > >
> > > > IMHO, from the higher level, if there is a requirement on the integrity
> > > > of
> > > > the
> > > > initramfs, it should take a similar approach as UKI. And the system
> > > > admin
> > > > can
> > > > choose whether to disable the unsafe format loader or not.
> > >
> > > Yes, that is a possibility, probably a good aim, but in the case of
> > > kexec/kdump
> > > that isn't really necessary. As filesystem(s) support xattrs, IMA
> > > policies
> > > could be written in terms of "func=KEXEC_INITRAMFS_CHECK" to include the
> > > initramfs.
> > >
> >
> > Just aware that we have such a cool feature. Thanks!
>
> > I checked the code. IIUC, the relevant code has already been in the
> > kernel. And the thing left to do is to install an IMA policy, right?
>
> Correct. The problem up to now has been that the initramfs was created on the
> fly on the target system, so it was impossible to remotely sign it by the
> distro.
>
> >
> > But there are still two things to be considered.
> > -1.The UEFI partition is FAT format, which can not support xattr
>
> The normal kexec/kdump kernel image and initramfs are stored in /boot, not the
> UEFI partition. Is that changing?
>
I think that is the case if grub is used as a bootloader.
But officially, only FAT32 is supported in the UEFI specification. So
if a UEFI application (let's say systemd-boot) tries to load kernel
and initramfs, then boots into kernel, it can only expect to read
these files from FAT32 partition.
> e.g. kexec -s -l /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -
> r`.img --reuse-cmdline
>
> > -2. Just like in the UKI case, the kernel fd content is not necessary
> > for the kernel image itself. The initramfs fd can be used to pass some
> > extra data if we use a temp file as a package. So checking the
> > signatures at the initramfs level will block this usage
>
> Sorry I lost you here. What exactly is included in the UKI signature? What
> is
> this initramfs fd extra data? Is it included in the UKI signature? Can you
> point me to some documentation?
>
Sorry for the awkward expression, let me clarify it.
It is a pity that these things are on the fly and there are no documents yet.
With the advent of UKI, which encapsulates the kernel, initramfs, and
cmdline into a single PE file, the original kexec_file_load syscall
schema no longer aligns with this design.
SYSCALL_DEFINE5(kexec_file_load, int, kernel_fd, int, initrd_fd,
unsigned long, cmdline_len, const char __user *, cmdline_ptr,
unsigned long, flags)
In particular, the kernel_fd parameter no longer refers to just the
kernel image alone.
And the same thing may happen to initrd_fd.
In essence, it means the redesign or re-explaining of the
kexec_file_load() interface, but for the time being, these things are
on the fly.
Thanks,
Pingfan
