Re: [PATCH v5] kernel: add panic_on_taint

2020-05-15 Thread Luis Chamberlain
On Fri, May 15, 2020 at 01:55:02PM -0400, Rafael Aquini wrote:
> Analogously to the introduction of panic_on_warn, this patch introduces a 
> kernel
> option named panic_on_taint in order to provide a simple and generic way to 
> stop
> execution and catch a coredump when the kernel gets tainted by any given flag.
> 
> This is useful for debugging sessions as it avoids having to rebuild the 
> kernel
> to explicitly add calls to panic() into the code sites that introduce the 
> taint
> flags of interest. For instance, if one is interested in proceeding with a
> post-mortem analysis at the point a given code path is hitting a bad page
> (i.e. unaccount_page_cache_page(), or slab_bug()), a coredump can be collected
> by rebooting the kernel with 'panic_on_taint=0x20' amended to the command 
> line.
> 
> Another, perhaps less frequent, use for this option would be as a mean for
> assuring a security policy case where only a subset of taints, or no single
> taint (in paranoid mode), is allowed for the running system.
> The optional switch 'nousertaint' is handy in this particular scenario,
> as it will avoid userspace induced crashes by writes to sysctl interface
> /proc/sys/kernel/tainted causing false positive hits for such policies.
> 
> Suggested-by: Qian Cai 
> Signed-off-by: Rafael Aquini 

Reviewed-by: Luis Chamberlain 

  Luis


[PATCH v5] kernel: add panic_on_taint

2020-05-15 Thread Rafael Aquini
Analogously to the introduction of panic_on_warn, this patch introduces a kernel
option named panic_on_taint in order to provide a simple and generic way to stop
execution and catch a coredump when the kernel gets tainted by any given flag.

This is useful for debugging sessions as it avoids having to rebuild the kernel
to explicitly add calls to panic() into the code sites that introduce the taint
flags of interest. For instance, if one is interested in proceeding with a
post-mortem analysis at the point a given code path is hitting a bad page
(i.e. unaccount_page_cache_page(), or slab_bug()), a coredump can be collected
by rebooting the kernel with 'panic_on_taint=0x20' amended to the command line.

Another, perhaps less frequent, use for this option would be as a mean for
assuring a security policy case where only a subset of taints, or no single
taint (in paranoid mode), is allowed for the running system.
The optional switch 'nousertaint' is handy in this particular scenario,
as it will avoid userspace induced crashes by writes to sysctl interface
/proc/sys/kernel/tainted causing false positive hits for such policies.

Suggested-by: Qian Cai 
Signed-off-by: Rafael Aquini 
---
Changelog:
* v2: get rid of unnecessary/misguided compiler hints   (Luis)
  enhance documentation text for the new kernel parameter   (Randy)
* v3: drop sysctl interface, keep it only as a kernel parameter (Luis)
* v4: change panic_on_taint input from alphabetical taint flags
  to hexadecimal bitmasks, for clarity and extendability(Luis)
* v5: add doc note on the potential effects of panic_on_taint
  with notaintuser on writes to kernel.tainted sysctl knob  (Luis)

 Documentation/admin-guide/kdump/kdump.rst |  8 +
 .../admin-guide/kernel-parameters.txt | 13 +++
 Documentation/admin-guide/sysctl/kernel.rst   |  7 
 include/linux/kernel.h|  3 ++
 kernel/panic.c| 34 +++
 kernel/sysctl.c   | 11 +-
 6 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kdump/kdump.rst 
b/Documentation/admin-guide/kdump/kdump.rst
index ac7e131d2935..2da65fef2a1c 100644
--- a/Documentation/admin-guide/kdump/kdump.rst
+++ b/Documentation/admin-guide/kdump/kdump.rst
@@ -521,6 +521,14 @@ will cause a kdump to occur at the panic() call.  In cases 
where a user wants
 to specify this during runtime, /proc/sys/kernel/panic_on_warn can be set to 1
 to achieve the same behaviour.
 
+Trigger Kdump on add_taint()
+
+
+The kernel parameter panic_on_taint facilitates a conditional call to panic()
+from within add_taint() whenever the value set in this bitmask matches with the
+bit flag being set by add_taint().
+This will cause a kdump to occur at the add_taint()->panic() call.
+
 Contact
 ===
 
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index d9197499aad1..27b988acb4db 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3422,6 +3422,19 @@
bit 4: print ftrace buffer
bit 5: print all printk messages in buffer
 
+   panic_on_taint= Bitmask for conditionally call panic() in add_taint()
+   Format: [,nousertaint]
+   Hexadecimal bitmask representing the set of TAINT flags
+   that will cause the kernel to panic when add_taint() is
+   called with any of the flags in this set.
+   The optional switch "nousertaint" can be utilized to
+   prevent userspace forced crashes by writing to sysctl
+   /proc/sys/kernel/tainted any flagset matching with the
+   bitmask set on panic_on_taint.
+   See Documentation/admin-guide/tainted-kernels.rst for
+   extra details on the taint flags that users can pick
+   to compose the bitmask to assign to panic_on_taint.
+
panic_on_warn   panic() instead of WARN().  Useful to cause kdump
on a WARN().
 
diff --git a/Documentation/admin-guide/sysctl/kernel.rst 
b/Documentation/admin-guide/sysctl/kernel.rst
index c6c27db68d4c..427ce0a86b36 100644
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@ -1241,6 +1241,13 @@ ORed together. The letters are seen in "Tainted" line of 
Oops reports.
 
 See :doc:`/admin-guide/tainted-kernels` for more information.
 
+Note:
+  writes to this sysctl interface will fail with ``EINVAL`` if the kernel is
+  booted with the command line option ``panic_on_taint=,nousertaint``
+  and any of the ORed together values being written to ``tainted`` match with
+  the bitmask declared on panic_on_taint.
+  See