Bug 241712 - Kernel "tainted" message with Nvidia proprietary driver and kernel 2.6.21-1.3194.fc7
Kernel "tainted" message with Nvidia proprietary driver and kernel 2.6.21-1.3...
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
: 242102 242320 242496 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-29 14:32 EDT by Joel Gomberg
Modified: 2007-11-30 17:12 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-20 06:43:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Audit Log (2.31 MB, text/plain)
2007-05-30 13:43 EDT, Joel Gomberg
no flags Details

  None (edit)
Description Joel Gomberg 2007-05-29 14:32:07 EDT
Description of problem:  Nvidia proprietary driver won't load with SELINUX
enabled.  I wasn't sure whether to file this under kernel or
selinux-policy-targeted.  No denials show up in audit.log.



Version-Release number of selected component (if applicable): kernel
2.6.21-1.3194.fc7.  FC7-RC2.  Upgrade from FC6.



How reproducible:  Boot with SELINUX enabled


Steps to Reproduce:
1. Boot with Nvidia proprietary driver and SELINUX enabled.
2.
3.
  
Actual results:

Boot message reports that can't stat /dev/nvidia0,1,23, and /dev/nvidiactl.  

From /var/log/messages:
 
May 28 11:48:48 alcibiades kernel: audit(1180378096.858:4): avc:  denied  {
create } for  pid=454 comm="cp" name="nvidia0"
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=chr_file
May 28 11:48:48 alcibiades kernel: audit(1180378096.858:5): avc:  denied  {
setattr } for  pid=454 comm="cp" name="nvidia0" dev=tmpfs ino=1751
scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
tcontext=system_u:object_r:etc_t:s0 tclass=chr_file
May 28 11:48:48 alcibiades kernel: nvidia: module license 'NVIDIA' taints kernel.


Expected results:

System should boot with Nvidia driver and SELINUX enabled.


Additional info:

With "enforcing=0" system boots normally with Nvidia driver.
Comment 1 Daniel Walsh 2007-05-29 23:20:31 EDT
This looks like you have a badly mislabeled file system or something is going
very strange.

Running the avc messages you attached gives output 

allow udev_t etc_t:chr_file { create setattr };

Whic indicates udev is trying to create a chr_file in an etc directory?
Comment 2 Joel Gomberg 2007-05-29 23:37:46 EDT
I ran ls -Z /dev/nvidia0:

ls -Z /dev/nvidia0
crw-------  joel root system_u:object_r:xserver_misc_device_t /dev/nvidia0  

Running restorecon didn't change the label.  The Nvidia driver was working
without problems on FC6 running SELinux targeted.  After the upgrade to FC7 RC
2, I built the nvidia.ko module from the Livna SRPM.  /dev/nvidia0 has a date of
10 March, which is the date of xorg-x11-drv-nvidia-1.0.9755-2.lvn7.

Do you have any suggestions?  Relabeling the system?
Comment 3 Joel Gomberg 2007-05-30 00:14:43 EDT
I've also been getting this data from logwatch since the update from fc6:

 --------------------- Selinux Audit Begin ------------------------ 

 *** Denials ***
    system_u system_u (chr_file): 15 times
    system_u system_u (dir): 85 times
 
  Number of audit daemon starts: 5 
 
  Number of audit daemon stops: 5 
 
 ---------------------- Selinux Audit End ------------------------- 

I don't remember ever seeing selinux audit entries in logwatch before.
Comment 4 Daniel Walsh 2007-05-30 13:25:26 EDT
See if 

setsebool -P allow_execstack=1 

fixes your nvida problem.
Comment 5 Daniel Walsh 2007-05-30 13:25:50 EDT
Also please attach your audit.log
Comment 6 Joel Gomberg 2007-05-30 13:43:36 EDT
Created attachment 155713 [details]
Audit Log
Comment 7 Joel Gomberg 2007-05-30 13:45:49 EDT
Your suggestion didn't work:

[root@alcibiades audit]# setsebool -P allow_execstack=1
Could not change policy booleans
Comment 8 Will Woods 2007-05-30 13:48:05 EDT
the nvidia driver needs a bunch of device files - /dev/nvidiactl and
/dev/nvidia[0-9] chiefly. Something stashes them in /etc/udev/devices, where (in
theory) udev copies them to /dev at startup. 

Perhaps this is udev trying to save these newly-created devices to
/etc/udev/devices?
Comment 9 Daniel Walsh 2007-05-30 13:57:37 EDT
Joel setsebool failed?  This seems like your machine is badly mislabeled.  Have
you triggered a relabel.  

