View previous topic :: View next topic |
Author |
Message |
causality Apprentice
Joined: 03 Jun 2006 Posts: 239
|
Posted: Wed Apr 18, 2012 5:25 pm Post subject: Hardened-Sources, nvidia-drivers, and gcc-4.5 |
|
|
x11-drivers/nvidia-drivers (any version, currently using 295.40) cannot be built with a gcc-4.5.x compiler, at least not against hardened-sources (currently using 3.3.2).
Attempting to do so results in the following errors during compilation of nvidia-drivers. The kernel was built with gcc-4.5.3 and this is the result of attempting to build nvidia-drivers with the same compiler:
Code: | i686-pc-linux-gnu-gcc -Wp,-MD,/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/.nv-vm.o.d -nostdinc -isystem /usr/lib/gcc/i686-pc-linux-gnu/4.5.3/include -I/usr/src/linux-3.3.2-hardened/arch/x86/include -Iarch/x86/include/generated -Iinclude -I/usr/src/linux-3.3.2-hardened/include -include /usr/src/linux-3.3.2-hardened/include/linux/kconfig.h -I/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -m32 -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=k8 -maccumulate-outgoing-args -Wa,-mtune=generic32 -ffreestanding -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wframe-larger-than=1024 -fno-stack-protector -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -fplugin=/usr/src/linux-3.3.2-hardened/tools/gcc/constify_plugin.so -DCONSTIFY_PLUGIN -fplugin=/usr/src/linux-3.3.2-hardened/tools/gcc/colorize_plugin.so -I/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel -Wall -MD -Wno-cast-qual -Wno-error -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"295.40\" -Wno-unused-function -Wuninitialized -UDEBUG -U_DEBUG -DNDEBUG -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(nv_vm)" -D"KBUILD_MODNAME=KBUILD_STR(nvidia)" -c -o /var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-vm.o /var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-vm.c
/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-procfs.c: In function 'nv_register_procfs':
/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-procfs.c:715:5: error: assignment of read-only variable 'nv_procfs_registry_fops'
/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-procfs.c:716:5: error: assignment of read-only variable 'nv_procfs_registry_fops'
make[4]: *** [/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel/nv-procfs.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [_module_/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/kernel] Error 2
make[2]: *** [sub-make] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build!
make[1]: *** [module] Error 1
make: *** [module] Error 2
emake failed
* ERROR: x11-drivers/nvidia-drivers-295.40 failed (compile phase):
* Unable to emake HOSTCC=i686-pc-linux-gnu-gcc CROSS_COMPILE=i686-pc-linux-gnu- LDFLAGS= ARCH=i386 IGNORE_CC_MISMATCH=yes V=1 SYSSRC=/usr/src/linux SYSOUT=/lib/modules/3.3.2-hardened/build CC=i686-pc-linux-gnu-gcc clean module
*
* Call stack:
* ebuild.sh, line 85: Called src_compile
* environment, line 3679: Called linux-mod_src_compile
* environment, line 2627: Called die
* The specific snippet of code:
* eval "emake HOSTCC=\"$(tc-getBUILD_CC)\" CROSS_COMPILE=${CHOST}- LDFLAGS=\"$(get_abi_LDFLAGS)\" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS} " || die "Unable to emake HOSTCC="$(tc-getBUILD_CC)" CROSS_COMPILE=${CHOST}- LDFLAGS="$(get_abi_LDFLAGS)" ${BUILD_FIXES} ${BUILD_PARAMS} ${BUILD_TARGETS}";
*
* If you need support, post the output of 'emerge --info =x11-drivers/nvidia-drivers-295.40',
* the complete build log and the output of 'emerge -pqv =x11-drivers/nvidia-drivers-295.40'.
* The complete build log is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/temp/environment'.
* S: '/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/work/'
>>> Failed to emerge x11-drivers/nvidia-drivers-295.40, Log file:
>>> '/var/tmp/portage/x11-drivers/nvidia-drivers-295.40/temp/build.log' |
After that error, immediately using gcc-config to set the compiler to the old gcc-4.4.6 version (without plugin support) and re-issuing "emerge --oneshot nvidia-drivers" works flawlessly. That of course won't actually work because a module built with 4.4 will fail to load when running a kernel built with 4.5 (complaining about invalid module format), forcing me to build both the kernel and nvidia-drivers with 4.4.
There is a seven-month-old discussion on the grsecurity forums located here: http://forums.grsecurity.net/viewtopic.php?p=11305
That discussion mentions two patches intended to fix this issue.
Assuming those patches work (I have not tried them), can they be incorporated into the nvidia-drivers ebuilds for Hardened Gentoo users? They have been around for some time. Or is there another known workaround to this issue I have been unable to find? Except for this issue, nvidia-drivers and hardened-sources work flawlessly for me. |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 23059
|
Posted: Wed Apr 18, 2012 10:50 pm Post subject: |
|
|
Patch pax-usercopy.patch looks like it is safe to use unconditionally, since it just changes an allocation to flag the allocation as USERCOPY.
Patch pax-const.patch is problematic, since it introduces a dependency on PaX-specific functions that do not exist in the hardened kernel. Using this patch in the ebuild would require the ebuild to determine whether you are using hardened-sources and apply the patch only if you are need it.
May I ask why you are trying this? Typically, people who run hardened-sources do so for increased security, so loading a huge closed source blob into the kernel seems a bit odd. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Thu Apr 19, 2012 6:26 am Post subject: |
|
|
Hu wrote: | Using this patch in the ebuild would require the ebuild to determine whether you are using hardened-sources |
A lot of ebuilds have USE=pax_kernel.
Quote: | May I ask why you are trying this? |
In order to be able to use X with the machine?
Quote: | Typically, people who run hardened-sources do so for increased security |
This should not imply that the machine cannot be used as a desktop.
Quote: | so loading a huge closed source blob into the kernel seems a bit odd. |
"Closed source" != "unsecure". It only means that you cannot audit security by yourself, i.e. you have to trust the vendor completely. If you do not audit by yourself (and most people don't) and the vendor has a good auditing this can be even better than open source due to obscurity. (Of course, security by obscurity is not possible, but obscurity can help in some cases.) |
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 23059
|
Posted: Fri Apr 20, 2012 2:03 am Post subject: |
|
|
mv wrote: | A lot of ebuilds have USE=pax_kernel. | Yes, but the user may have multiple kernel sources installed. The ebuild only needs to patch the nVidia driver if the kernel source used is a hardened kernel.
mv wrote: | Quote: | May I ask why you are trying this? |
In order to be able to use X with the machine? | Nouveau works quite well for X these days.
mv wrote: | Quote: | Typically, people who run hardened-sources do so for increased security |
This should not imply that the machine cannot be used as a desktop.
Quote: | so loading a huge closed source blob into the kernel seems a bit odd. |
"Closed source" != "unsecure". It only means that you cannot audit security by yourself, i.e. you have to trust the vendor completely. If you do not audit by yourself (and most people don't) and the vendor has a good auditing this can be even better than open source due to obscurity. (Of course, security by obscurity is not possible, but obscurity can help in some cases.) | Given the frequency with which the nVidia closed drivers have had bugs that are just plain weird, I have very little faith in their quality control process. Although it is possible that they could have good security practice and bad quality control practice, it seems unlikely. |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Fri Apr 20, 2012 5:57 am Post subject: |
|
|
Hu wrote: | mv wrote: | A lot of ebuilds have USE=pax_kernel. | Yes, but the user may have multiple kernel sources installed. The ebuild only needs to patch the nVidia driver if the kernel source used is a hardened kernel. |
The user decides with the USE-Flag whether to patch for the hardened kernel. This is what this USE-Flag is used for in most ebuilds (e.g. in aufs*).
Hu wrote: | Nouveau works quite well for X these days. |
No, not at all. It is practically unusable on all machines which I have tested (dead X after very few minutes for unknown reasons, even with minimal window managers without any effects). And given the speed of its development I experienced with it since several years, I guess it will still need several more years until it reaches a state where it can be used. |
|
Back to top |
|
|
fpires n00b
Joined: 08 Jan 2010 Posts: 15
|
Posted: Mon Jun 25, 2012 10:56 pm Post subject: |
|
|
This is the first time I try to compile the nvidia-drivers, to see if I could get the HDMI output on this laptop to work, since nouveau didn't work. This laptops has an Intel 915 for the screen, and nVidia Geforce 310M for HDMI.
I'm getting the same error with x11-drivers/nvidia-drivers-302.17, hardened-sources-3.4.2 and gcc 4.5.3. I have also tried compiling while using a hardened kernel with Pax and Grsecurity disabled, and selecting gcc vanilla. Still the same error:
KBUILD_STR(nvidia)" -c -o /var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/.tmp_nv-usermap.o /var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/nv-usermap.c
/var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/nv-procfs.c: In function ‘nv_register_procfs’:
/var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/nv-procfs.c:729:5: error: assignment of read-only variable ‘nv_procfs_registry_fops’
/var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/nv-procfs.c:730:5: error: assignment of read-only variable ‘nv_procfs_registry_fops’
make[3]: *** [/var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel/nv-procfs.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [_module_/var/tmp/portage/x11-drivers/nvidia-drivers-302.17/work/kernel] Error 2
NVIDIA: left KBUILD.
nvidia.ko failed to build! |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|