Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Hardened-Sources, nvidia-drivers, and gcc-4.5
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
causality
Apprentice
Apprentice


Joined: 03 Jun 2006
Posts: 239

PostPosted: Wed Apr 18, 2012 5:25 pm    Post subject: Hardened-Sources, nvidia-drivers, and gcc-4.5 Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 23059

PostPosted: Wed Apr 18, 2012 10:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6780

PostPosted: Thu Apr 19, 2012 6:26 am    Post subject: Reply with quote

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
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 23059

PostPosted: Fri Apr 20, 2012 2:03 am    Post subject: Reply with quote

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
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6780

PostPosted: Fri Apr 20, 2012 5:57 am    Post subject: Reply with quote

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
View user's profile Send private message
fpires
n00b
n00b


Joined: 08 Jan 2010
Posts: 15

PostPosted: Mon Jun 25, 2012 10:56 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
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