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.\" $FreeBSD$ 29.\" 30.Dd April 29, 2021 31.Dt KASAN 9 32.Os 33.Sh NAME 34.Nm KASAN 35.Nd Kernel Address SANitizer 36.Sh SYNOPSIS 37The 38.Pa GENERIC-KASAN 39kernel configuration can be used to compile a KASAN-enabled kernel using 40.Pa GENERIC 41as a base configuration. 42Alternately, to compile KASAN into the kernel, place the following line in your 43kernel configuration file: 44.Bd -ragged -offset indent 45.Cd "options KASAN" 46.Ed 47.Pp 48.Ft void 49.Fn kasan_mark "const void *addr" "size_t size" "size_t redzsize" "uint8_t code" 50.Sh DESCRIPTION 51.Nm 52is a subsystem which leverages compiler instrumentation to detect invalid 53memory accesses in the kernel. 54Currently it is implemented only on the amd64 platform. 55.Pp 56When 57.Nm 58is compiled into the kernel, the compiler is configured to emit function 59calls upon every memory access. 60The functions are implemented by 61.Nm 62and permit run-time detection of several types of bugs including 63use-after-frees, double frees and frees of invalid pointers, and out-of-bounds 64accesses. 65These protections apply to memory allocated by 66.Xr uma 9 , 67.Xr malloc 9 68and related functions, and 69.Fn kmem_malloc 70and related functions, 71as well as global variables and kernel stacks. 72.Nm 73is conservative and will not detect all instances of these types of bugs. 74Memory accesses through the kernel map are sanitized, but accesses via the 75direct map are not. 76When 77.Nm 78is configured, the kernel aims to minimize its use of the direct map. 79.Sh IMPLEMENTATION NOTES 80.Nm 81is implemented using compiler instrumentation and a kernel runtime. 82When a 83kernel is built with the KASAN option enabled, the compiler inserts function calls 84before most memory accesses in the generated code. 85The runtime implements the corresponding functions, which decide whether a 86given access is valid. 87If not, the runtime prints a warning or panics the kernel, depending on the 88value of the 89.Sy debug.kasan.panic_on_violation 90sysctl/tunable. 91.Pp 92The 93.Nm 94runtime works by maintaining a shadow map for the kernel map. 95There exists a linear mapping between addresses in the kernel map and addresses 96in the shadow map. 97The shadow map is used to store information about the current state of 98allocations from the kernel map. 99For example, when a buffer is returned by 100.Xr malloc 9 , 101the corresponding region of the shadow map is marked to indicate that the 102buffer is valid. 103When it is freed, the shadow map is updated to mark the buffer as invalid. 104Accesses to the buffer are intercepted by the 105.Nm 106runtime and validated using the contents of the shadow map. 107.Pp 108Upon booting, all kernel memory is marked as valid. 109Kernel allocators must mark cached but free buffers as invalid, and must mark 110them valid before freeing the kernel virtual address range. 111This slightly reduces the effectiveness of 112.Nm 113but simplifies its maintenance and integration into the kernel. 114.Pp 115Updates to the shadow map are performed by calling 116.Fn kasan_mark . 117Parameter 118.Fa addr 119is the address of the buffer whose shadow is to be updated, 120.Fa size 121is the usable size of the buffer, and 122.Fa redzsize 123is the full size of the buffer allocated from lower layers of the system. 124.Fa redzsize 125must be greater than or equal to 126.Fa size . 127In some cases kernel allocators will return a buffer larger than that requested 128by the consumer; the unused space at the end is referred to as a red zone and is 129always marked as invalid. 130.Fa code 131allows the caller to specify an identifier used when marking a buffer as invalid. 132The identifier is included in any reports generated by 133.Nm 134and helps identify the source of the invalid access. 135For instance, when an item is freed to a 136.Xr uma 9 137zone, the item is marked with 138.Dv KASAN_UMA_FREED . 139See 140.In sys/asan.h 141for the available identifiers. 142If the entire buffer is to be marked valid, i.e., 143.Fa size 144and 145.Fa redzsize 146are equal, 147.Fa code 148should be 0. 149.Sh SEE ALSO 150.Xr build 7 , 151.Xr malloc 9 , 152.Xr memguard 9 , 153.Xr redzone 9 , 154.Xr uma 9 155.Sh HISTORY 156.Nm 157was ported from 158.Nx 159and first appeared in 160.Fx 14.0 . 161.Sh BUGS 162Accesses to kernel memory outside of the kernel map are ignored by the 163.Nm 164runtime. 165When 166.Nm 167is configured, the kernel memory allocators are configured to use the kernel 168map, but some uses of the direct map remain. 169For example, on amd64, accesses to page table pages are not tracked. 170.Pp 171Some kernel memory allocators explicitly permit accesses after an object has 172been freed. 173These cannot be sanitized by 174.Nm . 175For example, memory from all 176.Xr uma 9 177zones initialized with the 178.Dv UMA_ZONE_NOFREE 179flag are not sanitized. 180