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 kernel'
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.
https://www.kernel.org/doc/html/v4.14/admin-guide/tainted-kernels.html
The numbers in the list correspond to the bit positions in the value supplied by "cat
/proc/sys/kernel/tainted"
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 web
page you highlighted.
12289 = 11000000000001 in binary
[bit] [bit value] [description]
0 1 A module with a non-GPL license has been loaded. (bit
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 supporting
module signature
1 + 4096 + 8192 = 12289
The program I reference simply does the math for you. The source is tainted.c and
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 what
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 crashes
and submit a bugzilla it won't be debugged since any traces wouldn't match any debug
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
1024
So, even though there are no messages (and I don't care why that is the case) the
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
0
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?
regards,
Steve
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
