Introduction: The Linux kernel taint mechanism

The Linux kernel maintains a "tainted state" which is included in kernel error messages. The tainted state provides an indication whether something has happened to the running kernel that affects whether a kernel error or hang can be troubleshot effectively by analysing the kernel source code. Some of the information in the taint relates to whether the information provided by the kernel in an error message can be considered trustworthy.

As an example, the taint state is set when a machine check exception (MCE) has been raised, indicating a hardware related problem has occurred.

Once the tainted state of a running kernel has been set, it cannot be unset other than by reloading the kernel, that is by shutting down and then restarting the system.
 

Taint flags

The tainted status of the kernel not only indicates whether or not the kernel has been tainted but also indicates what type(s) of event caused the kernel to be marked as tainted. This information is encoded through single-character flags in the string following "Tainted:" in a kernel error message.

P: A module with a Proprietary license has been loaded, i.e. a module that is not licensed under the GNU General Public License (GPL) or a compatible license. This may indicate that source code for this module is not available to the Linux kernel developers or to SUSE developers.

G: The opposite of 'P': the kernel has been tainted (for a reason indicated by a different flag), but all modules loaded into it were licensed under the GPL or a license compatible with the GPL.

F: A module was loaded using the Force option "-f" of insmod or modprobe, which caused a sanity check of the versioning information from the module (if present) to be skipped.

R: A module which was in use or was not designed to be removed has been forcefully Removed from the running kernel using the force option "-f" of rmmod.

S: The Linux kernel is running with Symmetric MultiProcessor support (SMP), but the CPUs in the system are not designed or certified for SMP use.

M: A Machine Check Exception (MCE) has been raised while the kernel was running. MCEs are triggered by the hardware to indicate a hardware related problem, for example the CPU's temperature exceeding a threshold or a memory bank signaling an uncorrectable error.

B: A process has been found in a Bad page state, indicating a corruption of the virtual memory subsystem, possibly caused by malfunctioning RAM or cache memory.

U: User or user application specifically requested that the Tainted flag be set, ' ' otherwise.

D: Kernel has Died recently, i.e. there was an OOPS or BUG.

W: A Warning has previously been issued by the kernel.

C: A staging driver has been loaded.

A: ACPI table has been overriden [From SLES11 SP1 onwards]

I: Kernel is working around a severe bug in the platform firmware [From SLES11 SP2 onwards]

O: An Out-of-tree module has been loaded [From SLES12 SP0 onwards]

L: A Soft Lockup has previously occured on the system [From SLES12 SP2 onwards]

K: The Kernel has been live patched [From SLES12 SP2 onwards]

The taint flags above are implemented in the standard Linux kernel and indicate that the information provided in kernel error messages is not necessarily to be trusted.

In SUSE kernels, additional taint flags are implemented.

N: An uNsupported module has been loaded, i.e. a module which is not supported by SUSE and which is not known to be supported by a third party. For example, the module is a driver that is not yet mature enough to be supportable or is a driver for an obsolete type of hardware which can no longer be tested adequately.

X: A module that is supported by SUSE  in cooperation with a third party has been loaded into the kernel.

E: An unsigned module has been loaded in a kernel supportconfig module signature [From SLES11 SP3 onwards].

H: System restored from unsafe Hibernate snapshot image [From SLES12 SP1 onwards]
 

Determining the taint status of a running kernel.

The taint status of a running kernel can be determined by running

cat /proc/sys/kernel/tainted

When the output is 0, the kernel is not tainted, when the output is non-zero, the kernel is tainted.

The value will be a combined number of all applying kernel taint flags added (ORed) together. You can find a list of currently used kernel flags under:

/usr/src/linux/Documentation/sysctl/kernel.txt

When the kernel produces an error, a string detailing the taint status will be included.
 

Tainted kernels and support from SUSE Support

As the information provided by a tainted kernel is not necessarily trustworthy and may relate to third-party code for which source code is not available to SUSE, it can be of limited value for troubleshooting. As such, the support which SUSE Support is able to provide for issues involving tainted kernels is limited.

When an issue occurs with a tainted kernel, it is important that every effort be made to reproduce the issue with an untainted kernel (or a kernel only tainted with X) so that SUSE Support can provide appropriate support.
 

Avoiding kernel tainting

The following steps can be taken to avoid tainting the kernel:

• To avoid "P" tainting, switch to using SUSE supplied drivers and modules instead of ones supplied by other vendors. For instance, use Linux' device-mapper multipath I/O rather than a vendor's proprietary multipathing implementation. Note that is not always possible; some hardware components are only supported by proprietary drivers, for instance.

• To avoid "F" or "R" tainting, do not use force options when (un)loading kernel modules. If necessary, obtain drivers built specifically for the running kernel version.

• To avoid "S" tainting, do not use SMP-enabled kernels on systems with CPUs that have not been designed or certified for SMP use.

• To avoid "M" or "B" tainting, ensure that the hardware is operated within specified parameters for power supply, temperature, humidity and air flow. Additionally, check the hardware using hardware diagnostics tools from the hardware vendor and consult the Sig11 information page for more information on hardware and hardware configuration issues.

• To avoid "N", use a YES certified configuration.

• "X" tainting is not necessarily problematic. As for support, SUSE Support can involve the third party that provides support for the driver involved. The external flag can be avoided by using hardware components that are directly supported by SUSE. 

• To avoid "I" you may figure out where the firmware problem lays (BIOS or some other component)

• To avoid "E"  tainting. please make sure to not load any module which does not have a valid signature. You can force this behaviour by enabling CONFIG_MODULE_SIG_FORCE config option, or by setting module.sig_enforce=1 on the kernel command line

• "H" is being set when the system tries to boot from a snapshot images without valid signatures. it is controlled through CONFIG_SNAPSHOT_VERIFICATION config option. if you get this flag, make sure your snapshot has a valid signature