patching file kernel/nv-procfs.c Hunk #1 FAILED at 707.
Created attachment 357266 [details, diff] Patch for nvidia-drivers-319.49.ebuild Don't apply nvidia-drivers-pax-const.patch This seems to solve the problem.
(In reply to Norman Shulman from comment #1) > Don't apply nvidia-drivers-pax-const.patch > This seems to solve the problem. Works for me, thanks!
I suspect nvidia-drivers-325.08.ebuild also has this problem: nshulman@nvshp:/usr/portage/x11-drivers/nvidia-drivers $ grep nvidia-drivers-pax-const.patch nvidia-drivers-325.*.ebuild nvidia-drivers-325.08.ebuild: epatch "${FILESDIR}"/nvidia-drivers-pax-const.patch nvidia-drivers-325.15.ebuild has been fixed (bug #479944).
Same here. Removing the nvidia-drivers-pax-const.patch fixes 319.49. Nvidia cleanup up their act a bit ;)
331.20 will need this: http://www.grsecurity.net/~paxguy1/nvidia-drivers-331.20-pax-constify.patch
This patch lets the drivers build, but rebooting my system caused it to freeze very early in the EFI boot. Turned out the EFI part of the BIOS was corrupted. After reinstalling the BIOS, the system booted up, but froze with a black screen after bring up the network interfaces. I've downgraded nvidia-drivers to 325.15. Now I see there are new versions of app-emulation/emul-linux-x86-xlibs, so I'm screwing up my courage for another try (I want the latest chromium).
I've patched 331.20 this way: https://bugs.gentoo.org/show_bug.cgi?id=490232#c5
that's another way to go (albeit with a binary module, security is out of the window so why bother with the complex way), but that patch itself is incomplete, there's a memset on that same constified structure in nvUvmInterfaceDeRegisterUvmOps which would need open/close calls around it as well. i say stick to my patch instead, it's more likely to apply for future drivers and you don't really gain/lose any security either way.
(In reply to Norman Shulman from comment #6) Turns out my problem was because I didn't realize that 331.20.ebuild was no longer applying the pax-usercopy.patch, and now relies on epatch_user for all patching. Appending the 331.13-pax-usercopy.patch to my __no_const patch solved the problem.
Sorry for coming late to this, but has this been upstreamed? Can we close this bug as resolved?
(In reply to Anthony Basile from comment #10) > Sorry for coming late to this, but has this been upstreamed? Can we close > this bug as resolved? upstream to me or nvidia? ;) i've had a patch out for 337.12 [1] for some time now which works even with the latest 343.22. [1] https://www.grsecurity.net/~paxguy1/nvidia-drivers-337.12-pax-constify.patch
(In reply to PaX Team from comment #11) > (In reply to Anthony Basile from comment #10) > > Sorry for coming late to this, but has this been upstreamed? Can we close > > this bug as resolved? > > upstream to me or nvidia? ;) > > i've had a patch out for 337.12 [1] for some time now which works even with > the latest 343.22. > > [1] > https://www.grsecurity.net/~paxguy1/nvidia-drivers-337.12-pax-constify.patch I meant to you :) I'm going to reassign this to jer the nvidia-drivers maintainer. Your patch could be added contingent on USE=pax_kernel. @jer your call.
So this patch should work for everything >331 it seems.
(In reply to Jeroen Roovers from comment #13) > So this patch should work for everything >331 it seems. That is my understanding.
