mirror of
https://github.com/torvalds/linux.git
synced 2025-04-06 00:16:18 +00:00
mseal sysmap: update mseal.rst
Update memory sealing documentation to include details about system mappings. Link: https://lkml.kernel.org/r/20250305021711.3867874-7-jeffxu@google.com Signed-off-by: Jeff Xu <jeffxu@chromium.org> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org> Cc: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Andrei Vagin <avagin@gmail.com> Cc: Anna-Maria Behnsen <anna-maria@linutronix.de> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Benjamin Berg <benjamin@sipsolutions.net> Cc: Christoph Hellwig <hch@lst.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Rientjes <rientjes@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Elliot Hughes <enh@google.com> Cc: Florian Faineli <f.fainelli@gmail.com> Cc: Greg Ungerer <gerg@kernel.org> Cc: Guenter Roeck <groeck@chromium.org> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Helge Deller <deller@gmx.de> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Jason A. Donenfeld <jason@zx2c4.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Jorge Lucangeli Obes <jorgelo@chromium.org> Cc: Linus Waleij <linus.walleij@linaro.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcow (Oracle) <willy@infradead.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michal Hocko <mhocko@suse.com> Cc: Miguel Ojeda <ojeda@kernel.org> Cc: Mike Rapoport <mike.rapoport@gmail.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Pedro Falcato <pedro.falcato@gmail.com> Cc: Peter Xu <peterx@redhat.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Stephen Röttger <sroettger@google.com> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This commit is contained in:
parent
3d38922abf
commit
a8c15bb400
@ -130,6 +130,26 @@ Use cases
|
||||
|
||||
- Chrome browser: protect some security sensitive data structures.
|
||||
|
||||
- System mappings:
|
||||
The system mappings are created by the kernel and includes vdso, vvar,
|
||||
vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-mode), uprobes.
|
||||
|
||||
Those system mappings are readonly only or execute only, memory sealing can
|
||||
protect them from ever changing to writable or unmmap/remapped as different
|
||||
attributes. This is useful to mitigate memory corruption issues where a
|
||||
corrupted pointer is passed to a memory management system.
|
||||
|
||||
If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),
|
||||
the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of this
|
||||
architecture.
|
||||
|
||||
The following architectures currently support this feature: x86-64 and arm64.
|
||||
|
||||
WARNING: This feature breaks programs which rely on relocating
|
||||
or unmapping system mappings. Known broken software at the time
|
||||
of writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Therefore
|
||||
this config can't be enabled universally.
|
||||
|
||||
When not to use mseal
|
||||
=====================
|
||||
Applications can apply sealing to any virtual memory region from userspace,
|
||||
|
Loading…
x
Reference in New Issue
Block a user