Searched full:shadow (Results 1 – 25 of 58) sorted by relevance
123
| /Documentation/arch/x86/ |
| D | shstk.rst | 4 Control-flow Enforcement Technology (CET) Shadow Stack
14 CET introduces shadow stack and indirect branch tracking (IBT). A shadow stack
17 return address to both the normal stack and the shadow stack. Upon
18 function return, the processor pops the shadow stack copy and compares it
21 as marked by the compiler with 'ENDBR' opcodes. Not all CPU's have both Shadow
23 shadow stack and kernel IBT are supported.
25 Requirements to use Shadow Stack
28 To use userspace shadow stack you need HW that supports it, a kernel
31 The kernel Kconfig option is X86_USER_SHADOW_STACK. When compiled in, shadow
34 To build a user shadow stack enabled kernel, Binutils v2.29 or LLVM v6 or later
[all …]
|
| /Documentation/livepatch/ |
| D | shadow-vars.rst | 2 Shadow Variables
5 Shadow variables are a simple way for livepatch modules to associate
6 additional "shadow" data with existing data structures. Shadow data is
8 unmodified. The shadow variable API described in this document is used
9 to allocate/add and remove/free shadow variables to/from their parents.
13 shadow data. The numeric identifier is a simple enumeration that may be
14 used to describe shadow variable version, class or type, etc. More
16 numeric id subsequently filters hashtable queries. Multiple shadow
24 (See the full API usage docbook notes in livepatch/shadow.c.)
26 A hashtable references all shadow variables. These references are
[all …]
|
| D | api.rst | 14 Shadow Variables
17 .. kernel-doc:: kernel/livepatch/shadow.c
|
| D | index.rst | 14 shadow-vars
|
| D | cumulative-patches.rst | 96 - There is no special handling of shadow variables. Livepatch authors
101 A good practice might be to remove shadow variables in the post-unpatch
|
| /Documentation/virt/kvm/x86/ |
| D | mmu.rst | 4 The x86 kvm shadow mmu
55 spte shadow pte (referring to pfns)
87 direct mode; otherwise it operates in shadow mode (see below).
118 Shadow pages
121 The principal data structure is the shadow page, 'struct kvm_mmu_page'. A
122 shadow page contains 512 sptes, which can be either leaf or nonleaf sptes. A
123 shadow page may contain a mix of leaf and nonleaf sptes.
126 is not related to a translation directly. It points to other shadow pages.
150 Shadow pages contain the following information:
152 The level in the shadow paging hierarchy that this shadow page belongs to.
[all …]
|
| /Documentation/dev-tools/ |
| D | kmsan.rst | 95 incorrect shadow/origin values, likely leading to false positives. Functions
132 KMSAN shadow memory
135 KMSAN associates a metadata byte (also called shadow byte) with every byte of
136 kernel memory. A bit in the shadow byte is set iff the corresponding bit of the
138 setting its shadow bytes to ``0xff``) is called poisoning, marking it
139 initialized (setting the shadow bytes to ``0x00``) is called unpoisoning.
146 Compiler instrumentation also tracks the shadow values as they are used along
148 ``mm/kmsan/`` to persist shadow values.
150 The shadow value of a basic or compound type is an array of bytes of the same
152 When a value is read from memory, its shadow memory is also obtained and
[all …]
|
| D | kasan.rst | 256 granule is encoded in one shadow byte. Those 8 bytes can be accessible,
258 encoding for each shadow byte: 00 means that all 8 bytes of the corresponding
265 In the report above, the arrow points to the shadow byte ``03``, which means
307 Software KASAN modes use shadow memory to record whether each byte of memory is
308 safe to access and use compile-time instrumentation to insert shadow memory
311 Generic KASAN dedicates 1/8th of kernel memory to its shadow memory (16TB
313 translate a memory address to its corresponding shadow address.
315 Here is the function which translates an address to its corresponding shadow
329 memory accesses are valid or not by checking corresponding shadow memory.
332 directly inserts the code to check shadow memory. This option significantly
[all …]
|
| /Documentation/arch/powerpc/ |
| D | kasan.txt | 8 The shadow area sits at the top of the kernel virtual memory space above the
43 To avoid this limitation, the KASAN shadow would have to be placed inside the
53 - Alternatively, we can place the shadow at the _end_ of memory, but this
|
| /Documentation/fb/ |
| D | udlfb.rst | 13 result with a local shadow of the remote hardware framebuffer to identify
91 modprobe udlfb fb_defio=0 console=1 shadow=1
106 options udlfb fb_defio=0 console=1 shadow=1
125 shadow Allocate a 2nd framebuffer to shadow what's currently across
129 default: shadow=1
153 unchanged, based on a shadow framebuffer check
|
| /Documentation/devicetree/bindings/gpio/ |
| D | gpio-mm-lantiq.txt | 19 - lantiq,shadow : The default value that we shall assume as already set on the
36 lantiq,shadow = <0x77f>
|
| D | gpio-stp-xway.yaml | 36 lantiq,shadow:
93 lantiq,shadow = <0xffffff>;
|
| /Documentation/infiniband/ |
| D | tag_matching.rst | 48 maintained by the hardware, with the software expected to shadow this list.
64 Software is expected to shadow this list, to help with processing MPI cancel
66 tightly synchronized with respect to the tag-matching operation, this shadow
|
| /Documentation/arch/s390/ |
| D | mm.rst | 20 instrumentation, as well as the KASAN shadow memory itself is
107 +KASAN_SHADOW_START+ KASAN shadow memory start
109 | KASAN shadow | KASAN untracked
|
| /Documentation/arch/arm64/ |
| D | memory.rst | 33 [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
50 [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
111 to the kasan shadow being a fraction of the entire kernel VA space,
112 the end of the kasan shadow must also be in the higher half of the
114 the end of the kasan shadow is invariant and dependent on ~0UL,
|
| D | kasan-offsets.sh | 3 # Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW
|
| /Documentation/devicetree/bindings/pci/ |
| D | snps,dw-pcie-ep.yaml | 52 Shadow DWC PCIe config-space registers. This space is selected
54 the PCI-SIG PCIe CFG-space with the shadow registers for some
57 but still there are some shadow registers available for the
|
| D | snps,dw-pcie.yaml | 61 Shadow DWC PCIe config-space registers. This space is selected
63 the PCI-SIG PCIe CFG-space with the shadow registers for some
66 but still there are some shadow registers available for the
|
| D | rockchip-dw-pcie-ep.yaml | 30 - description: Data Bus Interface (DBI) shadow registers
|
| /Documentation/scsi/ |
| D | hptiop.rst | 95 0x4058 Outbound List Copy Pointer Shadow Base Address Low
96 0x405C Outbound List Copy Pointer Shadow Base Address High
176 put into the copy pointer shadow register. An outbound interrupt will be
179 - The host read the outbound list copy pointer shadow register and compare
|
| /Documentation/arch/x86/x86_64/ |
| D | mm.rst | 51 ffffec0000000000 | -20 TB | fffffbffffffffff | 16 TB | KASAN shadow memory
110 ffdf000000000000 | -8.25 PB | fffffbffffffffff | ~8 PB | KASAN shadow memory
153 range must not overlap with anything except the KASAN shadow area, which is
|
| /Documentation/arch/parisc/ |
| D | registers.rst | 94 Shadow Registers used by interruption handler code
100 The PA-RISC architecture defines 7 registers as "shadow registers".
104 Shadow registers are the GRs 1, 8, 9, 16, 17, 24, and 25.
|
| /Documentation/devicetree/bindings/pwm/ |
| D | microchip,corepwm.yaml | 45 control the duty cycle for channel x have a second "shadow"/buffer reg synthesised.
|
| /Documentation/arch/xtensa/ |
| D | mmu.rst | 80 | KASAN shadow map | KASAN_SHADOW_START 0x80400000 KASAN_SHADOW_SIZE
123 | KASAN shadow map | KASAN_SHADOW_START 0x80400000 KASAN_SHADOW_SIZE
167 | KASAN shadow map | KASAN_SHADOW_START 0x80400000 KASAN_SHADOW_SIZE
|
| /Documentation/virt/kvm/ |
| D | locking.rst | 84 write-protected by shadow page write-protection.
104 | spte is the shadow page table entry corresponding with gpte and |
270 :Protects: -shadow page/shadow tlb entry
|
123