touch /.autorelabel; reboot


Will the idea of /etc/udev/devices is probably correct.
Comment 10 Joel Gomberg 2007-05-30 14:16:34 EDT
I did a relabel last night.  It didn't help.

ls - Z /etc/udev/devices

crw-------  root root system_u:object_r:etc_t          nvidia0
crw-------  root root system_u:object_r:etc_t          nvidia1
crw-------  root root system_u:object_r:etc_t          nvidia2
crw-------  root root system_u:object_r:etc_t          nvidia3
crw-------  root root system_u:object_r:etc_t          nvidiactl

They've been there all along.  Their file dates are 10 March.

I'll try removing the nvidia rpms, relabeling, and then reinstalling them.
Comment 11 Joel Gomberg 2007-05-30 14:44:43 EDT
I removed the nvidia rpms, relabeled, reinstalled.  Same behavior, same messages.
Comment 12 Daniel Walsh 2007-05-30 15:06:40 EDT
The problem here is the labeling of the /etc/udev/devices directory. 

This directory should be labeled device_t and I bet it would work.  

You can create the directory
chcon -t device_t /etc/udev/devices 

But why is udev creating the devices in this directory at all rather then on /dev?
Comment 13 Joel Gomberg 2007-05-30 15:13:49 EDT
Udev isn't creating these devices -- they're included in the livna rpm:

[joel@alcibiades ~]$ rpm -ql xorg-x11-drv-nvidia-1.0.9755-2.lvn7
/dev/nvidia0
/dev/nvidia1
/dev/nvidia2
/dev/nvidia3
/dev/nvidiactl
/etc/ld.so.conf.d/nvidia.conf
/etc/modprobe.d/nvidia
/etc/profile.d/nvidia.csh
/etc/profile.d/nvidia.sh
/etc/rc.d/init.d/nvidia
/etc/udev/devices/nvidia0
/etc/udev/devices/nvidia1
/etc/udev/devices/nvidia2
/etc/udev/devices/nvidia3
/etc/udev/devices/nvidiactl

-- snip remainder of file listing --

I'll try your suggestion and see if it works.
Comment 14 Joel Gomberg 2007-05-30 15:23:52 EDT
That didn't work either.  Just after udev starts, I see the boot message:

cp:  cannot stat '/dev/nvidia0': permission denied.

Then the same lines for the other devices.

Then, I believe, cannot lstat /dev/nvidia0:  no such file or directory.

Once I've booted with enforcing=0, I can issue a setenforce 1 command and
everything seems to work just fine.
Comment 15 Harald Hoyer 2007-05-31 06:53:44 EDT
/etc/udev/devices is deprecated anyway. The "clean" way now would be
/etc/udev/makedev.d/60-nvidia.nodes and the nvidia rpm should also provide
/etc/makedev.d/60nvidia.
Comment 16 vfiend 2007-06-01 02:19:58 EDT
I just filed this at livna where it belongs (
http://bugzilla.livna.org/show_bug.cgi?id=1504 )
Comment 17 Joel Gomberg 2007-06-01 10:21:55 EDT
(In reply to comment #16)
> I just filed this at livna where it belongs (
> http://bugzilla.livna.org/show_bug.cgi?id=1504 )

Thanks for doing that.  I tried to create a bugzilla account at Livna yesterday,
but never got a confirmation email with a password.  They may still be having
problems related to their hard drive failure.
Comment 18 Harald Hoyer 2007-06-04 11:44:23 EDT
*** Bug 242102 has been marked as a duplicate of this bug. ***
Comment 19 Harald Hoyer 2007-06-04 11:49:02 EDT
*** Bug 242320 has been marked as a duplicate of this bug. ***
Comment 20 Daniel Walsh 2007-06-04 12:08:05 EDT
If you execute the following does everything work.  

#  chcon -t bin_t /sbin/start_udev

The startup script is labeled udev_exec_t and I believe this is incorrect.   If
we label it bin_t the startup will continue to run in initrc_t and will
transition to udev_t only when udev starts up.

If this does not work, we could also try to label /etc/udev/devices as device_t.

chcon -R -t device_t /etc/udev/devices



Comment 21 Joel Gomberg 2007-06-04 12:32:52 EDT
Livna has issued a new rpm consistent with Harald Hoyer's comment and the
problem now seems to be resolved, at least with respect to Livna.
Comment 22 Daniel Walsh 2007-06-04 15:57:13 EDT
*** Bug 242496 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.