[PATCH v8 0/8] Add support for memory sealing

[Florian Weimer]

* Adhemerval Zanella Netto:

> On 03/02/25 15:03, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> The Linux 6.10 (8be7258aad44) added the mseal syscall that allows
>>> blocking some memory 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 avoid either remapping
>>> the memory segments or changing the memory protection segments layout
>>> by the dynamic loader (for instance, the RELRO hardening). The OpenBSD
>>> supports a similar hardening with the mimmutable syscall [2].
>> 
>> Have you checked that CRIU restore still works after these changes?  I
>> don't see how it can because the initial mappings can no longer be
>> unmapped.
>
> No, I will take a look but I am not if this applies since it is a opt-in
> feature.  The CRIU adds some extra semantic requirements that is hard
> to take in consideration, similar to the defunct prelink support.
>
> But from CRIU discussion about a sealing extension to kernel mappings
> (such as vDSO) I got the impression that memory sealing is not a problem
> for userland (I guess that restoring just either ignore sealing or
> apply itself).

CRIU needs to be able to unmap everything that was initially loaded by
the kernel and glibc.  This will stop working if we use mseal for glibc
itself.

> A dynamic tag would add support only for ET_DYN, where a GNU attribute
> allows for ET_EXEC as well (similar to recent hardening mechanism like
> BTI, GCS, etc.).

We don't need the compatibility indicator on static executables because
incompatible static binaries won't have the PT_* header that requests
sealing.

> An the range approach is an extra complexity that I don't really see
> much gain, since the idea of PT_LOAD are to being *immutable* over process
> execution and not selective applied (different than PT_GNU_RELRO where
> only part of memory range should be RO).
>
> A range-based approach will still allow a misconfigured binary to be 
> partially sealed, which defeats the whole idea of the hardening (similar
> to partial relro).

But partial sealing could be a feature, too.  For example, in libgcc_s,
we might want to keep the root of the dynamic unwinding data structure
in read-only memory most of the time, as a post-exploitation
countermeasure that makes it harder to run arbitrary DWARF programs.

Thanks,
Florian