Lines Matching +full:in +full:- +full:memory
1 .. SPDX-License-Identifier: GPL-2.0
9 Modern CPUs support memory permissions such as RW and NX bits. The memory
10 permission feature improves security stance on memory corruption bugs, i.e.
11 the attacker can’t just write to arbitrary memory and point the code to it,
12 the memory has to be marked with X bit, or else an exception will happen.
14 Memory sealing additionally protects the mapping itself against
15 modifications. This is useful to mitigate memory corruption issues where a
16 corrupted pointer is passed to a memory management system. For example,
17 such an attacker primitive can break control-flow integrity guarantees
18 since read-only memory that is supposed to be trusted can become writable
19 or .text pages can get remapped. Memory sealing can automatically be
23 A similar feature already exists in the XNU kernel with the
29 -----------------------
32 **addr**/**len**: virtual memory address range.
34 - The start address must be in an allocated VMA.
35 - The start address must be page aligned.
36 - The end address (**addr** + **len**) must be in an allocated VMA.
37 - no gap (unallocated memory) between start and end address.
44 - **0**: Success.
45 - **-EINVAL**:
49 - **-ENOMEM**:
52 * A gap (unallocated memory) between start and end address.
53 - **-EPERM**:
54 * sealing is supported only on 64-bit CPUs, 32-bit is not supported.
57 - For above error cases, users can expect the given memory range is
59 - There might be other internal errors/cases not listed here, e.g.
61 number of supported VMAs. In those cases, partial updates to the given
62 memory range could happen. However, those cases should be rare.
65 mseal only works on 64-bit CPUs, not 32-bit CPUs.
68 users can call mseal multiple times. mseal on an already sealed memory
69 is a no-action (not error).
77 -------------------------------------
79 stay in the process's memory until the process terminates**.
90 - munmap
91 - mmap
92 - mremap
93 - mprotect and pkey_mprotect
94 - some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE,
98 either leave an empty space in the address space, therefore allowing
107 risks when applied to anonymous memory by threads lacking write
111 operation on the anonymous memory.
113 Kernel will return -EPERM for blocked syscalls.
115 When blocked syscall return -EPERM due to sealing, the memory regions may
118 - munmap: munmap is atomic. If one of VMAs in the given range is
120 - mprotect, pkey_mprotect, madvise: partial update might happen, e.g.
122 VMAs before reaching the sealed VMA and return -EPERM.
123 - mmap and mremap: undefined behavior.
127 - glibc:
131 - Chrome browser: protect some security sensitive data structures.
135 Applications can apply sealing to any virtual memory region from userspace,
141 - aio/shm
143 ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied to
145 then munmap will fail, causing leaks in VMA address space during the
148 - ptr allocated by malloc (heap)
149 Don't use mseal on the memory ptr return from malloc().
154 non-deterministic.
166 In a nutshell, mseal blocks certain mm syscall from modifying some of VMA's
168 memory is immutable.
170 As Jann Horn pointed out in [3], there are still a few ways to write
171 to RO memory, which is, in a way, by design. And those could be blocked
176 - Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).
177 - Write to read-only memory through ptrace (such as PTRACE_POKETEXT).
178 - userfaultfd.
180 The idea that inspired this patch comes from Stephen Röttger’s work in V8
181 CFI [4]. Chrome browser in ChromeOS will be the first user of this API.
185 - [1] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b9f69dbd3c8c3fd30a/…
186 - [2] https://man.openbsd.org/mimmutable.2
187 - [3] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426FkcgnfUGLvA@mail.gmail.c…
188 - [4] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXgeaRHo/edit#heading=…