grsecurity forums

Hello,

Based on an earlier forum entry, third party modules need modified to work with RAP. However, I am confused by the following error when loading nvidia modules with CONFIG_PAX_RAP (x86_64 - grsecurity-3.1-4.5.3-201605060852.patch):

modprobe: ERROR: could not insert 'nvidia': Exec format error

[ADDED] To clarify, the "vermagic" from modinfo is correct and the nvidia modules match the "vermagic" of other kernel modules:

vermagic: 4.5.3-grsec SMP mod_unload modversions KERNEXEC_BTS UDEREF RAP REFCOUNT CONSTIFY_PLUGIN STACKLEAK_PLUGIN GRSEC

Is this error message the expected behavior (an "Exec format error") when loading a third party module that "needs work"?

Thanks

see https://bugs.gentoo.org/show_bug.cgi?id=581726#c2

Thanks

Hi

System:

Code: Select all

Linux version 4.6.3-gr1 (root@localhost) (gcc version 4.9.3 (Gentoo Hardened 4.9.3 p1.3, pie-0.6.3) ) #5 SMP PREEMPT Wed Jul 6 21:52:31 CEST 2016
+ grsecurity-3.1-4.6.3-201607060823.patch
+nvidia-367.27 (+nvidia-drivers-367.27-pax.patch)

Modprobe:

Code: Select all

modprobe: ERROR: could not insert 'nvidia': Exec format error

In dmesg:

Code: Select all

[  119.379528] nvidia: module is not compatible with the KERNEXEC 'or' method and RAP

Is it worth a try PAX RAP kernels 4.7.x and the next, or opt out of this feature?

Cheers

jacekalex wrote:In dmesg:

Code: Select all

[  119.379528] nvidia: module is not compatible with the KERNEXEC 'or' method and RAP

Is it worth a try PAX RAP kernels 4.7.x and the next, or opt out of this feature?

i explained the situation in the linked gentoo bugzilla entry, did you read it?

PaX Team wrote:

jacekalex wrote:In dmesg:

Code: Select all

[  119.379528] nvidia: module is not compatible with the KERNEXEC 'or' method and RAP

Is it worth a try PAX RAP kernels 4.7.x and the next, or opt out of this feature?

i explained the situation in the linked gentoo bugzilla entry, did you read it?

PaX Team 2016-05-01 10:59:42 UTC wrote: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).

Actually, my question was a little out of place.
Summing up RAP and Nvidia-drivers to exclude each other, and this condition can exist for any length of time, as I understand it.
The question is, once this state of affairs may change, eg for 1, 5 or 50 years, or never.

Cheers

speaking only for myself, i'm sure i'll never spend the time on an elaborate binary rewriter and static analyzer that could possibly pull this off for binary-only programs. as for nvidia, you should ask them but i somehow doubt we're on their radar enough to care about compatibility/support. perhaps one day, if/when this code makes it upstream, they'll be forced to, but i'll make no predictions on that.