https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html
Tainted kernels
The kernel will mark itself as ‘tainted’ when something occurs that might be relevant later when investigating problems. Don’t worry too much about this, most of the time it’s not a problem to run a tainted kernel; the information is mainly of interest once someone wants to investigate some problem, as its real cause might be the event that got the kernel tainted. That’s why bug reports from tainted kernels will often be ignored by developers, hence try to reproduce problems with an untainted kernel.
The kernel marks "tainted" when something that might be relevant when investigating any problem occurs. You don't have to take this seriously, in many cases running a tainted kernel is not a problem. The information is interesting when investigating any issues, as the kernel may be trained. As a result, bug reports for tainted kernels are often ignored by developers, so try reproducing the problem with a non-tainted kernel.
Note the kernel will remain tainted even after you undo what caused the taint (i.e. unload a proprietary kernel module), to indicate the kernel remains not trustworthy. That’s also why the kernel will print the tainted state when it notices an internal problem (a ‘kernel bug’), a recoverable error (‘kernel oops’) or a non-recoverable error (‘kernel panic’) and writes debug information about this to the logs dmesg outputs. It’s also possible to check the tainted state at runtime through a file in /proc/.
Note that the kernel remains tainted even after reverting the cause of the tainted (for example, unloading the proprietary kernel module), which indicates that the kernel remains unreliable. It also tells why the kernel is in a sealed state, internal problems (kernel bugs), recoverable errors (kernel oops), unrecoverable errors (kernel panic), and fat g information that leaves a log in dmesg output. It is also used to express when the export of is generated. You can also check the tainted state in a file in / proc during execution.
Tainted flag in bugs, oops or panics messages
You find the tainted state near the top in a line starting with ‘CPU:’; if or why the kernel was tainted is shown after the Process ID (‘PID:’) and a shortened name of the command (‘Comm:’) that triggered the event:
You can find the stained state of the line starting with "CPU:" at the top. Whether the kernel is sealed or not is displayed after the process ID ('PID:') and the short name ('Comm:') of the command that triggered the event.
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
Oops: 0002 [#1] SMP PTI
CPU: 0 PID: 4424 Comm: insmod Tainted: P W O 4.20.0-0.rc6.fc30 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
RIP: 0010:my_oops_init+0x13/0x1000 [kpanic]
[...]
You’ll find a ‘Not tainted: ‘ there if the kernel was not tainted at the time of the event; if it was, then it will print ‘Tainted: ‘ and characters either letters or blanks. In above example it looks like this:
If the kernel is not tainted when the event occurs, this will be "Not tainted:". If the kernel is tainted, "Tainted:" and a character or blank string will be displayed individually. In this example:
Tainted: P W O
The meaning of those characters is explained in the table below. In tis case the kernel got tainted earlier because a proprietary Module (P) was loaded, a warning occurred (W), and an externally-built module was loaded (O). To decode other letters use the table below.
The meanings of these characters are shown in Table below. In this case, the kernel was tainted with the precondition that the proprietary Module was loaded (P), a warning occurred (W), and the externally built module was loaded (O). How to decode these strings using Table will be described later.
Decoding tainted state at runtime
At runtime, you can query the tainted state by reading cat /proc/sys/kernel/tainted. If that returns 0, the kernel is not tainted; any other number indicates the reasons why it is. The easiest way to decode that number is the script tools/debugging/kernel-chktaint, which your distribution might ship as part of a package called linux-tools or kernel-tools; if it doesn’t you can download the script from git.kernel.org and execute it with sh kernel-chktaint, which would print something like this on the machine that had the statements in the logs that were quoted earlier:
At runtime, the way to read the tainted state is cat / proc / sys / kernel / tainted. If 0 is returned, the kernel is not tainted. If not, it indicates what the reason is. An easy way to decode is to use script tools / debugging / kernel-chktaint, which you can get as part of the linux-tools and kernel-tools packages. If you don't have one, you can download it with sh kernel-chktaint from git.kernel.org or externally. This will output the following log on the machine where there was a statement in the log mentioned above.
Kernel is Tainted for following reasons:
* Proprietary module was loaded (#0)
* Kernel issued warning (#9)
* Externally-built ('out-of-tree') module was loaded (#12)
See Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel or
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for
a more details explanation of the various taint flags.
Raw taint value as int/string: 4609/'P W O '
You can try to decode the number yourself. That’s easy if there was only one reason that got your kernel tainted, as in this case you can find the number with the table below. If there were multiple reasons you need to decode the number, as it is a bitfield, where each bit indicates the absence or presence of a particular type of taint. It’s best to leave that to the aforementioned script, but if you need something quick you can use this shell command to check which bits are set:
Try decoding the numbers yourself. If you are tainted for a single cause, you can look up the numbers in the table below. If there are multiple causes, you need to decode the number, in this case it's a bitfield. Each bit indicates the presence or absence of a taint of each type. It's best to leave this to the script above, but if you want to do it easily, you can use the following shell command to see which bits are set.
$ for i in $(seq 18); do echo $(($i-1)) $(($(cat /proc/sys/kernel/tainted)>>($i-1)&1));done
Table for decoding tainted state
Note: The character _ is representing a blank in this table to make reading easier.
Note: The letter _ represents a blank in this table for readability.
|Bit|Log|Number |Reason that got the kernel tainted | | |--:|:-:|--:|:--|:--| | | |0 |G/P|1 |proprietary module was loaded |proprietary modul has been loaded.| |1 |/F|2 |module was force loaded |module was forcibly loaded| |2 |/S|4 |SMP kernel oops on an officially SMP incapable processor |I'm running the SMP Kernel on a processor that doesn't officially support SMP| |3 |/R|8 |module was force unloaded |module was forcibly unloaded| |4 |/M|16 |processor reported a Machine Check Exception (MCE) |processor is Machine Check Exception(MCE)Reported| |5 |/B|32 |bad page referenced or some unexpected page flags |Illegal page references and unexpected page flags| |6 |/U|64 |taint requested by userspace application |user application requested tainte| |7 |/D|128 |kernel died recently, i.e. there was an OOPS or BUG |kernel stopped, for example OOPS or BUG| |8 |/A|256 |ACPI table overridden by user |ACPI Table updated by user| |9 |/W|512 |kernel issued warning |Warning occurred in kernel| |10 |/C|1024 |staging driver was loaded |staging driver loaded| |11 |/I|2048 |workaround for bug in platform firmware applied |Workaround for bugs applied to platform firmware| |12 |/O|4096 |externally-built (“out-of-tree”) module was loaded |Built externally(out-of-tree)module was loaded| |13 |/E|8192 |unsigned module was loaded |Unsigned module loaded| |14 |/L|16384 |soft lockup occurred |A soft lockup has occurred| |15 |/K|32768 |kernel has been live patched |live patch applied to kernel| |16 |/X|65536 |auxiliary taint, defined for and used by distros |Ancillary stained that is defined and used for the distribution| |17 |_/T|131072 |kernel was built with the struct randomization plugin |The kernel was built using the struct randomization plugin|
More detailed explanation for tainting
More details on tainting are below.
0. G if all modules loaded have a GPL or compatible license, P if any proprietary module has been loaded. Modules without a MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary. 1. F if any module was force loaded by insmod -f, ' ' if all modules were loaded normally. 2. S if the oops occurred on an SMP kernel running on hardware that hasn’t been certified as safe to run multiprocessor. Currently this occurs only on various Athlons that are not SMP capable. 3. R if a module was force unloaded by rmmod -f, ' ' if all modules were unloaded normally. 4. M if any processor has reported a Machine Check Exception, ' ' if no Machine Check Exceptions have occurred.
5. B If a page-release function has found a bad page reference or some unexpected page flags. This indicates a hardware problem or a kernel bug; there should be other information in the log indicating why this tainting occured. 6. U if a user or user application specifically requested that the Tainted flag be set, ' ' otherwise. 7. D if the kernel has died recently, i.e. there was an OOPS or BUG. 8. A if an ACPI table has been overridden. 9. W if a warning has previously been issued by the kernel. (Though some warnings may set more specific taint flags.)
10. C if a staging driver has been loaded. 11. I if the kernel is working around a severe bug in the platform firmware (BIOS or similar). 12. O if an externally-built (“out-of-tree”) module has been loaded. 13. E if an unsigned module has been loaded in a kernel supporting module signature. 14. L if a soft lockup has previously occurred on the system.
15. K if the kernel has been live patched. 16. X Auxiliary taint, defined for and used by Linux distributors. 17. T Kernel was build with the randstruct plugin, which can intentionally produce extremely unusual kernel structure layouts (even performance pathological ones), which is important to know when debugging. Set at build time.
Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Recommended Posts