From: andrey.konovalov@linux.dev
To: Marco Elver <elver@google.com>, Alexander Potapenko <glider@google.com>
Cc: Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
kasan-dev@googlegroups.com, Peter Collingbourne <pcc@google.com>,
Evgenii Stepanov <eugenis@google.com>,
Florian Mayer <fmayer@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrey Konovalov <andreyknvl@google.com>
Subject: [PATCH mm v2 00/33] kasan: switch tag-based modes to stack ring from per-object metadata
Date: Tue, 19 Jul 2022 02:09:40 +0200 [thread overview]
Message-ID: <cover.1658189199.git.andreyknvl@google.com> (raw)
From: Andrey Konovalov <andreyknvl@google.com>
This series makes the tag-based KASAN modes use a ring buffer for storing
stack depot handles for alloc/free stack traces for slab objects instead
of per-object metadata. This ring buffer is referred to as the stack ring.
On each alloc/free of a slab object, the tagged address of the object and
the current stack trace are recorded in the stack ring.
On each bug report, if the accessed address belongs to a slab object, the
stack ring is scanned for matching entries. The newest entries are used to
print the alloc/free stack traces in the report: one entry for alloc and
one for free.
The advantages of this approach over storing stack trace handles in
per-object metadata with the tag-based KASAN modes:
- Allows to find relevant stack traces for use-after-free bugs without
using quarantine for freed memory. (Currently, if the object was
reallocated multiple times, the report contains the latest alloc/free
stack traces, not necessarily the ones relevant to the buggy allocation.)
- Allows to better identify and mark use-after-free bugs, effectively
making the CONFIG_KASAN_TAGS_IDENTIFY functionality always-on.
- Has fixed memory overhead.
The disadvantage:
- If the affected object was allocated/freed long before the bug happened
and the stack trace events were purged from the stack ring, the report
will have no stack traces.
Discussion
==========
The proposed implementation of the stack ring uses a single ring buffer for
the whole kernel. This might lead to contention due to atomic accesses to
the ring buffer index on multicore systems.
At this point, it is unknown whether the performance impact from this
contention would be significant compared to the slowdown introduced by
collecting stack traces due to the planned changes to the latter part,
see the section below.
For now, the proposed implementation is deemed to be good enough, but this
might need to be revisited once the stack collection becomes faster.
A considered alternative is to keep a separate ring buffer for each CPU
and then iterate over all of them when printing a bug report. This approach
requires somehow figuring out which of the stack rings has the freshest
stack traces for an object if multiple stack rings have them.
Further plans
=============
This series is a part of an effort to make KASAN stack trace collection
suitable for production. This requires stack trace collection to be fast
and memory-bounded.
The planned steps are:
1. Speed up stack trace collection (potentially, by using SCS;
patches on-hold until steps #2 and #3 are completed).
2. Keep stack trace handles in the stack ring (this series).
3. Add a memory-bounded mode to stack depot or provide an alternative
memory-bounded stack storage.
4. Potentially, implement stack trace collection sampling to minimize
the performance impact.
Thanks!
---
Changes v1->v2:
- Rework synchronization in the stack ring implementation.
- Dynamically allocate stack ring based on the kasan.stack_ring_size
command-line parameter.
- Multiple less significant changes, see the notes in patches for details.
Andrey Konovalov (33):
kasan: check KASAN_NO_FREE_META in __kasan_metadata_size
kasan: rename kasan_set_*_info to kasan_save_*_info
kasan: move is_kmalloc check out of save_alloc_info
kasan: split save_alloc_info implementations
kasan: drop CONFIG_KASAN_TAGS_IDENTIFY
kasan: introduce kasan_print_aux_stacks
kasan: introduce kasan_get_alloc_track
kasan: introduce kasan_init_object_meta
kasan: clear metadata functions for tag-based modes
kasan: move kasan_get_*_meta to generic.c
kasan: introduce kasan_requires_meta
kasan: introduce kasan_init_cache_meta
kasan: drop CONFIG_KASAN_GENERIC check from kasan_init_cache_meta
kasan: only define kasan_metadata_size for Generic mode
kasan: only define kasan_never_merge for Generic mode
kasan: only define metadata offsets for Generic mode
kasan: only define metadata structs for Generic mode
kasan: only define kasan_cache_create for Generic mode
kasan: pass tagged pointers to kasan_save_alloc/free_info
kasan: move kasan_get_alloc/free_track definitions
kasan: cosmetic changes in report.c
kasan: use virt_addr_valid in kasan_addr_to_page/slab
kasan: use kasan_addr_to_slab in print_address_description
kasan: make kasan_addr_to_page static
kasan: simplify print_report
kasan: introduce complete_report_info
kasan: fill in cache and object in complete_report_info
kasan: rework function arguments in report.c
kasan: introduce kasan_complete_mode_report_info
kasan: implement stack ring for tag-based modes
kasan: support kasan.stacktrace for SW_TAGS
kasan: dynamically allocate stack ring entries
kasan: better identify bug types for tag-based modes
Documentation/dev-tools/kasan.rst | 15 ++-
include/linux/kasan.h | 55 ++++------
include/linux/slab.h | 2 +-
lib/Kconfig.kasan | 8 --
mm/kasan/common.c | 175 +++---------------------------
mm/kasan/generic.c | 154 ++++++++++++++++++++++++--
mm/kasan/hw_tags.c | 39 +------
mm/kasan/kasan.h | 173 ++++++++++++++++++++---------
mm/kasan/report.c | 117 +++++++++-----------
mm/kasan/report_generic.c | 45 +++++++-
mm/kasan/report_tags.c | 128 +++++++++++++++++-----
mm/kasan/sw_tags.c | 5 +-
mm/kasan/tags.c | 138 ++++++++++++++++++-----
13 files changed, 620 insertions(+), 434 deletions(-)
--
2.25.1
next reply other threads:[~2022-07-19 0:10 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-19 0:09 andrey.konovalov [this message]
2022-07-19 0:09 ` [PATCH mm v2 01/33] kasan: check KASAN_NO_FREE_META in __kasan_metadata_size andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 02/33] kasan: rename kasan_set_*_info to kasan_save_*_info andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 03/33] kasan: move is_kmalloc check out of save_alloc_info andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 04/33] kasan: split save_alloc_info implementations andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 05/33] kasan: drop CONFIG_KASAN_TAGS_IDENTIFY andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 06/33] kasan: introduce kasan_print_aux_stacks andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 07/33] kasan: introduce kasan_get_alloc_track andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 08/33] kasan: introduce kasan_init_object_meta andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 09/33] kasan: clear metadata functions for tag-based modes andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 10/33] kasan: move kasan_get_*_meta to generic.c andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 11/33] kasan: introduce kasan_requires_meta andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 12/33] kasan: introduce kasan_init_cache_meta andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 13/33] kasan: drop CONFIG_KASAN_GENERIC check from kasan_init_cache_meta andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 14/33] kasan: only define kasan_metadata_size for Generic mode andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 15/33] kasan: only define kasan_never_merge " andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 16/33] kasan: only define metadata offsets " andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 17/33] kasan: only define metadata structs " andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 18/33] kasan: only define kasan_cache_create " andrey.konovalov
2022-07-19 0:09 ` [PATCH mm v2 19/33] kasan: pass tagged pointers to kasan_save_alloc/free_info andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 20/33] kasan: move kasan_get_alloc/free_track definitions andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 21/33] kasan: cosmetic changes in report.c andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 22/33] kasan: use virt_addr_valid in kasan_addr_to_page/slab andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 23/33] kasan: use kasan_addr_to_slab in print_address_description andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 24/33] kasan: make kasan_addr_to_page static andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 25/33] kasan: simplify print_report andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 26/33] kasan: introduce complete_report_info andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 27/33] kasan: fill in cache and object in complete_report_info andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 28/33] kasan: rework function arguments in report.c andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 29/33] kasan: introduce kasan_complete_mode_report_info andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 30/33] kasan: implement stack ring for tag-based modes andrey.konovalov
2022-07-19 11:41 ` Marco Elver
2022-07-21 20:41 ` Andrey Konovalov
2022-08-02 20:45 ` Andrey Konovalov
2022-08-03 20:28 ` Marco Elver
2022-09-05 20:40 ` Andrey Konovalov
2022-07-19 0:10 ` [PATCH mm v2 31/33] kasan: support kasan.stacktrace for SW_TAGS andrey.konovalov
2022-07-19 0:10 ` [PATCH mm v2 32/33] kasan: dynamically allocate stack ring entries andrey.konovalov
2022-08-03 20:09 ` Marco Elver
2022-09-05 20:34 ` Andrey Konovalov
2022-07-19 0:10 ` [PATCH mm v2 33/33] kasan: better identify bug types for tag-based modes andrey.konovalov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover.1658189199.git.andreyknvl@google.com \
--to=andrey.konovalov@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@gmail.com \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=eugenis@google.com \
--cc=fmayer@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pcc@google.com \
--cc=ryabinin.a.a@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).