On 24/2/18 3:43 pm, Stephen Morris wrote:
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?
-------------------------------------------------- Snipping the Rest of
the Message
--------------------------------------------------------------------------------------------------------
Just further to this, I did a system upgrade yesterday which installed a
new kernel, so all the drivers were re-compiled. I have two versions of
my wifi driver installed in dkms because the oldest of the 3 kernels
that exist is using the older wifi driver (and with the kernel changes
that were done that required a new version of the wifi driver to be
obtained will potentially mean that the new version of the driver will
not compile with the oldest version of the kernel I have), and with the
kernel update that was done yesterday dkms for some reason decided to
compile the wrong version of the wifi driver so I had to manually
compile the driver with dkms to get wifi back again (the reasons why the
wrong one was selected this time doesn't really matter, I have rectified
the situation), but the last couple of compiles of the wifi driver I
have done have highlighted that dkms has changed functionality. When I
compiled the wifi driver, after the depmod process was run dkms ran
dracut to update the associated initramfs, and produced messages about
what the backup was called and to use the backup if the next boot
failed. Now depending on how comprehensive the logic in this process is,
it may or may not work, particularly when in my situation I am compiling
3 kernel modules that all potentially require initramfs changes (I know
the nvidia driver does but I'm not sure about the mouse drivers). I know
the main xorg nvidia package I am using installs a dracut config file
but the wifi driver I am using does not because I am manually loading on
the source into /usr/src, so I'm not sure why dkms run dracut when it is
compiled, whereas it is understandable for the nvidia driver.
In addition to the above, before I compiled the wifi driver, I ran a
'dmesg | grep -i taint', and that reported the out of tree taint
messages for the mouse driver for the first time, plus it produced two
new messages that prior to yesterdays update had never been produced
before. The output from the command is below:
[ 10.395281] razermouse: loading out-of-tree module taints kernel.
[ 10.395344] razermouse: module verification failed: signature and/or
required key missing - tainting kernel
[ 10.874905] nvidia: module license 'NVIDIA' taints kernel.
[ 10.874907] Disabling lock debugging due to kernel taint
[ 123.187478] CPU: 6 PID: 825 Comm: systemd-logind Tainted: P
OE 4.15.4-300.fc27.x86_64 #1
[ 123.194773] CPU: 3 PID: 655 Comm: nvidia-modeset Tainted: P W
OE 4.15.4-300.fc27.x86_64 #1
Why are the two cpu messages now coming out for the first time, has the
last update introduced something that is now causing these messages to
be produced or has there been additional functionality added to the
kernel to produce them.
Looking at the nvidia one, this one is probably understandable given
that the nvidia drivers do taint the kernel, but I'm not sure where that
module is coming from because when I use yumex to search for modeset I
don't get any hits at all.
The systemd one is a bit disconcerting, from the perspective of any
kernel modules that systemd has I would have expected to be a native
part of the kernel, hence wouldn't be causing any tainted, hence what is
this logind binary module that is being inserted into the kernel to
cause tainting?
regards,
Steve
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
