/tmp/portage/x11-drivers/nvidia-drivers-275.09.07/work/kernel/nv-procfs.c: In function 'nv_register_procfs': /tmp/portage/x11-drivers/nvidia-drivers-275.09.07/work/kernel/nv-procfs.c:710:5: error: assignment of read-only variable 'nv_procfs_registry_fops' /tmp/portage/x11-drivers/nvidia-drivers-275.09.07/work/kernel/nv-procfs.c:711:5: error: assignment of read-only variable 'nv_procfs_registry_fops' Reproducible: Always Also see this thread http://forums.grsecurity.net/viewtopic.php?f=3&t=2716&start=30#p11305 Proposed ebuild patch: 3 @@ -19,7 +19,7 @@ 4 LICENSE="NVIDIA" 5 SLOT="0" 6 KEYWORDS="-* ~amd64 ~x86 ~x86-fbsd" 7 -IUSE="acpi custom-cflags gtk multilib kernel_linux" 8 +IUSE="acpi custom-cflags gtk multilib kernel_linux hardened" 9 RESTRICT="strip" 10 EMULTILIB_PKG="true" 11 12 @@ -288,6 +288,11 @@ 13 # If greater than 2.6.5 use M= instead of SUBDIR= 14 convert_to_m "${NV_SRC}"/Makefile.kbuild 15 fi 16 + 17 + if use hardened; then 18 + epatch "${FILESDIR}"/nvidia-drivers-275.19-pax-const.patch 19 + # epatch "${FILESDIR}"/nvidia-drivers-285.03-pax-usercopy.patch 20 + fi 21 } 22 23 src_compile() {
Created attachment 288939 [details] Additional patch for nvidia-drivers
Three points here: 1) We have been supporting nouveau for a while, nvidia + hardened have had problems. 2) This is a fix against the nvidia drivers, not the hardened kernel. If the x11 team wishes to include it. 3) If they do, they should not use "hardened" use flags since "hardened" refers to hardened tool chain and not hardened kernel. We've been recommending another use flags "pax_kernel".
Hi, I agree with all three points Anthony mentioned. I already changed the USE flag to pax_kernel in my overlay. Will also try to get the usercopy patch working with latest driver.
x11-drivers/nvidia drivers is not maintained by x11
Patch working nicely here against 290.10
- I rebased the patch against 290.06. - version bumped to 290.10 in my overlay http://www.startux.de/gitweb/quarks.git so please test so this patch can be included. Stefan --- ../../../../portage/x11-drivers/nvidia-drivers/nvidia-drivers-290.06.ebuild 2011-11-04 11:11:42.000000000 -0700 +++ nvidia-drivers-290.10.ebuild 2011-11-24 03:28:04.027569344 -0800 @@ -19,7 +19,7 @@ LICENSE="NVIDIA" SLOT="0" KEYWORDS="-* ~amd64 ~x86 ~x86-fbsd" -IUSE="acpi custom-cflags gtk multilib kernel_linux" +IUSE="acpi custom-cflags gtk multilib kernel_linux pax_kernel" RESTRICT="strip" EMULTILIB_PKG="true" @@ -288,6 +288,11 @@ # If greater than 2.6.5 use M= instead of SUBDIR= convert_to_m "${NV_SRC}"/Makefile.kbuild fi + + if use pax_kernel; then + epatch "${FILESDIR}"/nvidia-drivers-pax-const.patch + epatch "${FILESDIR}"/nvidia-drivers-pax-usercopy.patch + fi }
I updated the PAX_USERCOPY patches using new versions provided by the Pax team of Grsecurity forum. These patches allow using the SLUB allocator now too! Also rebased my overlay against latest upstream 290.10
I've been using the attached patch without issue for quite some time. Please consider it for inclusion.
Use a newer version of nvidia-drivers since the versions you are referencing are no longer in the tree.
I still maintain nvidia-drivers incl. these patches in my overlay btw. so you can always check out the latest version: http://www.startux.de/gitweb/quarks.git/tree/HEAD:/x11-drivers/nvidia-drivers Ready to be included upstream :)
ok. Well these ebuilds aren't in the tree. Only newer ones... so these patches won't be going into the tree.
Hi, don't know what you mean by that..sorry. The patches in my overlay apply to all the 295* ebuilds in the upstream tree. all you need is: http://www.startux.de/gitweb/quarks.git/blob/HEAD:/x11-drivers/nvidia-drivers/ebuild.diff + the actual patches: http://www.startux.de/gitweb/quarks.git/blob/HEAD:/x11-drivers/nvidia-drivers/files/nvidia-drivers-pax-usercopy.patch http://www.startux.de/gitweb/quarks.git/blob/HEAD:/x11-drivers/nvidia-drivers/files/nvidia-drivers-pax-const.patch Cheers
I agree, I am using this with 295.59 currently.
Are we competing for how many times this ticket can be opened? It's a crap patch. It's a double cast to get ride of a const. It's not going in the tree no matter what version it's against. Fix it right.
The "crap" patch is from Brad Spengler the author of Grsecurity himself. I just picked it up and tried to help out people who want to use the nvidia blob. I still think a "non perfect" patch is far better than completely unusable, but I rather spent my time somewhere else than arguing about "code quality"... :(
We know this is an issue, and are reopening it to start trying to work out issues like this with upstream. Please do not take reopening this bug as an endorsement of any specific fix, but we will be starting with the fix provided in this bug and taking it to nvidia.
Rejoice and be merry, the patches are carried in the tree for 304.43 and newer.
(In reply to comment #17) > Rejoice and be merry, the patches are carried in the tree for 304.43 and > newer. Thank-you very much!
Created attachment 322513 [details, diff] Patch for the 173.* series I am very glad that finally the new nvidia drivers work with hardened kernel without local patches. (nouveau crashes so often that it is not an option on my machines.) Since I have one machine which needs the 173 series of drivers (for which the patch does not work), I use since ages another patch for this series which I attach now. It is more agressive than the patch for the newer series, because it just removes the const attribute globally, but otherwise the patch would be huge and would probably have to be rewritten for every upgrade (while the attached patch works since ages for all versions of the 173 series). It should not be a problem if the patch is applied also with a non-hardened kernel (although I have not really tested this).
(In reply to comment #19) > Created attachment 322513 [details, diff] [details, diff] > Patch for the 173.* series > > I am very glad that finally the new nvidia drivers work with hardened > kernel without local patches. (nouveau crashes so often that it is not > an option on my machines.) > > Since I have one machine which needs the 173 series of drivers > (for which the patch does not work), I use since ages another > patch for this series which I attach now. > > It is more agressive than the patch for the newer series, because it just > removes the const attribute globally, but otherwise the patch would > be huge and would probably have to be rewritten for every upgrade > (while the attached patch works since ages for all versions of the > 173 series). > > It should not be a problem if the patch is applied also with a > non-hardened kernel (although I have not really tested this). Please create a new bug.
