On Mon, Feb 03, 2020 at 10:06:11AM -0500, Qian Cai wrote:

On Mon, 2020-02-03 at 15:08 +0100, Christian Borntraeger wrote:

quoted

On 29.01.20 19:39, Qian Cai wrote:

quoted

quoted

On Jan 29, 2020, at 1:08 PM, Grzegorz Halat [off-list ref] wrote:

Memory management subsystem performs various checks at runtime,
if an inconsistency is detected then such event is being logged and kernel
continues to run. While debugging such problems it is helpful to collect
memory dump as early as possible. Currently, there is no easy way to panic
kernel when such error is detected.

It was proposed[1] to panic the kernel if panic_on_oops is set but this
approach was not accepted. One of alternative proposals was introduction of
a new sysctl.

Add a new sysctl - panic_on_inconsistent_mm. If the sysctl is set then the
kernel will be crashed when an inconsistency is detected by memory
management. This currently means panic when bad page or bad PTE
is detected(this may be extended to other places in MM).

Another use case of this sysctl may be in security-wise environments,
it may be more desired to crash machine than continue to run with
potentially damaged data structures.

It is annoying that I have to repeat my feedback, but I don’t know why
admins want to enable this by allowing normal users to crash the systems
more easily through recoverable MM bugs where I am sure we have plenty.
How does that improve the security?

There are cases where data corruption is a no-go, while "one node going down" 
is acceptable.
And then there is also the case for payed service providers that often need
a dump at the time of the problem to understand rare issues.

So I DO see value in such a thing. We should just piggy-back on panic_on_warn
I guess.

Indeed, so change pr_alert() to pr_warn() there then?

pr_* are just printk levels. If you want a full trace and to hook to
panic_on_warn, you want WARN_ON(condition) (or WARN_ON_ONCE(), etc).

-- 
Kees Cook