|author||Mathieu Desnoyers <firstname.lastname@example.org>||2014-03-13 12:11:30 +1030|
|committer||Rusty Russell <email@example.com>||2014-03-13 12:11:51 +1030|
Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE
Users have reported being unable to trace non-signed modules loaded within a kernel supporting module signature. This is caused by tracepoint.c:tracepoint_module_coming() refusing to take into account tracepoints sitting within force-loaded modules (TAINT_FORCED_MODULE). The reason for this check, in the first place, is that a force-loaded module may have a struct module incompatible with the layout expected by the kernel, and can thus cause a kernel crash upon forced load of that module on a kernel with CONFIG_TRACEPOINTS=y. Tracepoints, however, specifically accept TAINT_OOT_MODULE and TAINT_CRAP, since those modules do not lead to the "very likely system crash" issue cited above for force-loaded modules. With kernels having CONFIG_MODULE_SIG=y (signed modules), a non-signed module is tainted re-using the TAINT_FORCED_MODULE taint flag. Unfortunately, this means that Tracepoints treat that module as a force-loaded module, and thus silently refuse to consider any tracepoint within this module. Since an unsigned module does not fit within the "very likely system crash" category of tainting, add a new TAINT_UNSIGNED_MODULE taint flag to specifically address this taint behavior, and accept those modules within Tracepoints. We use the letter 'X' as a taint flag character for a module being loaded that doesn't know how to sign its name (proposed by Steven Rostedt). Also add the missing 'O' entry to trace event show_module_flags() list for the sake of completeness. Signed-off-by: Mathieu Desnoyers <firstname.lastname@example.org> Acked-by: Steven Rostedt <email@example.com> NAKed-by: Ingo Molnar <firstname.lastname@example.org> CC: Thomas Gleixner <email@example.com> CC: David Howells <firstname.lastname@example.org> CC: Greg Kroah-Hartman <email@example.com> Signed-off-by: Rusty Russell <firstname.lastname@example.org>
Diffstat (limited to 'Documentation')
4 files changed, 8 insertions, 1 deletions
diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index 47064c2b1f79..b9a29cdbaccb 100644
@@ -49,3 +49,4 @@ Description: Module taint flags:
O - out-of-tree module
F - force-loaded module
C - staging driver module
+ X - unsigned module
diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index 2b40e04d3c49..b6af42e4d790 100644
@@ -53,7 +53,8 @@ This has a number of options available:
If this is off (ie. "permissive"), then modules for which the key is not
available and modules that are unsigned are permitted, but the kernel will
- be marked as being tainted.
+ be marked as being tainted, and the concerned modules will be marked as
+ tainted, shown with the character 'X'.
If this is on (ie. "restrictive"), only modules that have a valid
signature that can be verified by a public key in the kernel's possession
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 13032c0140d4..879abe289523 100644
@@ -265,6 +265,9 @@ characters, each representing a particular tainted value.
13: 'O' if an externally-built ("out-of-tree") module has been loaded.
+ 14: 'X' if an unsigned module has been loaded in a kernel supporting
+ module signature.
The primary reason for the 'Tainted: ' string is to tell kernel
debuggers if this is a clean kernel or if anything unusual has
occurred. Tainting is permanent: even if an offending module is
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index e55124e7c40c..8ebe1c047004 100644
@@ -792,6 +792,8 @@ can be ORed together:
1024 - A module from drivers/staging was loaded.
2048 - The system is working around a severe firmware bug.
4096 - An out-of-tree module has been loaded.
+8192 - An unsigned module has been loaded in a kernel supporting module