When setting the new option CONFIG_PAX_RAP=y in sys-kernel/hardened-sources-4.5.2-r1 and reemerging nvidia-drivers after kernel compilation, the freshly built module cannot be loaded with the new kernel: With modprobe, I receive the error message modprobe: ERROR: could not insert 'nvidia': Exec format error and simlarly, insmod complains about 'invalid module format'. The error disappears when CONFIG_PAX_RAP is unset. The compiler used is gcc-5.3.0[-hardened], the architecture is 64 bit Core 2.
(In reply to Martin Väth from comment #0) > When setting the new option CONFIG_PAX_RAP=y in > sys-kernel/hardened-sources-4.5.2-r1 and reemerging nvidia-drivers after > kernel compilation, the freshly built module cannot be loaded with the new > kernel: > > With modprobe, I receive the error message > > modprobe: ERROR: could not insert 'nvidia': Exec format error > > and simlarly, insmod complains about 'invalid module format'. > > The error disappears when CONFIG_PAX_RAP is unset. > > The compiler used is gcc-5.3.0[-hardened], the architecture is 64 bit Core 2. I didn't think of this but it makes sense since the plugin is not being used on those modules. Passing this upstream.
RAP is not and will never be compatible with out-of-tree binary code (for the same reason that the KERNEXEC 'or' method can't be). just consider what would happen when an instrumented indirect call tries to call an uninstrumented nvidia function... instant hash mismatch detection (though it's a good demonstration of the defense mechanism i doubt as an end user you'd appreciate that).
(In reply to PaX Team from comment #2) > consider what > would happen when an instrumented indirect call tries to call an > uninstrumented nvidia function... of course. the only thing you might do is provide better error messages. i'm not sure where you'd issue such messages, but that's about all the end user can expect if they enable RAP.
(In reply to Anthony Basile from comment #3) > of course. the only thing you might do is provide better error messages. > i'm not sure where you'd issue such messages, but that's about all the end > user can expect if they enable RAP. well, i'm only making use of the kernel's existing infrastructure to report modversion mismatches, it should all be in dmesg.
You might make a remark in the description of CONFIG_PAX_RAP that modules with binary blobs like nvidia will break with that option. And maybe point to instructions how to compile out-of-kernel modules for which the full source is available: For these, compilation should be possible, theoretically. (Maybe this even works out-of-the-box? I haven't tried.)
(In reply to PaX Team from comment #4) > it should all be in dmesg. The "modprobe" and "insmod" commands did not cause an output to dmesg
(In reply to Martin Väth from comment #5) > You might make a remark in the description of CONFIG_PAX_RAP that modules > with binary blobs like nvidia will break with that option. done in the latest patch. > And maybe point to instructions how to compile out-of-kernel modules for > which the full source is available: For these, compilation should be > possible, theoretically. (Maybe this even works out-of-the-box? I haven't > tried.) there're no special instructions, out-of-tree module compilation works fine. some checks like these however can't be done at compile time, only module load time.
(In reply to Martin Väth from comment #6) > (In reply to PaX Team from comment #4) > > it should all be in dmesg. > > The "modprobe" and "insmod" commands did not cause an output to dmesg oh yeah, sorry, i thought i'd added an error message for this case already, will be in the next patch.