もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Docs » Development tools for the kernel » The Kernel Address Sanitizer (KASAN)
The Kernel Address Sanitizer (KASAN)
Overview
KernelAddressSANitizer (KASAN) is a dynamic memory error detector designed to find out-of-bound and use-after-free bugs. KASAN has two modes: generic KASAN (similar to userspace ASan) and software tag-based KASAN (similar to userspace HWASan).
KernelAddressSANitizer (KASAN)は、動的メモリエラー検知手段です。out-of-boundやuse-after-free bugsを検知できるように設計されています。KASANは２つのmodeがあります。generic KASAN(ユーザー空間 Asanと類似)と、software tag-baed KASAN(ユーザー空間HWAsanと類似）です。
KASAN uses compile-time instrumentation to insert validity checks before every memory access, and therefore requires a compiler version that supports that.
KASANは、全メモリアクセスの前に有効性チェックをコンパイル時の計測を利用します。そして、それにはサポートしているコンパイラーバージョンが要求されます。
Generic KASAN is supported in both GCC and Clang. With GCC it requires version 4.9.2 or later for basic support and version 5.0 or later for detection of out-of-bounds accesses for stack and global variables and for inline instrumentation mode (see the Usage section). With Clang it requires version 7.0.0 or later and it doesn’t support detection of out-of-bounds accesses for global variables yet.
Generic KASANは、GCCとClangの両方でサポートされています。GCCの場合、基本サポートに対してVersion 4.9.2以降が必要であり、stackやglobal変数へのout-of-boundsの検出にはVersion 5.0以降で、inline instrumentation modeが必要です(Usage sectionを参照してください)。Clangの場合、7.0.0以降のバージョンが要求されますが、まだ、グローバル変数へのout-of-bounds 検知はサポートされていません。
Tag-based KASAN is only supported in Clang and requires version 7.0.0 or later.
Tag-based KASANはClangでだけでサポートされており、version 7.0.0以降が要求されます。
Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and riscv architectures, and tag-based KASAN is supported only for arm64.
現在、generic KASANはx86_64, arm64, xtensa s390 そして riscv architecturesでサポートされています。そして、tag-based KASANはarm64でだけサポートされています。
Usage
To enable KASAN configure kernel with:
KASANを有効擦るるためのkernel設定は以下です。
CONFIG_KASAN = y
and choose between CONFIG_KASAN_GENERIC (to enable generic KASAN) and CONFIG_KASAN_SW_TAGS (to enable software tag-based KASAN).
そして、(generic KASANを有効にするために)CONFIG_KASAN_GENERIC、あるいは、(software tag-based KASANを有効にするために）CONFIG_KASAN_SW_TAGSのどちらかを選択してください。
You also need to choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and inline are compiler instrumentation types. The former produces smaller binary while the latter is 1.1 - 2 times faster.
更に、CONFIG_KASAN_OUTLINEとCONFIG_LASAN_INLINEの間からも選択しなければなりません。Outlineとinlineは困憊ターのinstrumentation typeです。前者は小さいバイナリを生成します。後者は1.1-2倍、高速です。
Both KASAN modes work with both SLUB and SLAB memory allocators. For better bug detection and nicer reporting, enable CONFIG_STACKTRACE.
どちらのKASAN modesも、SLUBとSLAB memory allocatorsと一緒に使えます。更によいバグ検知とレポート報告のためには、CONFIG_STACKTRACEを有効にしてください。
To augment reports with last allocation and freeing stack of the physical page, it is recommended to enable also CONFIG_PAGE_OWNER and boot with page_owner=on.
物理ページにおける、最終的に確保された／解放しているstackについてのレポートを拡張するには、CONFIF_PAGE_OWNERもまた有効にし、起動時にpage_owner=onを設定してください。
To disable instrumentation for specific files or directories, add a line similar to the following to the respective kernel Makefile:
特定のファイルまたはディレクトリのinstrumentationを無効にするには、次のような行をそれぞれのカーネルMakefileに追加します。
- For a single file (e.g. main.o):
KASAN_SANITIZE_main.o := n
- For all files in one directory:
KASAN_SANITIZE := n
Error reports
A typical out-of-bounds access generic KASAN report looks like this:
典型的なout-of-boundsアクセス時の、generic KASAN では以下のような報告を行います。
==================================================================
BUG: KASAN: slab-out-of-bounds in kmalloc_oob_right+0xa8/0xbc [test_kasan]
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 [test_kasan]
kmalloc_tests_init+0x16/0x700 [test_kasan]
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 [test_kasan]
kmalloc_tests_init+0x16/0x700 [test_kasan]
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 header of the report provides a short summary of what kind of bug happened and what kind of access caused it. It’s followed by a stack trace of the bad access, a stack trace of where the accessed memory was allocated (in case bad access happens on a slab object), 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 information about the accessed memory page.
レポートのヘッダ部では、どのようなバグが起きたのか、どんな種類のアクセスだったのかについての短いサマリーが提供されます。そのあとに、不正アクセスのstack trace、アクセスされたメモリが確保されたときのstack trace(slab objctにおいて不正アクセスがあった場合）、オブジェクトがfreeされたときのstack trace(use-after-free bug reportの場合）が続きます。その次には、アクセスされたslab objectのdescriptionと、アクセスされたmemory pageに関する情報が続きます。
In the last section the report shows memory state around the accessed address. Reading this part requires some understanding of how KASAN works.
最期のセクションでは、アクセスされたアドレス週販のメモリの状態が表示されます。この部分を読みには、KASAN worksに関する理解が必要となります。
The state of each 8 aligned bytes of memory is encoded in one shadow byte. Those 8 bytes can be accessible, partially accessible, freed or be a redzone. We use the following encoding for each shadow byte:
- 0 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.
We use different negative values to distinguish between different kinds of inaccessible memory like redzones or freed memory (see mm/kasan/kasan.h).
メモリ上のそれぞれの8 aligned byteの状態は、あるshadow byteにencodeされます。これら8bytesは、部分的なアクセスや解放、redzoneにすることができます。それぞれのshadow byteに対して、次のようなencodingを用います。
- 0は、対応するメモリ領域の8バイト全てに、アクセスできることを意味します。
- number N ( 1<= N <=7)は、最初のNバイトがアクセス可能であり、そのほかの(8-N)byteがそうではないことを意味します。
- 負の数は、対象の8byteがアクセス不可能であることを意味します。
In the report above the arrows point to the shadow byte 03, which means that the accessed address is partially accessible.
上記レポートでは、矢印がshadow byte 03を示しています。アクセスされたアドレスに部分的にアクセス可能であることを意味します。
For tag-based KASAN this last report section shows the memory tags around the accessed address (see Implementation details section).
tag-based KASANでは、最終レポートせきょんでは、アクセスされたアドレス周辺のmemory tagを表示しています（see Implementation details sectionを参照してください）