| Message ID | 20250303050921.3033083-7-jeffxu@google.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | mseal system mappings | expand |
On Mon, Mar 03, 2025 at 05:09:20AM +0000, jeffxu@chromium.org wrote: > From: Jeff Xu <jeffxu@chromium.org> > > Update memory sealing documentation to include details about system > mappings. > > Signed-off-by: Jeff Xu <jeffxu@chromium.org> > Reviewed-by: Kees Cook <kees@kernel.org> LGTM so: Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> > --- > Documentation/userspace-api/mseal.rst | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst > index 41102f74c5e2..76e10938302a 100644 > --- a/Documentation/userspace-api/mseal.rst > +++ b/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 compact-mode), sigpage (arm compact-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. Perfect, thanks! > + > When not to use mseal > ===================== > Applications can apply sealing to any virtual memory region from userspace, > -- > 2.48.1.711.g2feabab25a-goog >
diff --git a/Documentation/userspace-api/mseal.rst b/Documentation/userspace-api/mseal.rst index 41102f74c5e2..76e10938302a 100644 --- a/Documentation/userspace-api/mseal.rst +++ b/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 compact-mode), sigpage (arm compact-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,