Lines Matching refs:shadow

140 granule is encoded in one shadow byte. Those 8 bytes can be accessible,
142 encoding for each shadow byte: 0 means that all 8 bytes of the corresponding
149 In the report above the arrows point to the shadow byte 03, which means that
205 similar to that of kmemcheck: use shadow memory to record whether each byte of
207 of shadow memory on each memory access.
209 Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (e.g. 16TB
211 translate a memory address to its corresponding shadow address.
213 Here is the function which translates an address to its corresponding shadow
227 access is valid or not by checking corresponding shadow memory.
230 function calls GCC directly inserts the code to check the shadow memory.
251 it uses shadow memory to store memory tags associated with each 16-byte memory
252 cell (therefore it dedicates 1/16th of the kernel memory for shadow memory).
264 emits callbacks to check memory accesses; and inline, that performs the shadow
282 shadow memory.
316 that all addresses accessed by instrumented code have a valid shadow
320 real memory to support a real shadow region for every address that
326 By default, architectures only map real memory over the shadow region
329 page is mapped over the shadow area. This read-only shadow page
334 allocator, KASAN can temporarily map real shadow memory to cover
340 the kernel will fault when trying to set up the shadow data for stack
350 allocating real shadow memory to back the mappings.
353 page of shadow space. Allocating a full shadow page per mapping would
355 use different shadow pages, mappings would have to be aligned to
360 of the shadow region. This page can be shared by other vmalloc
363 KASAN hooks into the vmap infrastructure to lazily clean up unused shadow
367 that the part of the shadow region that covers the vmalloc space will
368 not be covered by the early shadow page, but will be left