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@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org