Created attachment 362468 [details, diff] new pax-const.patch, *not* obsoleting nvidia-drivers331.13-pax-usercopy.patch) The newest nvidia-drivers-331.17 does not emerge when USE=pax_kernel is set. There are two reasons for this: (1) A trivial reason is that the patchname ${P}-pax-usercopy.patch is used instead of ${PN}-331.13-pax-usercopy.patch. (2) However, even with (1) being fixed, nvidia-drivers-331.17 does not emerge when the kernel sources are from a hardened kernel (with compiler plugins enabled), because the new driver initializes similarly to earlier nvidia drivers: It is necessary to use a patch similar to nvidia-drivers-pax-const.patch (in addition to the pax-usercopy patch). I attach a patch nvidia-drivers-331.17-pax-const.patch for the second issue, and a trivial patch nvidia-drivers-331.17.ebuild.patch for the ebuild which fixes (1) and additionally (2). (The latter patch uses the name ${PN}-331.17-pax-const.patch to refer to the patch so that a problem like (1) does not occur again with the next bump of nvidia-drivers.)
Created attachment 362470 [details, diff] Trivial patch for the nvidia-drivers-331.17.ebuild to include both patches correctly
I forgot to mention that I tested the patches with amd64 and x86.
x11-drivers/nvidia-drivers-331.20 has the same issue(s), and the same patches work (tested on x86 and amd65).
Martin's patches work like charm +1 FYI: wrapped up in http://www.startux.de/gitweb/quarks.git/commit/2abec1f330d5504cb4eb5eb45b6fd70b52a0a369
x11-drivers/nvidia-drivers-331.20 compiles without these patches (strange, previous versions usually fail to compile without them), kernel module loads without errors, but it hang console (black screen, dead keyboard/mouse - sysrq doesn't work) when Xorg start (Xorg.0.log is empty after reboot). With these two patches (one copied from /usr/portage/x11-drivers/nvidia-drivers/files/, second is from attach to this issue): # ls -1 /etc/portage/patches/x11-drivers/nvidia-drivers/ nvidia-drivers-331.13-pax-usercopy.patch nvidia-drivers-331.17-pax-const.patch Xorg start and works ok.
as explained in https://bugs.gentoo.org/show_bug.cgi?id=482784#c8 this patch is incomplete and i suggest that you use my patch instead.
(In reply to PaX Team from comment #6) > i suggest that you use my patch instead. I agree with the no_const attribute, especially because nobody knows what happens in the binary part of the driver. However, I am surprised that you make now such a suggestion, because the "historical" patch (I guess also suggested by you) followed a different road and, moreover, you complained when I used the no_const attribute approach for the (also partially binary) martian-modem driver.
if you look at the code handling struct UvmGpuProvider you'll see that it's not at all clear that the open source wrapper has all its instances and management code because nvUvmInterfaceRegisterUvmOps is exported and the address of g_nvKernelProvider 'escapes' to the outside world. as UvmGpuProvider is not one of the kernel's own ops structures (unlike file_operations previously) we can't really assume what happens to it inside the binary parts. also for proper constification of g_nvKernelProvider you should move the runtime initializers into a compile time initializer and then also not bother with clearing it in nvUvmInterfaceDeRegisterUvmOps. but that again raises the possibility of changing some deeper logic we know nothing about. last but not least, UvmGpuProviderTracking would also need constification then since it too contains function pointers in addition to a pointer to struct UvmGpuProvider (again at the risk of upsetting some logic that does rely on this clearing). so all in all, not touching these ops structures is the safer (and much cheaper to maintain) way i think for now. if/when nvidia changes this code we can get automatic constification.
Looks like this patch didn't go anywhere. Reopen if there's more owrk on it.
