moonjuice/kernel_arpi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

kasan: docs: update error reports section

Browse Source 
Update the "Error reports" section in KASAN documentation:

 - Mention that bug titles are best-effort.

 - Move and reword the part about auxiliary stacks from "Implementation
   details".

 - Punctuation, readability, and other minor clean-ups.

Link: https://lkml.kernel.org/r/3531e8fe6972cf39d1954e3643237b19eb21227e.1615559068.git.andreyknvl@google.com
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Marco Elver <elver@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Andrey Konovalov
2021-04-29 23:00:21 -07:00
committed by Linus Torvalds
parent 86e6f08dd2
commit 836f79a266
1 changed files with 26 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
Documentation/dev-tools/kasan.rst
View File

@@ -60,7 +60,7 @@ physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Error reports Error reports
~~~~~~~~~~~~~ ~~~~~~~~~~~~~
A typical out-of-bounds access generic KASAN report looks like this:: A typical KASAN report looks like this::
================================================================== ==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan] BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
@@ -133,33 +133,43 @@ A typical out-of-bounds access generic KASAN report looks like this::
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
================================================================== ==================================================================
The header of the report provides a short summary of what kind of bug happened The report header summarizes what kind of bug happened and what kind of access
and what kind of access caused it. It's followed by a stack trace of the bad caused it. It is followed by a stack trace of the bad access, a stack trace of
access, a stack trace of where the accessed memory was allocated (in case bad where the accessed memory was allocated (in case a slab object was accessed),
access happens on a slab object), and a stack trace of where the object was and a stack trace of where the object was freed (in case of a use-after-free
freed (in case of a use-after-free bug report). Next comes a description of bug report). Next comes a description of the accessed slab object and the
the accessed slab object and information about the accessed memory page. information about the accessed memory page.
In the last section the report shows memory state around the accessed address. In the end, the report shows the memory state around the accessed address.
Internally KASAN tracks memory state separately for each memory granule, which Internally, KASAN tracks memory state separately for each memory granule, which
is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the is either 8 or 16 aligned bytes depending on KASAN mode. Each number in the
memory state section of the report shows the state of one of the memory memory state section of the report shows the state of one of the memory
granules that surround the accessed address. granules that surround the accessed address.
For generic KASAN the size of each memory granule is 8. The state of each For generic KASAN, the size of each memory granule is 8. The state of each
granule is encoded in one shadow byte. Those 8 bytes can be accessible, granule is encoded in one shadow byte. Those 8 bytes can be accessible,
partially accessible, freed or be a part of a redzone. KASAN uses the following partially accessible, freed, or be a part of a redzone. KASAN uses the following
encoding for each shadow byte: 0 means that all 8 bytes of the corresponding encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
memory region are accessible; number N (1 <= N <= 7) means that the first N memory region are accessible; number N (1 <= N <= 7) means that the first N
bytes are accessible, and other (8 - N) bytes are not; any negative value bytes are accessible, and other (8 - N) bytes are not; any negative value
indicates that the entire 8-byte word is inaccessible. KASAN uses different indicates that the entire 8-byte word is inaccessible. KASAN uses different
negative values to distinguish between different kinds of inaccessible memory negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h). like redzones or freed memory (see mm/kasan/kasan.h).
In the report above the arrows point to the shadow byte 03, which means that In the report above, the arrow points to the shadow byte ``03``, which means
the accessed address is partially accessible. For tag-based KASAN modes this that the accessed address is partially accessible.
last report section shows the memory tags around the accessed address
(see the `Implementation details`_ section). For tag-based KASAN modes, this last report section shows the memory tags around
the accessed address (see the `Implementation details`_ section).
Note that KASAN bug titles (like ``slab-out-of-bounds`` or ``use-after-free``)
are best-effort: KASAN prints the most probable bug type based on the limited
information it has. The actual type of the bug might be different.
Generic KASAN also reports up to two auxiliary call stack traces. These stack
traces point to places in code that interacted with the object but that are not
directly present in the bad access stack trace. Currently, this includes
call_rcu() and workqueue queuing.
Boot parameters Boot parameters
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
@@ -223,10 +233,6 @@ function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel. boost over outline instrumented kernel.
Generic KASAN also reports the last 2 call stacks to creation of work that
potentially has access to an object. Call stacks for the following are shown:
call_rcu() and workqueue queuing.
Generic KASAN is the only mode that delays the reuse of freed object via Generic KASAN is the only mode that delays the reuse of freed object via
quarantine (see mm/kasan/quarantine.c for implementation). quarantine (see mm/kasan/quarantine.c for implementation).