[PATCH v6 0/9] Add support for memory sealing

[Jeff Xu]

On Wed, Apr 2, 2025 at 10:40 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Adhemerval Zanella:
>
> > The Linux 6.10 (8be7258aad44) added the mseal syscall that allows
> > blocking some memory mapping operations on the VMA range:
> >
> >  * Unmapping, moving to another location, extending or shrinking the
> >    size, munmap, and mremap.
> >  * Moving or expanding a different VMA into the current range, via
> >    mremap.
> >  * Modifying the memory range with mmap along with flag MAP_FIXED.
> >  * Expanding the size with mremap.
> >  * Change the protection flags with mprotect or pkey_mprotect.
> >  * Destructive behaviors on anonymous memory, such as madvice with
> >    MADV_DONTNEED.
> >
> > Memory sealing is a hardening mechanism [1] to prevent memory mapping
> > changes to the ELF segment mappings done by the dynamic loader (for
> > instance, the RELRO hardening). The OpenBSD supports a similar hardening
> > with the mimmutable syscall [2].
>
> The Nvidia drivers appear to patch the glibc dynamic linker (in
> _dl_debug_update):
>
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2357062#c5>
>
> I don't know if they use an mprotect-patch-mprotect sequence for that,
> or some other mechanism that is compatible with mseal.  But it seems we
> can't apply mseal to glibc by default for backwards compatibility
> reasons.
>
Based on the discussion in [1], [2], and [3], it seems that the Nvidia
drivers issue is related to loading a 32-bit app and has either a
workaround or a fix. If this is indeed a bug, glibc memory sealing can
help prevent or detect such a bug earlier.

There are two solutions for such a case in the future:
1. Do not turn on sealing when building the main binary.
2. Use the .gnu.mutable solution to mark specific areas/variables to
be not sealable.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2357062#c11 [1]
Link: https://bugzilla.rpmfusion.org/show_bug.cgi?id=7180#c25 [2]
Link: https://gitlab.freedesktop.org/glvnd/libglvnd/-/issues/252#note_2918141
[3]

Thanks
-Jeff

> Thanks,
> Florian
>