linux-kernel - [PATCH RFC sl-b] Export return addresses for better diagnostics

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201205004022.GA31166@paulmck-ThinkPad-P72>
Date:   Fri, 4 Dec 2020 16:40:22 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     rcu@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, kernel-team@...com, mingo@...nel.org,
        jiangshanlai@...il.com, akpm@...ux-foundation.org,
        mathieu.desnoyers@...icios.com, josh@...htriplett.org,
        tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
        dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
        oleg@...hat.com, joel@...lfernandes.org
Subject: [PATCH RFC sl-b] Export return addresses for better diagnostics

Hello!

This series improves diagnostics by providing access to return addresses
and stack traces collected by the sl*b allocators.  If the allocator is
not configured to collect this information, the diagnostics fall back
to a reasonable approximation of their earlier state.

One use case is the queue_rcu_work() function, which might be used
by any number of kernel subsystems.  If the caller does back-to-back
invocations of queue_rcu_work(), this constitutes a double-free bug,
and (if so configured) the debug-objects system will flag this, printing
the callback function.  In most cases, printing this function suffices.
However, for double-free bugs involving queue_rcu_work(), the RCU callback
function will always be rcu_work_rcufn(), which provides almost no help to
the poor person trying to find this double-free bug.  The return address
from the allocator of the memory containing the rcu_work structure can
provide an additional valuable clue.

Another use case is the percpu_ref_switch_to_atomic_rcu() function,
which detects percpu_ref reference-count underflow.  Unfortunately,
the only data that this function has access to doesn't have much in the
way of identifying characteristics.  Yes, it might be possible to gain
more information from a crash dump, but it is more convenient for the
needed hints to be in the console log.

Unfortunately, printing the return address in this case is of little help
because this object is allocated from percpu_ref_init(), regardless of
what part of the kernel is responsible for the reference-count underflow.
However, CONFIG_STACKTRACE=y kernels (such as those enabling ftrace)
using slub with debugging enabled also collect stack traces.  This series
therefore also provides a way of extracting these stack traces to provide
additional information to those debugging percpu_ref reference-count
underflows.

The patches are as follows:

1.	Add kmem_last_alloc() to return last allocation for memory block.

2.	Add kmem_last_alloc_errstring() to provide more kmem_last_alloc()
	info.

3.	Make call_rcu() print allocation address of double-freed callback.

4.	Create kmem_last_alloc_stack() to provide stack trace in slub.

5.	percpu_ref: Print allocator upon reference-count underflow.

6.	percpu_ref: Print stack trace upon reference-count underflow.

						Thanx, Paul

------------------------------------------------------------------------

 include/linux/slab.h  |   15 ++++++++
 kernel/rcu/tree.c     |   12 +++++-
 lib/percpu-refcount.c |   39 ++++++++++++++++------
 mm/slab.c             |   61 +++++++++++++++++++++++------------
 mm/slab_common.c      |   87 ++++++++++++++++++++++++++++++++++++++++++++------
 mm/slob.c             |   11 +++++-
 mm/slub.c             |   44 +++++++++++++++++++++++--
 7 files changed, 222 insertions(+), 47 deletions(-)