| From: Jeff Xu <jeffxu@chromium.org> |
| Subject: mseal sysmap: update mseal.rst |
| Date: Wed, 5 Mar 2025 02:17:10 +0000 |
| |
| 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> |
| --- |
| |
| Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++ |
| 1 file changed, 20 insertions(+) |
| |
| --- a/Documentation/userspace-api/mseal.rst~mseal-sysmap-update-msealrst |
| +++ a/Documentation/userspace-api/mseal.rst |
| @@ -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, |
| _ |
