Lines Matching full:memory

7 KernelAddressSANitizer (KASAN) is a dynamic memory safety error detector
12 3. hardware tag-based KASAN (based on hardware memory tagging).
14 Generic KASAN is mainly used for debugging due to a large memory overhead.
16 memory overhead that allows using it with real workloads. Hardware tag-based
17 KASAN comes with low memory and performance overheads and, therefore, can be
18 used in production. Either as an in-field memory bug detector or as a security
22 validity checks before every memory access and, therefore, require a compiler
32 still requires a compiler version that supports memory tagging instructions.
35 Both software KASAN modes work with SLUB and SLAB memory allocators,
127     Memory state around the buggy address:
138 where the accessed memory was allocated (in case a slab object was accessed),
141 information about the accessed memory page.
143 In the end, the report shows the memory state around the accessed address.
144 Internally, KASAN tracks memory state separately for each memory granule, which
146 memory state section of the report shows the state of one of the memory
149 For generic KASAN, the size of each memory granule is 8. The state of each
153 memory region are accessible; number N (1 <= N <= 7) means that the first N
156 negative values to distinguish between different kinds of inaccessible memory
157 like redzones or freed memory (see mm/kasan/kasan.h).
162 For tag-based KASAN modes, this last report section shows the memory tags around
180 By default, KASAN prints a bug report only for the first invalid memory access.
215 Software KASAN modes use shadow memory to record whether each byte of memory is
216 safe to access and use compile-time instrumentation to insert shadow memory
217 checks before each memory access.
219 Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
221 translate a memory address to its corresponding shadow address.
234 Compile-time instrumentation is used to insert memory access checks. Compiler
236 each memory access of size 1, 2, 4, 8, or 16. These functions check whether
237 memory accesses are valid or not by checking corresponding shadow memory.
240 directly inserts the code to check shadow memory. This option significantly
250 Software tag-based KASAN uses a software memory tagging approach to checking
254 to store a pointer tag in the top byte of kernel pointers. It uses shadow memory
255 to store memory tags associated with each 16-byte memory cell (therefore, it
256 dedicates 1/16th of the kernel memory for shadow memory).
258 On each memory allocation, software tag-based KASAN generates a random tag, tags
259 the allocated memory with this tag, and embeds the same tag into the returned
263 before each memory access. These checks make sure that the tag of the memory
265 this memory. In case of a tag mismatch, software tag-based KASAN prints a bug
269 emits callbacks to check memory accesses; and inline, which performs the shadow
270 memory checks inline). With outline instrumentation mode, a bug report is
277 reserved to tag freed memory regions.
280 memory.
286 hardware memory tagging support instead of compiler instrumentation and
287 shadow memory.
290 and based on both arm64 Memory Tagging Extension (MTE) introduced in ARMv8.5
293 Special arm64 instructions are used to assign memory tags for each allocation.
294 Same tags are assigned to pointers to those allocations. On every memory
295 access, hardware makes sure that the tag of the memory that is being accessed is
296 equal to the tag of the pointer that is used to access this memory. In case of a
301 reserved to tag freed memory regions.
304 memory.
316 Shadow memory
319 The kernel maps memory in several different parts of the address space.
321 memory to support a real shadow region for every address that could be
328 By default, architectures only map real memory over the shadow region
332 declares all memory accesses as permitted.
336 allocator, KASAN temporarily maps real shadow memory to cover them.
348 cost of greater memory usage. Currently, this is supported on x86,
352 allocating real shadow memory to back the mappings.
366 memory.
388 in memory allocators), these accesses are valid.
427 certain types of memory corruptions. The tests consist of two parts: