요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. Copyright (C) 2023, Google LLC.
Kernel Address Sanitizer (KASAN)
================================
Overview
--------
Kernel Address Sanitizer (KASAN) is a dynamic memory safety error detector
designed to find out-of-bounds and use-after-free bugs.
KASAN has three modes:
1. Generic KASAN
2. Software Tag-Based KASAN
3. Hardware Tag-Based KASAN
Generic KASAN, enabled with CONFIG_KASAN_GENERIC, is the mode intended for
debugging, similar to userspace ASan. This mode is supported on many CPU
architectures, but it has significant performance and memory overheads.
Software Tag-Based KASAN or SW_TAGS KASAN, enabled with CONFIG_KASAN_SW_TAGS,
can be used for both debugging and dogfood testing, similar to userspace HWASan.
This mode is only supported for arm64, but its moderate memory overhead allows
using it for testing on memory-restricted devices with real workloads.
Hardware Tag-Based KASAN or HW_TAGS KASAN, enabled with CONFIG_KASAN_HW_TAGS,
is the mode intended to be used as an in-field memory bug detector or as a
security mitigation. This mode only works on arm64 CPUs that support MTE
(Memory Tagging Extension), but it has low memory and performance overheads and
thus can be used in production.
For details about the memory and performance impact of each KASAN mode, see the
descriptions of the corresponding Kconfig options.
The Generic and the Software Tag-Based modes are commonly referred to as the
software modes. The Software Tag-Based and the Hardware Tag-Based modes are
referred to as the tag-based modes.
Support
-------
Architectures
~~~~~~~~~~~~~
Generic KASAN is supported on x86_64, arm, arm64, powerpc, riscv, s390, xtensa,
and loongarch, and the tag-based KASAN modes are supported only on arm64.
Compilers
~~~~~~~~~
Software KASAN modes use compile-time instrumentation to insert validity checks
before every memory access and thus require a compiler version that provides
support for that. The Hardware Tag-Based mode relies on hardware to perform
these checks but still requires a compiler version that supports the memory
tagging instructions.
Generic KASAN requires GCC version 8.3.0 or later
or any Clang version supported by the kernel.
Software Tag-Based KASAN requires GCC 11+
or any Clang version supported by the kernel.
Hardware Tag-Based KASAN requires GCC 10+ or Clang 12+.
Memory types
~~~~~~~~~~~~
Generic KASAN supports finding bugs in all of slab, page_alloc, vmap, vmalloc,
stack, and global memory.
Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
memory.
For slab, both software KASAN modes support SLUB and SLAB allocators, while
Hardware Tag-Based KASAN only supports SLUB.
Usage
-----
To enable KASAN, configure the kernel with::
CONFIG_KASAN=y
and choose between ``CONFIG_KASAN_GENERIC`` (to enable Generic KASAN),
``CONFIG_KASAN_SW_TAGS`` (to enable Software Tag-Based KASAN), and
``CONFIG_KASAN_HW_TAGS`` (to enable Hardware Tag-Based KASAN).
For the software modes, also choose between ``CONFIG_KASAN_OUTLINE`` and
``CONFIG_KASAN_INLINE``. Outline and inline are compiler instrumentation types.
The former produces a smaller binary while the latter is up to 2 times faster.
To include alloc and free stack traces of affected slab objects into reports,
enable ``CONFIG_STACKTRACE``. To include alloc and free stack traces of affected
physical pages, enable ``CONFIG_PAGE_OWNER`` and boot with ``page_owner=on``.
Boot parameters
~~~~~~~~~~~~~~~
KASAN is affected by the generic ``panic_on_warn`` command line parameter.
When it is enabled, KASAN panics the kernel after printing a bug report.
By default, KASAN prints a bug report only for the first invalid memory access.
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
effectively disables ``panic_on_warn`` for KASAN reports.
Alternatively, independent of ``panic_on_warn``, the ``kasan.fault=`` boot
parameter can be used to control panic and reporting behaviour:
- ``kasan.fault=report``, ``=panic``, or ``=panic_on_write`` controls whether
to only print a KASAN report, panic the kernel, or panic the kernel on
invalid writes only (default: ``report``). The panic happens even if
``kasan_multi_shot`` is enabled. Note that when using asynchronous mode of
Hardware Tag-Based KASAN, ``kasan.fault=panic_on_write`` always panics on
asynchronously checked accesses (including reads).
Software and Hardware Tag-Based KASAN modes (see the section about various
modes below) support altering stack trace collection behavior:
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
traces collection (default: ``on``).
- ``kasan.stack_ring_size=<number of entries>`` specifies the number of entries
in the stack ring (default: ``32768``).
Hardware Tag-Based KASAN mode is intended for use in production as a security
mitigation. Therefore, it supports additional boot parameters that allow
disabling KASAN altogether or controlling its features:
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
- ``kasan.mode=sync``, ``=async`` or ``=asymm`` controls whether KASAN
is configured in synchronous, asynchronous or asymmetric mode of
execution (default: ``sync``).
Synchronous mode: a bad access is detected immediately when a tag
check fault occurs.
Asynchronous mode: a bad access detection is delayed. When a tag check
fault occurs, the information is stored in hardware (in the TFSR_EL1
register for arm64). The kernel periodically checks the hardware and
only reports tag faults during these checks.
Asymmetric mode: a bad access is detected synchronously on reads and
asynchronously on writes.
- ``kasan.write_only=off`` or ``kasan.write_only=on`` controls whether KASAN
checks the write (store) accesses only or all accesses (default: ``off``).
- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc
allocations (default: ``on``).
- ``kasan.page_alloc.sample=<sampling interval>`` makes KASAN tag only every
Nth page_alloc allocation with the order equal or greater than
``kasan.page_alloc.sample.order``, where N is the value of the ``sample``
parameter (default: ``1``, or tag every such allocation).
This parameter is intended to mitigate the performance overhead introduced
by KASAN.
Note that enabling this parameter makes Hardware Tag-Based KASAN skip checks
of allocations chosen by sampling and thus miss bad accesses to these
allocations. Use the default value for accurate bug detection.
- ``kasan.page_alloc.sample.order=<minimum page order>`` specifies the minimum
order of allocations that are affected by sampling (default: ``3``).
Only applies when ``kasan.page_alloc.sample`` is set to a value greater
than ``1``.
This parameter is intended to allow sampling only large page_alloc
allocations, which is the biggest source of the performance overhead.
Error reports
~~~~~~~~~~~~~
A typical KASAN report looks like this::
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [kasan_test]
Write of size 1 at addr ffff8801f44ec37b by task insmod/2760
CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0x94/0xd8
print_address_description+0x73/0x280
kasan_report+0x144/0x187
__asan_report_store1_noabort+0x17/0x20
kmalloc_oob_right+0xa8/0xbc [kasan_test]
kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
__do_sys_init_module+0x1c6/0x200
__x64_sys_init_module+0x6e/0xb0
do_syscall_64+0x9f/0x2c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f96443109da
RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da
RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000
RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88
R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 2760:
save_stack+0x43/0xd0
kasan_kmalloc+0xa7/0xd0
kmem_cache_alloc_trace+0xe1/0x1b0
kmalloc_oob_right+0x56/0xbc [kasan_test]
kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
__do_sys_init_module+0x1c6/0x200
__x64_sys_init_module+0x6e/0xb0
do_syscall_64+0x9f/0x2c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 815:
save_stack+0x43/0xd0
__kasan_slab_free+0x135/0x190
kasan_slab_free+0xe/0x10
kfree+0x93/0x1a0
umh_complete+0x6a/0xa0
call_usermodehelper_exec_async+0x4c3/0x640
ret_from_fork+0x35/0x40
The buggy address belongs to the object at ffff8801f44ec300
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 123 bytes inside of
128-byte region [ffff8801f44ec300, ffff8801f44ec380)
The buggy address belongs to the page:
page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0
flags: 0x200000000000100(slab)
raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
^
ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================
The report header summarizes what kind of bug happened and what kind of access
caused it. It is followed by a stack trace of the bad access, a stack trace of
where the accessed memory was allocated (in case a slab object was accessed),
and a stack trace of where the object was freed (in case of a use-after-free
bug report). Next comes a description of the accessed slab object and the
information about the accessed memory page.
In the end, the report shows the memory state around the accessed address.
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
memory state section of the report shows the state of one of the memory
granules that surround the accessed address.
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,
partially accessible, freed, or be a part of a redzone. KASAN uses the following
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
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
negative values to distinguish between different kinds of inaccessible memory
like redzones or freed memory (see mm/kasan/kasan.h).
In the report above, the arrow points to the shadow byte ``03``, which means
that the accessed address is partially accessible.
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.
CONFIG_KASAN_EXTRA_INFO
~~~~~~~~~~~~~~~~~~~~~~~
Enabling CONFIG_KASAN_EXTRA_INFO allows KASAN to record and report more
information. The extra information currently supported is the CPU number and
timestamp at allocation and free. More information can help find the cause of
the bug and correlate the error with other system events, at the cost of using
extra memory to record more information (more cost details in the help text of
CONFIG_KASAN_EXTRA_INFO).
Here is the report with CONFIG_KASAN_EXTRA_INFO enabled (only the
different parts are shown)::
==================================================================
...
Allocated by task 134 on cpu 5 at 229.133855s:
...
Freed by task 136 on cpu 3 at 230.199335s:
...
==================================================================
Implementation details
----------------------
Generic KASAN
~~~~~~~~~~~~~
Software KASAN modes use shadow memory to record whether each byte of memory is
safe to access and use compile-time instrumentation to insert shadow memory
checks before each memory access.
Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
to cover 128TB on x86_64) and uses direct mapping with a scale and offset to
translate a memory address to its corresponding shadow address.
Here is the function which translates an address to its corresponding shadow
address::
static inline void *kasan_mem_to_shadow(const void *addr)
{
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET;
}
where ``KASAN_SHADOW_SCALE_SHIFT = 3``.
Compile-time instrumentation is used to insert memory access checks. Compiler
inserts function calls (``__asan_load*(addr)``, ``__asan_store*(addr)``) before
each memory access of size 1, 2, 4, 8, or 16. These functions check whether
memory accesses are valid or not by checking corresponding shadow memory.
With inline instrumentation, instead of making function calls, the compiler
directly inserts the code to check shadow memory. This option significantly
enlarges the kernel, but it gives an x1.1-x2 performance boost over the
outline-instrumented kernel.
Generic KASAN is the only mode that delays the reuse of freed objects via
quarantine (see mm/kasan/quarantine.c for implementation).
Software Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Software Tag-Based KASAN uses a software memory tagging approach to checking
access validity. It is currently only implemented for the arm64 architecture.
Software Tag-Based KASAN uses the Top Byte Ignore (TBI) feature of arm64 CPUs
to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
to store memory tags associated with each 16-byte memory cell (therefore, it
dedicates 1/16th of the kernel memory for shadow memory).
On each memory allocation, Software Tag-Based KASAN generates a random tag, tags
the allocated memory with this tag, and embeds the same tag into the returned
pointer.
Software Tag-Based KASAN uses compile-time instrumentation to insert checks
before each memory access. These checks make sure that the tag of the memory
that is being accessed is equal to the tag of the pointer that is used to access
this memory. In case of a tag mismatch, Software Tag-Based KASAN prints a bug
report.
Software Tag-Based KASAN also has two instrumentation modes (outline, which
emits callbacks to check memory accesses; and inline, which performs the shadow
memory checks inline). With outline instrumentation mode, a bug report is
printed from the function that performs the access check. With inline
instrumentation, a ``brk`` instruction is emitted by the compiler, and a
dedicated ``brk`` handler is used to print bug reports.
Software Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
Hardware Tag-Based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
Hardware Tag-Based KASAN is similar to the software mode in concept but uses
hardware memory tagging support instead of compiler instrumentation and
shadow memory.
Hardware Tag-Based KASAN is currently only implemented for arm64 architecture
and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
Instruction Set Architecture and Top Byte Ignore (TBI).
Special arm64 instructions are used to assign memory tags for each allocation.
Same tags are assigned to pointers to those allocations. On every memory
access, hardware makes sure that the tag of the memory that is being accessed is
equal to the tag of the pointer that is used to access this memory. In case of a
tag mismatch, a fault is generated, and a report is printed.
Hardware Tag-Based KASAN uses 0xFF as a match-all pointer tag (accesses through
pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently
reserved to tag freed memory regions.
If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
will not be enabled. In this case, all KASAN boot parameters are ignored.
Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
support MTE (but supports TBI).
Hardware Tag-Based KASAN only reports the first found bug. After that, MTE tag
checking gets disabled.
Shadow memory
-------------
The contents of this section are only applicable to software KASAN modes.
The kernel maps memory in several different 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. Therefore, KASAN only maps real shadow for certain
parts of the address space.
Default behaviour
~~~~~~~~~~~~~~~~~
By default, architectures only map real memory over the shadow region
for the linear mapping (and potentially other small areas). For all
other areas - such as vmalloc and vmemmap space - a single read-only
page is mapped over the shadow area. This read-only shadow page
declares all memory accesses as permitted.
This presents a problem for modules: they do not live in the linear
mapping but in a dedicated module space. By hooking into the module
allocator, KASAN temporarily maps real shadow memory to cover them.
This allows detection of invalid accesses to module globals, for example.
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
the kernel will fault when trying to set up the shadow data for stack
variables.
CONFIG_KASAN_VMALLOC
~~~~~~~~~~~~~~~~~~~~
With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
cost of greater memory usage. Currently, this is supported on x86,
arm64, riscv, s390, and powerpc.
This works by hooking into vmalloc and vmap and dynamically
allocating real shadow memory to back the mappings.
Most mappings in vmalloc space are small, requiring less than a full
page of shadow space. Allocating a full shadow page per mapping would
therefore be wasteful. Furthermore, to ensure that different mappings
use different shadow pages, mappings would have to be aligned to
``KASAN_GRANULE_SIZE * PAGE_SIZE``.
Instead, KASAN shares backing space across multiple mappings. It allocates
a backing page when a mapping in vmalloc space uses a particular page
of the shadow region. This page can be shared by other vmalloc
mappings later on.
KASAN hooks into the vmap infrastructure to lazily clean up unused shadow
memory.
To avoid the difficulties around swapping mappings around, KASAN expects
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 unmapped.
This will require changes in arch-specific code.
This allows ``VMAP_STACK`` support on x86 and can simplify support of
architectures that do not have a fixed module region.
For developers
--------------
Ignoring accesses
~~~~~~~~~~~~~~~~~
Software KASAN modes use compiler instrumentation to insert validity checks.
Such instrumentation might be incompatible with some parts of the kernel, and
therefore needs to be disabled.
Other parts of the kernel might access metadata for allocated objects.
Normally, KASAN detects and reports such accesses, but in some cases (e.g.,
in memory allocators), these accesses are valid.
For software KASAN modes, to disable instrumentation for a specific file or
directory, add a ``KASAN_SANITIZE`` annotation to the respective kernel
Makefile:
- For a single file (e.g., main.o)::
KASAN_SANITIZE_main.o := n
- For all files in one directory::
KASAN_SANITIZE := n
For software KASAN modes, to disable instrumentation on a per-function basis,
use the KASAN-specific ``__no_sanitize_address`` function attribute or the
generic ``noinstr`` one.
Note that disabling compiler instrumentation (either on a per-file or a
per-function basis) makes KASAN ignore the accesses that happen directly in
that code for software KASAN modes. It does not help when the accesses happen
indirectly (through calls to instrumented functions) or with Hardware
Tag-Based KASAN, which does not use compiler instrumentation.
For software KASAN modes, to disable KASAN reports in a part of the kernel code
for the current task, annotate this part of the code with a
``kasan_disable_current()``/``kasan_enable_current()`` section. This also
disables the reports for indirect accesses that happen through function calls.
For tag-based KASAN modes, to disable access checking, use
``kasan_reset_tag()`` or ``page_kasan_tag_reset()``. Note that temporarily
disabling access checking via ``page_kasan_tag_reset()`` requires saving and
restoring the per-page KASAN tag via ``page_kasan_tag``/``page_kasan_tag_set``.
Tests
~~~~~
There are KASAN tests that allow verifying that KASAN works and can detect
certain types of memory corruptions.
All KASAN tests are integrated with the KUnit Test Framework and can be enabled
via ``CONFIG_KASAN_KUNIT_TEST``. The tests can be run and partially verified
automatically in a few different ways; see the instructions below.
Each KASAN test prints one of multiple KASAN reports if an error is detected.
Then the test prints its number and status.
When a test passes::
ok 28 - kmalloc_double_kzfree
When a test fails due to a failed ``kmalloc``::
# kmalloc_large_oob_right: ASSERTION FAILED at mm/kasan/kasan_test.c:245
Expected ptr is not null, but is
not ok 5 - kmalloc_large_oob_right
When a test fails due to a missing KASAN report::
# kmalloc_double_kzfree: EXPECTATION FAILED at mm/kasan/kasan_test.c:709
KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
not ok 28 - kmalloc_double_kzfree
At the end the cumulative status of all KASAN tests is printed. On success::
ok 1 - kasan
Or, if one of the tests failed::
not ok 1 - kasan
There are a few ways to run the KASAN tests.
1. Loadable module
With ``CONFIG_KUNIT`` enabled, the tests can be built as a loadable module
and run by loading ``kasan_test.ko`` with ``insmod`` or ``modprobe``.
2. Built-In
With ``CONFIG_KUNIT`` built-in, the tests can be built-in as well.
In this case, the tests will run at boot as a late-init call.
3. Using kunit_tool
With ``CONFIG_KUNIT`` and ``CONFIG_KASAN_KUNIT_TEST`` built-in, it is also
possible to use ``kunit_tool`` to see the results of KUnit tests in a more
readable way. This will not print the KASAN reports of the tests that passed.
See `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`_
for more up-to-date information on ``kunit_tool``.
.. _KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
KASAN 개요와 세 가지 mode
1-40SPDX 라이선스 식별자: GPL-2.0
저작권 (C) 2023, Google LLC.
Kernel Address Sanitizer (KASAN)
개요
Kernel Address Sanitizer(KASAN)는 out-of-bounds와 use-after-free bug를 찾도록 설계된 동적 memory safety error detector입니다.
KASAN에는 Generic KASAN, Software Tag-Based KASAN, Hardware Tag-Based KASAN의 세 가지 mode가 있습니다.
CONFIG_KASAN_GENERIC으로 활성화하는 Generic KASAN은 userspace ASan과 비슷한 debugging용 mode입니다. 여러 CPU architecture에서 지원하지만 performance와 memory overhead가 큽니다.
CONFIG_KASAN_SW_TAGS로 활성화하는 Software Tag-Based KASAN, 즉 SW_TAGS KASAN은 userspace HWASan과 비슷하게 debugging과 dogfood testing에 모두 사용할 수 있습니다. arm64에서만 지원하지만 memory overhead가 중간 수준이므로 memory가 제한된 device에서 실제 workload를 이용한 testing에 사용할 수 있습니다.
CONFIG_KASAN_HW_TAGS로 활성화하는 Hardware Tag-Based KASAN, 즉 HW_TAGS KASAN은 현장 memory bug detector 또는 security mitigation으로 사용하기 위한 mode입니다. MTE(Memory Tagging Extension)를 지원하는 arm64 CPU에서만 동작하지만 memory와 performance overhead가 낮아 production에서 사용할 수 있습니다.
각 KASAN mode의 memory 및 performance 영향에 관한 자세한 내용은 해당 Kconfig option 설명을 참조하십시오.
Generic과 Software Tag-Based mode를 보통 software mode라고 부릅니다. Software Tag-Based와 Hardware Tag-Based mode는 tag-based mode라고 부릅니다.
지원 architecture, compiler, memory 유형
41-80지원
Architecture
Generic KASAN은 x86_64, arm, arm64, powerpc, riscv, s390, xtensa, loongarch에서 지원하며 tag-based KASAN mode는 arm64에서만 지원합니다.
Compiler
software KASAN mode는 모든 memory access 앞에 validity check를 삽입하는 compile-time instrumentation을 사용하므로 이를 지원하는 compiler version이 필요합니다. Hardware Tag-Based mode는 hardware가 검사를 수행하지만 memory tagging instruction을 지원하는 compiler version이 여전히 필요합니다.
Generic KASAN에는 GCC 8.3.0 이상 또는 커널이 지원하는 어떤 Clang version이든 사용할 수 있습니다.
Software Tag-Based KASAN에는 GCC 11 이상 또는 커널이 지원하는 어떤 Clang version이든 사용할 수 있습니다.
Hardware Tag-Based KASAN에는 GCC 10 이상 또는 Clang 12 이상이 필요합니다.
Memory 유형
Generic KASAN은 slab, page_alloc, vmap, vmalloc, stack, global memory의 bug를 찾을 수 있습니다.
Software Tag-Based KASAN은 slab, page_alloc, vmalloc, stack memory를 지원합니다.
Hardware Tag-Based KASAN은 slab, page_alloc, non-executable vmalloc memory를 지원합니다.
slab의 경우 두 software KASAN mode 모두 SLUB와 SLAB allocator를 지원하지만 Hardware Tag-Based KASAN은 SLUB만 지원합니다.
KASAN 구성과 stack trace
81-99사용법
KASAN을 활성화하려면 커널을 다음과 같이 구성하십시오.
CONFIG_KASAN=y그리고 Generic KASAN을 위한 `CONFIG_KASAN_GENERIC`, Software Tag-Based KASAN을 위한 `CONFIG_KASAN_SW_TAGS`, Hardware Tag-Based KASAN을 위한 `CONFIG_KASAN_HW_TAGS` 가운데 하나를 선택하십시오.
software mode에서는 `CONFIG_KASAN_OUTLINE`과 `CONFIG_KASAN_INLINE` 중 하나도 선택하십시오. outline과 inline은 compiler instrumentation 유형입니다. 전자는 더 작은 binary를 만들고 후자는 최대 2배 빠릅니다.
영향을 받은 slab object의 alloc 및 free stack trace를 report에 포함하려면 `CONFIG_STACKTRACE`를 활성화하십시오. 영향을 받은 physical page의 alloc 및 free stack trace를 포함하려면 `CONFIG_PAGE_OWNER`를 활성화하고 `page_owner=on`으로 boot하십시오.
boot parameter와 hardware tag 검사 정책
100-168Boot parameter
KASAN은 공통 `panic_on_warn` command line parameter의 영향을 받습니다. 이를 활성화하면 KASAN이 bug report를 출력한 뒤 kernel panic을 일으킵니다.
기본적으로 KASAN은 첫 번째 invalid memory access에 대해서만 bug report를 출력합니다. `kasan_multi_shot`을 사용하면 invalid access마다 report를 출력합니다. 이는 KASAN report에 대해 `panic_on_warn`을 사실상 비활성화합니다.
또는 `panic_on_warn`과 독립적으로 `kasan.fault=` boot parameter로 panic과 reporting 동작을 제어할 수 있습니다.
`kasan.fault=report`, `=panic`, `=panic_on_write`는 KASAN report만 출력할지, kernel panic을 일으킬지, invalid write에서만 panic을 일으킬지 제어합니다. 기본값은 `report`입니다. `kasan_multi_shot`이 활성화되어도 panic은 발생합니다. Hardware Tag-Based KASAN의 asynchronous mode에서는 `kasan.fault=panic_on_write`가 read를 포함해 비동기적으로 검사한 access에서 항상 panic을 일으킵니다.
Software 및 Hardware Tag-Based KASAN mode는 stack trace 수집 동작 변경을 지원합니다.
`kasan.stacktrace=off` 또는 `=on`은 alloc 및 free stack trace 수집을 비활성화하거나 활성화합니다. 기본값은 `on`입니다.
`kasan.stack_ring_size=<number of entries>`는 stack ring의 entry 수를 지정합니다. 기본값은 `32768`입니다.
Hardware Tag-Based KASAN은 production에서 security mitigation으로 사용하기 위한 mode이므로 KASAN 전체를 비활성화하거나 기능을 제어하는 추가 boot parameter를 지원합니다.
`kasan=off` 또는 `=on`은 KASAN 활성화 여부를 제어합니다. 기본값은 `on`입니다.
`kasan.mode=sync`, `=async`, `=asymm`은 KASAN을 synchronous, asynchronous, asymmetric 실행 mode 중 무엇으로 구성할지 제어합니다. 기본값은 `sync`입니다.
synchronous mode에서는 tag check fault가 발생할 때 bad access를 즉시 감지합니다. asynchronous mode에서는 감지가 지연됩니다. tag check fault가 발생하면 정보를 hardware, arm64의 경우 TFSR_EL1 register에 저장하고 kernel이 hardware를 주기적으로 검사할 때만 tag fault를 보고합니다. asymmetric mode에서는 read의 bad access를 동기적으로, write의 bad access를 비동기적으로 감지합니다.
`kasan.write_only=off` 또는 `kasan.write_only=on`은 write(store) access만 검사할지 모든 access를 검사할지 제어합니다. 기본값은 `off`입니다.
`kasan.vmalloc=off` 또는 `=on`은 vmalloc allocation tagging을 비활성화하거나 활성화합니다. 기본값은 `on`입니다.
`kasan.page_alloc.sample=<sampling interval>`은 order가 `kasan.page_alloc.sample.order` 이상인 page_alloc allocation 중 N번째마다 KASAN tag를 지정합니다. N은 `sample` 값이며 기본값은 `1`, 즉 해당하는 모든 allocation을 tag하는 것입니다. 이 parameter는 KASAN의 performance overhead를 줄이기 위한 것입니다.
이 parameter를 활성화하면 Hardware Tag-Based KASAN이 sampling에서 선택되지 않은 allocation의 검사를 건너뛰므로 해당 allocation의 bad access를 놓칠 수 있습니다. 정확한 bug 탐지를 위해서는 기본값을 사용하십시오.
`kasan.page_alloc.sample.order=<minimum page order>`는 sampling의 영향을 받는 allocation의 최소 order를 지정합니다. 기본값은 `3`입니다. `kasan.page_alloc.sample`이 `1`보다 클 때만 적용됩니다. performance overhead의 가장 큰 원인인 큰 page_alloc allocation만 sampling할 수 있게 하기 위한 parameter입니다.
KASAN error report 해석
169-282Error report
일반적인 KASAN report는 다음과 같습니다.
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [kasan_test]
Write of size 1 at addr ffff8801f44ec37b by task insmod/2760
CPU: 1 PID: 2760 Comm: insmod Not tainted 4.19.0-rc3+ #698
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Call Trace:
dump_stack+0x94/0xd8
print_address_description+0x73/0x280
kasan_report+0x144/0x187
__asan_report_store1_noabort+0x17/0x20
kmalloc_oob_right+0xa8/0xbc [kasan_test]
kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
__do_sys_init_module+0x1c6/0x200
__x64_sys_init_module+0x6e/0xb0
do_syscall_64+0x9f/0x2c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f96443109da
RSP: 002b:00007ffcf0b51b08 EFLAGS: 00000202 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055dc3ee521a0 RCX: 00007f96443109da
RDX: 00007f96445cff88 RSI: 0000000000057a50 RDI: 00007f9644992000
RBP: 000055dc3ee510b0 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f964430cd0a R11: 0000000000000202 R12: 00007f96445cff88
R13: 000055dc3ee51090 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 2760:
save_stack+0x43/0xd0
kasan_kmalloc+0xa7/0xd0
kmem_cache_alloc_trace+0xe1/0x1b0
kmalloc_oob_right+0x56/0xbc [kasan_test]
kmalloc_tests_init+0x16/0x700 [kasan_test]
do_one_initcall+0xa5/0x3ae
do_init_module+0x1b6/0x547
load_module+0x75df/0x8070
__do_sys_init_module+0x1c6/0x200
__x64_sys_init_module+0x6e/0xb0
do_syscall_64+0x9f/0x2c0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Freed by task 815:
save_stack+0x43/0xd0
__kasan_slab_free+0x135/0x190
kasan_slab_free+0xe/0x10
kfree+0x93/0x1a0
umh_complete+0x6a/0xa0
call_usermodehelper_exec_async+0x4c3/0x640
ret_from_fork+0x35/0x40
The buggy address belongs to the object at ffff8801f44ec300
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 123 bytes inside of
128-byte region [ffff8801f44ec300, ffff8801f44ec380)
The buggy address belongs to the page:
page:ffffea0007d13b00 count:1 mapcount:0 mapping:ffff8801f7001640 index:0x0
flags: 0x200000000000100(slab)
raw: 0200000000000100 ffffea0007d11dc0 0000001a0000001a ffff8801f7001640
raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801f44ec200: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801f44ec280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>ffff8801f44ec300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03
^
ffff8801f44ec380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
ffff8801f44ec400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
==================================================================긴 diagnostic 출력의 각 영역이 제공하는 조사 단서를 구조화했습니다.
report header는 발생한 bug 종류와 이를 일으킨 access 종류를 요약합니다. 이어서 bad access의 stack trace, 접근한 memory가 할당된 위치의 stack trace(slab object에 접근한 경우), object를 해제한 위치의 stack trace(use-after-free report인 경우)가 나옵니다. 다음에는 접근한 slab object 설명과 접근한 memory page 정보가 나옵니다.
마지막에는 접근한 address 주변의 memory state를 보여 줍니다. 내부적으로 KASAN은 KASAN mode에 따라 8 또는 16 aligned byte인 각 memory granule의 상태를 따로 추적합니다. report의 memory state 절에 있는 각 숫자는 접근한 address 주변 granule 하나의 상태를 나타냅니다.
Generic KASAN의 memory granule 크기는 8이며 각 granule 상태는 shadow byte 하나로 encode됩니다. 8byte는 accessible, partially accessible, freed 또는 redzone 일부일 수 있습니다. shadow byte `00`은 해당 8byte 모두 접근 가능함을 뜻합니다. N(1 <= N <= 7)은 처음 Nbyte가 접근 가능하고 나머지 (8 - N)byte는 접근할 수 없음을 뜻합니다. 음수 값은 8byte word 전체에 접근할 수 없음을 나타냅니다. KASAN은 redzone이나 freed memory 같은 접근 불가 유형을 구분하려고 서로 다른 음수 값을 사용합니다. `mm/kasan/kasan.h`를 참조하십시오.
위 report에서 화살표는 shadow byte `03`을 가리키며, 이는 접근한 address가 부분적으로만 접근 가능함을 뜻합니다.
tag-based KASAN mode에서는 report의 마지막 절이 접근한 address 주변의 memory tag를 보여 줍니다. '구현 세부 사항' 절을 참조하십시오.
`slab-out-of-bounds`나 `use-after-free` 같은 KASAN bug title은 best-effort 결과입니다. KASAN은 제한된 정보를 바탕으로 가장 가능성 높은 bug type을 출력하며 실제 bug type은 다를 수 있습니다.
Generic KASAN은 최대 두 개의 auxiliary call stack trace도 보고합니다. 이 trace는 object와 상호작용했지만 bad access stack trace에는 직접 나타나지 않는 코드 위치를 가리킵니다. 현재는 `call_rcu()`와 workqueue queuing이 포함됩니다.
CONFIG_KASAN_EXTRA_INFO
283-303CONFIG_KASAN_EXTRA_INFO
CONFIG_KASAN_EXTRA_INFO를 활성화하면 KASAN이 더 많은 정보를 기록하고 보고할 수 있습니다. 현재 지원하는 추가 정보는 allocation 및 free 시점의 CPU 번호와 timestamp입니다. 추가 정보는 더 많은 정보를 기록하기 위한 memory 비용을 대가로 bug 원인을 찾고 error를 다른 system event와 연관시키는 데 도움을 줍니다. 비용에 관한 자세한 내용은 CONFIG_KASAN_EXTRA_INFO help text에 있습니다.
CONFIG_KASAN_EXTRA_INFO를 활성화한 report는 다음과 같습니다. 달라지는 부분만 표시합니다.
==================================================================
...
Allocated by task 134 on cpu 5 at 229.133855s:
...
Freed by task 136 on cpu 3 at 230.199335s:
...
==================================================================Generic KASAN 구현
304-341구현 세부 사항
Generic KASAN
software KASAN mode는 각 memory byte에 안전하게 접근할 수 있는지를 shadow memory에 기록하고 compile-time instrumentation으로 각 memory access 앞에 shadow memory check를 삽입합니다.
Generic KASAN은 kernel memory의 1/8을 shadow memory에 할당합니다. x86_64에서는 128TB를 다루기 위해 16TB를 사용하며, scale과 offset을 이용한 direct mapping으로 memory address를 해당 shadow address로 변환합니다.
address를 해당 shadow address로 변환하는 함수는 다음과 같습니다.
static inline void *kasan_mem_to_shadow(const void *addr)
{
return (void *)((unsigned long)addr >> KASAN_SHADOW_SCALE_SHIFT)
+ KASAN_SHADOW_OFFSET;
}여기서 `KASAN_SHADOW_SCALE_SHIFT = 3`입니다.
compile-time instrumentation이 memory access check를 삽입합니다. compiler는 크기 1, 2, 4, 8, 16의 각 memory access 앞에 `__asan_load*(addr)` 또는 `__asan_store*(addr)` 함수 호출을 삽입합니다. 이 함수들은 해당 shadow memory를 검사해 memory access가 유효한지 확인합니다.
inline instrumentation에서는 함수 호출 대신 compiler가 shadow memory 검사 코드를 직접 삽입합니다. 이 옵션은 kernel을 상당히 크게 만들지만 outline instrumentation kernel보다 1.1배에서 2배 빠릅니다.
Generic KASAN은 quarantine을 통해 freed object의 재사용을 지연하는 유일한 mode입니다. 구현은 `mm/kasan/quarantine.c`를 참조하십시오.
Software Tag-Based KASAN 구현
342-373Software Tag-Based KASAN
Software Tag-Based KASAN은 software memory tagging 방식으로 access validity를 검사합니다. 현재 arm64 architecture에만 구현되어 있습니다.
arm64 CPU의 Top Byte Ignore(TBI) 기능을 사용해 kernel pointer의 top byte에 pointer tag를 저장합니다. shadow memory에는 각 16byte memory cell과 연관된 memory tag를 저장하므로 kernel memory의 1/16을 shadow memory에 할당합니다.
각 memory allocation에서 random tag를 생성해 할당한 memory에 지정하고 반환하는 pointer에도 같은 tag를 넣습니다.
compile-time instrumentation으로 각 memory access 앞에 검사를 삽입합니다. 접근하는 memory의 tag와 그 memory에 접근할 때 사용하는 pointer의 tag가 같은지 확인하며, tag가 일치하지 않으면 bug report를 출력합니다.
Software Tag-Based KASAN에도 outline과 inline의 두 instrumentation mode가 있습니다. outline은 memory access를 검사하는 callback을 내보내며 report는 access check 함수에서 출력됩니다. inline은 shadow memory check를 inline으로 수행하고 compiler가 `brk` instruction을 내보내며 전용 `brk` handler가 bug report를 출력합니다.
pointer tag 0xFF는 모든 tag와 일치하는 match-all tag로 사용하므로 0xFF tag pointer를 통한 access는 검사하지 않습니다. 0xFE는 freed memory region에 tag를 지정하기 위해 예약되어 있습니다.
Hardware Tag-Based KASAN 구현
374-404Hardware Tag-Based KASAN
개념적으로 software mode와 비슷하지만 compiler instrumentation과 shadow memory 대신 hardware memory tagging 지원을 사용합니다.
현재 arm64 architecture에만 구현되어 있으며 ARMv8.5 Instruction Set Architecture에서 도입한 arm64 Memory Tagging Extension(MTE)과 Top Byte Ignore(TBI)를 모두 기반으로 합니다.
특수 arm64 instruction으로 각 allocation에 memory tag를 지정하고 해당 allocation의 pointer에도 같은 tag를 지정합니다. 매 memory access에서 hardware가 memory tag와 pointer tag가 같은지 확인합니다. tag가 다르면 fault가 발생하고 report가 출력됩니다.
0xFF를 match-all pointer tag로 사용해 이 tag를 가진 pointer access는 검사하지 않습니다. 0xFE는 freed memory region tagging에 예약되어 있습니다.
hardware가 MTE를 지원하지 않는 ARMv8.5 이전 환경에서는 Hardware Tag-Based KASAN이 활성화되지 않으며 모든 KASAN boot parameter를 무시합니다.
CONFIG_KASAN_HW_TAGS를 활성화하면 항상 in-kernel TBI도 활성화됩니다. `kasan.mode=off`를 지정했거나 hardware가 MTE는 지원하지 않고 TBI만 지원해도 마찬가지입니다.
Hardware Tag-Based KASAN은 처음 발견한 bug만 보고하며 이후에는 MTE tag checking을 비활성화합니다.
shadow memory와 CONFIG_KASAN_VMALLOC
405-466Shadow memory
이 절의 내용은 software KASAN mode에만 적용됩니다.
kernel은 address space의 여러 영역에 memory를 mapping합니다. kernel virtual address 범위가 매우 커서 kernel이 접근할 수 있는 모든 address마다 실제 shadow region을 지원할 real memory가 충분하지 않습니다. 따라서 KASAN은 address space의 특정 영역에만 실제 shadow를 mapping합니다.
기본 동작
기본적으로 architecture는 linear mapping과 일부 작은 영역의 shadow region에만 real memory를 mapping합니다. vmalloc 및 vmemmap space 같은 다른 모든 영역에는 shadow area 전체에 하나의 read-only page를 mapping하며, 이 page는 모든 memory access를 허용된 것으로 선언합니다.
module은 linear mapping이 아니라 전용 module space에 있으므로 문제가 됩니다. KASAN은 module allocator에 hook을 걸어 module을 다루는 동안 real shadow memory를 임시로 mapping합니다. 이를 통해 module global에 대한 invalid access 등을 탐지할 수 있습니다.
이 방식은 `VMAP_STACK`과도 호환되지 않습니다. stack이 vmalloc space에 있으면 read-only page가 shadow를 제공하므로 kernel이 stack variable의 shadow data를 설정하려 할 때 fault가 발생합니다.
CONFIG_KASAN_VMALLOC
`CONFIG_KASAN_VMALLOC`을 사용하면 memory 사용량 증가를 대가로 KASAN이 vmalloc space를 다룰 수 있습니다. 현재 x86, arm64, riscv, s390, powerpc에서 지원합니다.
vmalloc과 vmap에 hook을 걸고 mapping을 뒷받침하는 real shadow memory를 동적으로 할당하는 방식으로 동작합니다.
vmalloc space의 대부분 mapping은 작아서 shadow space 한 page보다 적게 필요합니다. mapping마다 shadow page 전체를 할당하면 낭비이며, 서로 다른 mapping이 서로 다른 shadow page를 사용하도록 보장하려면 mapping을 `KASAN_GRANULE_SIZE * PAGE_SIZE`에 align해야 합니다.
대신 KASAN은 여러 mapping이 backing space를 공유하게 합니다. vmalloc space의 mapping이 shadow region의 특정 page를 사용할 때 backing page를 할당하고, 이후 다른 vmalloc mapping이 이 page를 공유할 수 있습니다.
KASAN은 vmap infrastructure에 hook을 걸어 사용하지 않는 shadow memory를 lazy cleanup합니다.
mapping을 교체할 때 생기는 어려움을 피하기 위해 KASAN은 vmalloc space를 다루는 shadow region 부분을 early shadow page가 덮지 않고 unmapped 상태로 남겨 두기를 기대합니다. 이를 위해 arch-specific code 변경이 필요합니다.
이 방식은 x86에서 `VMAP_STACK` 지원을 가능하게 하고 고정 module region이 없는 architecture 지원을 단순화할 수 있습니다.
개발자를 위한 access 검사 제외
467-512개발자를 위한 정보
Access 무시
software KASAN mode는 compiler instrumentation으로 validity check를 삽입합니다. 이런 instrumentation은 kernel 일부와 호환되지 않을 수 있으므로 비활성화해야 할 수 있습니다.
kernel의 다른 부분은 할당된 object의 metadata에 접근할 수 있습니다. 일반적으로 KASAN은 이를 탐지해 보고하지만 memory allocator 같은 일부 경우에는 유효한 access입니다.
software KASAN mode에서 특정 파일이나 directory의 instrumentation을 비활성화하려면 해당 kernel Makefile에 `KASAN_SANITIZE` annotation을 추가하십시오.
단일 파일, 예를 들어 main.o에는 다음을 사용합니다.
KASAN_SANITIZE_main.o := n한 directory의 모든 파일에는 다음을 사용합니다.
KASAN_SANITIZE := nsoftware KASAN mode에서 함수별로 instrumentation을 비활성화하려면 KASAN 전용 `__no_sanitize_address` function attribute 또는 공통 `noinstr`를 사용하십시오.
file 또는 function 단위로 compiler instrumentation을 비활성화하면 software KASAN mode가 해당 코드에서 직접 발생하는 access를 무시합니다. instrumented function 호출을 통한 간접 access나 compiler instrumentation을 사용하지 않는 Hardware Tag-Based KASAN에는 도움이 되지 않습니다.
현재 task의 kernel code 일부에서 KASAN report를 비활성화하려면 그 코드를 `kasan_disable_current()`와 `kasan_enable_current()` 구간으로 표시하십시오. function call을 통해 발생하는 간접 access report도 비활성화합니다.
tag-based KASAN mode에서 access checking을 비활성화하려면 `kasan_reset_tag()` 또는 `page_kasan_tag_reset()`을 사용하십시오. `page_kasan_tag_reset()`으로 일시적으로 검사를 비활성화할 때는 `page_kasan_tag`와 `page_kasan_tag_set`으로 page별 KASAN tag를 저장하고 복원해야 합니다.
KASAN KUnit test 실행과 결과
513-571Test
KASAN이 동작하고 특정 유형의 memory corruption을 탐지할 수 있는지 검증하는 KASAN test가 있습니다.
모든 KASAN test는 KUnit Test Framework와 통합되어 있으며 `CONFIG_KASAN_KUNIT_TEST`로 활성화할 수 있습니다. 아래 설명처럼 몇 가지 방법으로 test를 실행하고 부분적으로 자동 검증할 수 있습니다.
각 KASAN test는 error가 감지되면 여러 KASAN report 중 하나를 출력한 뒤 test 번호와 status를 출력합니다.
test가 통과하면 다음과 같이 출력합니다.
ok 28 - kmalloc_double_kzfree`kmalloc` 실패로 test가 실패하면 다음과 같습니다.
# kmalloc_large_oob_right: ASSERTION FAILED at mm/kasan/kasan_test.c:245
Expected ptr is not null, but is
not ok 5 - kmalloc_large_oob_right필요한 KASAN report가 없어 test가 실패하면 다음과 같습니다.
# kmalloc_double_kzfree: EXPECTATION FAILED at mm/kasan/kasan_test.c:709
KASAN failure expected in "kfree_sensitive(ptr)", but none occurred
not ok 28 - kmalloc_double_kzfree마지막에는 모든 KASAN test의 누적 status를 출력합니다. 성공한 경우는 다음과 같습니다.
ok 1 - kasantest 중 하나가 실패한 경우는 다음과 같습니다.
not ok 1 - kasanKASAN test를 실행하는 방법은 몇 가지가 있습니다.
1. loadable module: `CONFIG_KUNIT`이 활성화되어 있으면 test를 loadable module로 build하고 `insmod` 또는 `modprobe`로 `kasan_test.ko`를 load해 실행할 수 있습니다.
2. built-in: `CONFIG_KUNIT`이 built-in이면 test도 built-in으로 만들 수 있습니다. 이 경우 boot 중 late-init call로 실행됩니다.
3. kunit_tool 사용: `CONFIG_KUNIT`과 `CONFIG_KASAN_KUNIT_TEST`가 built-in이면 `kunit_tool`로 KUnit test 결과를 더 읽기 쉽게 볼 수 있습니다. 통과한 test의 KASAN report는 출력하지 않습니다. 최신 `kunit_tool` 정보는 `KUnit documentation <https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html>`을 참조하십시오.
KUnit: https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
요약과 해설
kasan.rst:1-571KASAN은 out-of-bounds와 use-after-free를 실행 중에 탐지합니다. Generic mode는 정밀한 debugging에, software tag mode는 arm64 test workload에, MTE 기반 hardware tag mode는 낮은 overhead가 필요한 production 탐지와 mitigation에 적합합니다.
mode마다 지원 memory와 compiler 요구 사항, report 정밀도, overhead가 다릅니다. 실제 운용에서는 panic·stack trace·sampling parameter를 목적에 맞게 정하고, report의 access stack과 allocation/free stack, shadow byte 또는 memory tag를 함께 해석해야 합니다.