What to do in response to a kernel warning [LWN.net]

What to do in response to a kernel warning

Posted Nov 18, 2021 22:59 UTC (Thu) by dambacher (subscriber, #1710)
Parent article: What to do in response to a kernel warning

maybe we should taint the affected subsystem on a WARN,
and make security sensible processes aware of this.
they can decide themselves if it is save to continue or not.

to post comments

What to do in response to a kernel warning

Posted Nov 19, 2021 2:51 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

KVM recently added KVM_BUG_ON, which makes all subsequent ioctls return with EIO.

What to do in response to a kernel warning

Posted Dec 10, 2021 20:32 UTC (Fri) by Vipketsh (guest, #134480) [Link]

Translated: they are turning a "potential issue" into "definitely an issue". Depending on the situation that can be anything from great to down right bastard.

If you are some cloud provider with a large number of machines (google, facebook, etc.), you probably have a bunch of redundancy and load balancing in your setup: if one machine goes down for whatever reason, even if just because of a "potential issue", there are a bunch more available to take over and the load balancing makes sure it happens. Furthermore the cloud provider probably has engineers available to take a look at the issue in short order and return the machine to operation. In such a setting taking machines down due to "potential issue" is very well warranted.

On the other hand if you are using the machine in question as a primary work machine, the last thing you want is for a "potential issue" to take down your system and eat hours of work with it. In such a scenario chugging along for as long as possible is the desired mode of operation.

I think google & co. have enough expertise on hand to tweak defaults to whatever makes sense for them while individuals (using Linux as a primary work machine) very often do not. Thus the only same thing is to keep the defaults to what makes sense for individuals: keep going for as long as possible.

What to do in response to a kernel warning

Posted Nov 19, 2021 5:43 UTC (Fri) by developer122 (guest, #152928) [Link]

The fundamental problem here is a desire for compartmentalization that simply does not exist.

It seems there are many different kinds of warn()s that can be triggered in different ways at different times. Some might happen in an interrupt handler, others might be the result of a filesystem or driver problem, and then some other might be the result of something actually triggered by userspace. So not only are warn()s not tagged by probable cause, but tagging them with that may be impossible.

Warn()s also occur in the shared security boundary of "all of kernel space." There is not theoretical limit to what state might be contaminated. It might be limited to only what is currently being processed. It might affect the whole subsystem. Or it could lead to corruption to anything else the kernel is doing and possibly take the whole system down. So not only are warn()s not tagged with their probably effects, but it's quite possibly impossible to do so.

Without knowing what caused a warn, and what effects it might have, it is impossible to take any decision more fine-grained than "do nothing" or "reset the system." You can't reliably kill the culprit or avoid the conditions that caused it. You can't reliably determine the affected area and pick an appropriate mitigation (flushing a buffer, killing a process, killing a subsystem, or indeed shutting down a totally-compromised system).

What the kernel devs desire is a system like minix, where the various subsystems are isolated enough that anything bad happening in one is reasonably assured to not have affected the others, and where the components are fine grained enough that one experiencing a problem can be automatically killed without too much cost. This is fundamentally impossible outside of a microkernel.

I'm not saying that minix or other microkernels are better, but I am saying that what people desire is just not an option with the design choices that linux has made.