On Thu, Oct 16, 2025 at 10:31:35PM -0400, Mimi Zohar wrote:
> On Thu, 2025-10-16 at 11:46 +0800, Coiby Xu wrote:
> > On Tue, Sep 30, 2025 at 04:28:14PM -0400, Mimi Zohar wrote:
> > > On Tue, 2025-09-30 at 09:57 -0400, Mimi Zohar wrote:
> > > > On Sun, 2025-09-28 at 11:03 +0800, Coiby Xu wrote:
> > > > > Currently, for any IMA policy that requires appraisal for kernel
modules
> > > > > e.g. ima_policy=secure_boot, PowerPC architecture specific policy,
> > > > > booting will fail because IMA will reject a kernel module which will
> > > > > be decompressed in the kernel space and then have its signature
> > > > > verified.
> > > > >
> > > > > This happens because when in-kernel module decompression
> > > > > (CONFIG_MODULE_DECOMPRESS) is enabled, kmod will use finit_module
> > > > > syscall instead of init_module to load a module. And IMA mandates IMA
> > > > > xattr verification for finit_module unless appraise_type=imasig|modsig
> > > > > is specified in the rule. However currently initramfs doesn't support
> > > > > xattr. And IMA rule "func=MODULE_CHECK appraise_type=imasig|modsig"
> > > > > doesn't work either because IMA will treat to-be-decompressed kernel
> > > > > module as not having module signature as it can't decompress kernel
> > > > > module to check if signature exists.
> > > > >
> > > > > So fall back to default kernel module signature verification when we
have
> > > > > no way to verify IMA xattr.
> > > > >
> > > > > Reported-by: Karel Srot <[email protected]>
> > > > > Signed-off-by: Coiby Xu <[email protected]>
> > > > > ---
> > > > > Another approach will be to make IMA decompress the kernel module to
> > > > > check the signature. This requires refactoring kernel module code to
> > > > > make the in-kernel module decompressing feature modular and seemingly
> > > > > more efforts are needed. A second disadvantage is it feels
> > > > > counter-intuitive to verify the same kernel module signature twice.
And
> > > > > we still need to make ima_policy=secure_boot allow verifying appended
> > > > > module signature.
> > > > >
> > > > > Anyways, I'm open to suggestions and can try the latter approach if
> > > > > there are some benefits I'm not aware of or a better approach.
> > > >
> > > > Coiby, there are multiple issues being discussed here. Before deciding
on an
> > > > appropriate solution, let's frame the issues(s) properly.
> >
> > Hi Mimi,
> >
> > Thanks for listing and framing the issues! Sorry, it took me a while to
> > go through your feedback as I also had a 8-day holiday.
> >
> > > >
> > > > 1. The finit_module syscall eventually calls init_module_from_file() to
read the
> > > > module into memory and then decompress it. The problem is that the
kernel
> > > > module signature verification occurs during the kernel_read_file(),
before the
> > > > kernel module is decompressed. Thus, the appended kernel module
signature
> > > > cannot be verified.
> >
> > Since IMA only accesses a kernel module as a fd or struct file*, even if
> > IMA hook is triggerd after kernel module is decompressed, IMA still
> > doesn't know the default verification has passed or can't access the
> > decompressed kernel buffer [2] to do the verification by itself.
> >
> > [2]
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/module/main.c?h=v6.17#n3689
> >
> > > >
> > > > 2. CPIO doesn't have xattr support. There were multiple attempts at
including
> > > > xattrs in CPIO, but none were upstreamed [1]. If file signatures
stored in
> > > > security.ima were available in the initramfs, then finit_module() could
verify
> > > > them, as opposed to the appended kernel module signature.
> >
> > Thanks you for pointing me to the work [1]. I'll take a more careful
> > look at [1]. I think CPIO supporting xattr can be a long-term solution
> > and also close a important security gap.
> >
> > > >
> > > > 3. The issues described above are generic, not limited to Power. When
> > > > CONFIG_MODULE_SIG is configured, the arch specific IMA policy rules do
not
> > > > include an "appraise func=MODULE_CHECK".
> >
> > Yes, the issue is not limited to Power. And thanks for correcting me
> > that Power arch specific IMA policy rules don't have this problem! Sorry
> > I misread the code.
> >
> > > >
> > > > 4. Unlike the arch specific IMA policy rules, the built-in secure boot
IMA
> > > > policy, specified on the boot command line as "ima_policy=secure_boot",
always
> > > > enforces the IMA signature stored in security.ima.
> > > >
> > > > Partial solutions without kernel changes:
> > > > - Enable CONFIG_MODULE_SIG (Doesn't solve 4)
> > > > - Disable kernel module compression.
> > > >
> > > > Complete solution:
> > > > - Pick up and upstream Roberto Sassu's last version of initramfs
support [1].
> > > > - Somehow prevent kernel_read_file() from failing when the
kernel_read_file_id
> > > > enumeration is READING_MODULE and the kernel module is compressed. The
change
> > > > might be limited to ima_post_read_file().
> > >
> > > or perhaps not totally.
> > >
> > > init_module_from_file() doesn't pass the flags variable to
kernel_read_file().
> > > You might want to consider defining a new kernel_read_file_id enumeration
named
> > > READING_COMPRESSED_MODULE.
> >
> > Thanks for suggesting the solutions! I like the solution of CPIO
> > supporting xattr but it seems it won't land in upstream soon. So I
> > prefer the last approach. I've implemented one [3] by defining a new
> > kernel_read_file_id enumeration, would you like me to post the patches
> > to the mailing list directly?
> >
> > [3] https://github.com/coiby/linux/tree/in_kernel_decompression_ima
>
> A few thoughts, before you post the patch.
Thank you for sharing your thoughts!
>
> 1. In the general case, the kernel module could be compressed, but without an
> appended signature. The new code should only defer appended signature
> verification, if there isn't an xattr or appended signature.
I'll add these two condition checks, thanks!
>
> 2. Instead of defining an additional process_measurement() argument to
identify
> compressed kernel modules, to simplify the code it might be possible to
define a
> new "func" named COMPRESSED_MODULE_CHECK.
>
> + [READING_COMPRESSED_MODULE] = MODULE_CHECK, ->
COMPRESSED_MODULE_CHECK
I also thought about this approach. But IMA rule maps kernel module
loading to MODULE_CHECK. If we define a new rule and ask users to use
this new rule, ima_policy=secure_boot still won't work.
