iv/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

kasan: docs: update shadow memory section

Browse Source 
Update the "Shadow memory" section in KASAN documentation:

 - Rearrange the introduction paragraph do it doesn't give a
   "KASAN has an issue" impression.

 - Update the list of architectures with vmalloc support.

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

Link: https://lkml.kernel.org/r/00f8c38b0fd5290a3f4dced04eaba41383e67e14.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:36 -07:00
committed by Linus Torvalds
parent bb48675e5a
commit 67ca1c0b74
1 changed files with 14 additions and 17 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -313,14 +313,11 @@ checking gets disabled.
Shadow memory Shadow memory
------------- -------------
The kernel maps memory in a number of different parts of the address The kernel maps memory in several different parts of the address space.
space. This poses something of a problem for KASAN, which requires The range of kernel virtual addresses is large: there is not enough real
that all addresses accessed by instrumented code have a valid shadow memory to support a real shadow region for every address that could be
region. accessed by the kernel. Therefore, KASAN only maps real shadow for certain
parts of the address space.
The range of kernel virtual addresses is large: there is not enough
real memory to support a real shadow region for every address that
could be accessed by the kernel.
Default behaviour Default behaviour
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~
@ -332,10 +329,9 @@ page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted. declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear This presents a problem for modules: they do not live in the linear
mapping, but in a dedicated module space. By hooking in to the module mapping but in a dedicated module space. By hooking into the module
allocator, KASAN can temporarily map real shadow memory to cover allocator, KASAN temporarily maps real shadow memory to cover them.
them. This allows detection of invalid accesses to module globals, for This allows detection of invalid accesses to module globals, for example.
example.
This also creates an incompatibility with ``VMAP_STACK``: if the stack This also creates an incompatibility with ``VMAP_STACK``: if the stack
lives in vmalloc space, it will be shadowed by the read-only page, and lives in vmalloc space, it will be shadowed by the read-only page, and
@ -346,9 +342,10 @@ CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently this is only supported on x86. cost of greater memory usage. Currently, this is supported on x86,
riscv, s390, and powerpc.
This works by hooking into vmalloc and vmap, and dynamically This works by hooking into vmalloc and vmap and dynamically
allocating real shadow memory to back the mappings. allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full Most mappings in vmalloc space are small, requiring less than a full
@ -367,10 +364,10 @@ memory.
To avoid the difficulties around swapping mappings around, KASAN expects To avoid the difficulties around swapping mappings around, KASAN expects
that the part of the shadow region that covers the vmalloc space will that the part of the shadow region that covers the vmalloc space will
not be covered by the early shadow page, but will be left not be covered by the early shadow page but will be left unmapped.
unmapped. This will require changes in arch-specific code. This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86, and can simplify support of This allows ``VMAP_STACK`` support on x86 and can simplify support of
architectures that do not have a fixed module region. architectures that do not have a fixed module region.
For developers For developers