• M
    Fix: module signature vs tracepoints: add new TAINT_UNSIGNED_MODULE · 66cc69e3
    Mathieu Desnoyers 提交于
    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: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Acked-by: NSteven Rostedt <rostedt@goodmis.org>
    NAKed-by: NIngo Molnar <mingo@redhat.com>
    CC: Thomas Gleixner <tglx@linutronix.de>
    CC: David Howells <dhowells@redhat.com>
    CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
    66cc69e3
panic.c 11.3 KB