1.\"- 2.\" Copyright (c) 2021 The FreeBSD Foundation 3.\" 4.\" This documentation was written by Mark Johnston under sponsorship from 5.\" the FreeBSD Foundation. 6.\" 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 1. Redistributions of source code must retain the above copyright 11.\" notice, this list of conditions and the following disclaimer. 12.\" 2. Redistributions in binary form must reproduce the above copyright 13.\" notice, this list of conditions and the following disclaimer in the 14.\" documentation and/or other materials provided with the distribution. 15.\" 16.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND 17.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 18.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 19.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE 20.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 21.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 22.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 23.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 24.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 25.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 26.\" SUCH DAMAGE. 27.\" 28.Dd October 13, 2023 29.Dt KASAN 9 30.Os 31.Sh NAME 32.Nm kasan 33.Nd kernel address sanitizer 34.Sh SYNOPSIS 35To compile KASAN into the kernel, place the following line in your kernel 36configuration file: 37.Bd -ragged -offset indent 38.Cd "options KASAN" 39.Ed 40.Pp 41.Ft void 42.Fn kasan_mark "const void *addr" "size_t size" "size_t redzsize" "uint8_t code" 43.Sh DESCRIPTION 44.Nm 45is a subsystem which leverages compiler instrumentation to detect invalid 46memory accesses in the kernel. 47Currently it is implemented only on the amd64 platform. 48.Pp 49When 50.Nm 51is compiled into the kernel, the compiler is configured to emit function 52calls upon every memory access. 53The functions are implemented by 54.Nm 55and permit run-time detection of several types of bugs including 56use-after-frees, double frees and frees of invalid pointers, and out-of-bounds 57accesses. 58These protections apply to memory allocated by 59.Xr uma 9 , 60.Xr malloc 9 61and related functions, and 62.Fn kmem_malloc 63and related functions, 64as well as global variables and kernel stacks. 65.Nm 66is conservative and will not detect all instances of these types of bugs. 67Memory accesses through the kernel map are sanitized, but accesses via the 68direct map are not. 69When 70.Nm 71is configured, the kernel aims to minimize its use of the direct map. 72.Sh IMPLEMENTATION NOTES 73.Nm 74is implemented using compiler instrumentation and a kernel runtime. 75When a 76kernel is built with the KASAN option enabled, the compiler inserts function calls 77before most memory accesses in the generated code. 78The runtime implements the corresponding functions, which decide whether a 79given access is valid. 80If not, the runtime prints a warning or panics the kernel, depending on the 81value of the 82.Sy debug.kasan.panic_on_violation 83sysctl/tunable. 84.Pp 85The 86.Nm 87runtime in a KASAN-configured kernel can be disabled by 88setting the loader tunable 89.Sy debug.kasan.disable=1 . 90.Pp 91The 92.Nm 93runtime works by maintaining a shadow map for the kernel map. 94There exists a linear mapping between addresses in the kernel map and addresses 95in the shadow map. 96The shadow map is used to store information about the current state of 97allocations from the kernel map. 98For example, when a buffer is returned by 99.Xr malloc 9 , 100the corresponding region of the shadow map is marked to indicate that the 101buffer is valid. 102When it is freed, the shadow map is updated to mark the buffer as invalid. 103Accesses to the buffer are intercepted by the 104.Nm 105runtime and validated using the contents of the shadow map. 106.Pp 107Upon booting, all kernel memory is marked as valid. 108Kernel allocators must mark cached but free buffers as invalid, and must mark 109them valid before freeing the kernel virtual address range. 110This slightly reduces the effectiveness of 111.Nm 112but simplifies its maintenance and integration into the kernel. 113.Pp 114Updates to the shadow map are performed by calling 115.Fn kasan_mark . 116Parameter 117.Fa addr 118is the address of the buffer whose shadow is to be updated, 119.Fa size 120is the usable size of the buffer, and 121.Fa redzsize 122is the full size of the buffer allocated from lower layers of the system. 123.Fa redzsize 124must be greater than or equal to 125.Fa size . 126In some cases kernel allocators will return a buffer larger than that requested 127by the consumer; the unused space at the end is referred to as a red zone and is 128always marked as invalid. 129.Fa code 130allows the caller to specify an identifier used when marking a buffer as invalid. 131The identifier is included in any reports generated by 132.Nm 133and helps identify the source of the invalid access. 134For instance, when an item is freed to a 135.Xr uma 9 136zone, the item is marked with 137.Dv KASAN_UMA_FREED . 138See 139.In sys/asan.h 140for the available identifiers. 141If the entire buffer is to be marked valid, i.e., 142.Fa size 143and 144.Fa redzsize 145are equal, 146.Fa code 147should be 0. 148.Sh SEE ALSO 149.Xr malloc 9 , 150.Xr memguard 9 , 151.Xr redzone 9 , 152.Xr uma 9 153.Sh HISTORY 154.Nm 155first appeared in 156.Fx 14.0 . 157.Sh BUGS 158Accesses to kernel memory outside of the kernel map are ignored by the 159.Nm 160runtime. 161When 162.Nm 163is configured, the kernel memory allocators are configured to use the kernel 164map, but some uses of the direct map remain. 165For example, on amd64, accesses to page table pages are not tracked. 166.Pp 167Some kernel memory allocators explicitly permit accesses after an object has 168been freed. 169These cannot be sanitized by 170.Nm . 171For example, memory from all 172.Xr uma 9 173zones initialized with the 174.Dv UMA_ZONE_NOFREE 175flag are not sanitized. 176