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

[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).

> 
> I don't think the design is quite right.  The property flag (why not a
> flag in a dynamic tag? these things are very complicated) should allow
> flagging a program or initiallly loaded shared object, like CRIU or
> ltrace, as incompatible with mseal.  If mseal is active for the process,
> the mseal range should be controlled by a program header similar to
> PT_GNU_RELRO, and not indiscriminately applied to the entire object.

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.).

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).

> 
> I don't think we should apply this blindly to any NODELETE mapping.

It is not, it is controlled by the attribute presence. The NODELETE
just allow shared library with the sealing attribute to be sealed
with dlopen. 

> 
> Thanks,
> Florian
>