On 24/2/18 2:25 pm, Ed Greshko wrote:
On 02/24/18 10:21, Stephen Morris wrote:
On 23/2/18 8:59 am, Ed Greshko wrote:
On 02/23/18 05:27, Stephen Morris wrote:
  From the responses I am getting it seems that the meaning of 'taints the 
has morphed into something else?
Here is the definitive list of what taints the kernel.  This is from the 4.14
documentation but is also valid for 4.15 kernels.


The numbers in the list correspond to the bit positions in the value supplied by 

Why you don't get "tainted" messages in your dmesg output or journal?  Don't
know....and I'd not be interested in chasing it down.

I've a small program that converts the value from proc-tainted into real info 
if you
need it.
Access to that program would be great, the output from the cat command you
mentioned above of 12289 is meaningless to me especially after looking at the 
page you highlighted.
12289 = 11000000000001  in binary

[bit]    [bit value]    [description]
0            1                A module with a non-GPL license has been loaded.  
0 is rightmost bit)
12          4096         An out-of-tree module has been loaded
13          8192         An unsigned module has been loaded in a kernel 
module signature

1 + 4096 + 8192 = 12289

The program I reference simply does the math for you.  The source is tainted.c 
located at https://paste.fedoraproject.org/paste/a6HyoXLvYCMpjKeym-S~wg

Thanks Ed. Is there any documentation anywhere on what each bit represents?

With bit 13 being set reflecting the loading of an unsigned module into a kernel supporting module signatures, is that because the kernel has been designed for secure boot, and will turning on secure boot resolve the signing issue?

But it is really easy to do it yourself as you can see.

The nVidia driver is a proprietary driver and thus doesn't have a GPL license
The nVidia driver has been compiled from source that isn't in the kernel source
tree.  So, it is out-of-tree.
The nVidia driver isn't signed and the kernel checks signatures.

It won't matter if you "binary one" or one you "compile if from source 
yourself" the
result would be the same.  Your kernel will be tainted no matter what you do or 
may be happening to prevent the messages form appearing in logs.

It won't matter if you compile a kernel and manage somehow to insert the nVidia
driver into the source code tree and fake a GPL license and sign the module and
produce a 0 output from "cat /proc/sys/kernel/tainted" if you have a kernel 
and submit a bugzilla it won't be debugged since any traces wouldn't match any 
info for the kernel as released.

You should run a system with only the mouse driver you talk about and check the
output of the cat.

As I have mentioned elsewhere.  I have a VM under Virtual Box with the vboxvideo
driver and the Virtual Box Tools installed....

[egreshko@f27k ~]$ dmesg | grep -i taint
[egreshko@f27k ~]$ journalctl -b -0 | grep -i taint
[egreshko@f27k ~]$ cat /proc/sys/kernel/tainted

So, even though there are no messages (and I don't care why that is the case) 
kernel on the system is tainted.

Contrast that with a system running under "virt-manager"....

[egreshko@f27qk ~]$ dmesg | grep -i taint
[egreshko@f27qk ~]$ journalctl -b -0 | grep -i taint
[egreshko@f27qk ~]$ cat /proc/sys/kernel/tainted

Also, no messages.  But not running a tainted kernel.

Are all these taint messages, and all the reasons for a taint message being produced saying that if we have to build our own drivers into the kernel to be able to use our hardware, and hence put us into the situation of potentially not getting support for kernel defects if any are encountered, that we shouldn't be using linux?



users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org

Reply via email to