Bug 415159 – sys-kernel/hardened-sources-3.2.11: modprobe of binary module fails with bad error message when CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR set

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description irayo 2012-05-08 18:33:21 UTC]

When the PAX configuration option CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR is set, pre-compiled binary-only modules (e.g. fglrx from ati-drivers) cannot be loaded.  This is mentioned briefly in the documentation for this configuration item.

However, if the option is selected anyway, and the user attempts to modprobe one of these binary-only modules, the error message "Invalid module format" is printed and no other error message is sent to dmesg.  This is unhelpful as usually "Invalid module format" refers to a version magic mismatch, and yet in this case it is referring to something entirely different.

I suggest including a printk (perhaps "attempt to load module violates kernel PAX instrumentation") around line 2518 in kernel/module.c to ensure that the real issue is made clear to users when this occurs.



Reproducible: Always

Steps to Reproduce:
1. Enable CONFIG_PAX_KERNEXEC_PLUGIN_METHOD_OR
2. Compile kernel, modules, and (r)emerge ati-drivers
3. Attempt to modprobe ati-drivers
Actual Results:  
Nondescript error message

Expected Results:  
Error message referring to the PAX configuration setting that causes this to occur.

amd64, Linux/x86_64 3.2.11-hardened SMP

[Comment 1 Anthony Basile 2012-05-08 21:13:10 UTC]

(In reply to comment #0)

> I suggest including a printk (perhaps "attempt to load module violates
> kernel PAX instrumentation") around line 2518 in kernel/module.c to ensure
> that the real issue is made clear to users when this occurs.

This sounds reasonable.  If the user were to read the Kconfig help, he would know what the problem is, but we can't always expect the user to do so.

I'll pass the request upstream.

[Comment 2 PaX Team 2012-05-08 23:24:16 UTC]

it's not that simple ;).

1. the KERNEXEC method is already part of the vermagic string, so any mismatch in there will produce an error that users can investigate as usual

2. unfortunately the binary modules i'm aware of all have an open-source wrapper layer that will fool the above vermagic check (and the same is true for otherwise open source modules that contain uninstrumented assembly code)

3. short of disassembly and full binary analysis there's no way to tell whether a given module is fully compatible with the KERNEXEC instrumentation

the problem is that there's no reliable way to detect incompatible modules from the kernel, any approach will be some approximation only. what i have now is based on the assumption that hopefully modules that declare themselves with a GPL compatible license will likely work with the KERNEXEC instrumentation, but as i said above, there can very well be exceptions here (false positives/negatives). so i can print out some message for this license mismatch but i'm afraid that people will treat it as a reliable message whereas it can never be one.

[Comment 3 Anthony Basile 2012-05-09 22:48:53 UTC]

(In reply to comment #2)
> it's not that simple ;).
> 

Okay, we'll just have to deal with this via documentation.  Thanks for considering it :)