On Fri, 2025-10-17 at 11:19 +0800, Coiby Xu wrote: > 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.
I don't have a problem with extending the "secure-boot" policy to support uncompressed kernel modules appended signatures, based on whether CONFIG_MODULE_SIG is enabled. The new rule would be in addition to the existing MODULE_CHECK rule. > > > > > 3. The patch title "ima: Use default kernel module signature verification > > for > > compressed ones" is a bit off. It should be something along the lines of > > "ima: > > defer compressed kernel module appended signature verification". > > > > > 4. Simplify the patch description. > > I'll rephrase the title and try simplifying it. Thanks! Thank you.
