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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Thu Feb 6 14:25:29 GMT 2025



On 06/02/25 06:15, Andrei Vagin wrote:
> On Mon, Feb 03, 2025 at 11:11:56PM -0300, Cristian Rodríguez wrote:
>> On Mon, Feb 3, 2025 at 4:40 PM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * Adhemerval Zanella Netto:
>>>
>>>>> 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.
>>>>
>>>> So in this case the easiest way it to filter of mseal (with seccomp or
>>>> something related) and disable sealing.  I don't have a easy solution.
>>>
>>> Please test with CRIU and trace and find a way to make them work again
>>> if they are broken.
>>
>> that is a kernel problem afaik..
> 
> Could you please provide more details on why you think that is the
> kernel issue?
> 
> btw: this reminds me another discussion about mseal on lkml:
> https://lore.kernel.org/lkml/htdv44tqzi4jl2b7dwutsdwnh4tgrxq6xdvumi5wwu3hnh7sgw@tfwlal74ukx6/
> 
>> .why libc has to care about this limitation ?
> 
> CRIU has worked with glibc for many years... It's not just about CRIU;
> other projects, such as gVisor and UML, are also likely to be affected.

The current proposal is a opt-in feature, but also without a way to disable it
(similar to how RELRO is enableD).

I don't have much experience on how CRIU or gVisor works internally, but if
any requires to change any metadata (munmap, mprotect) of the PT_LOAD elf 
segments after startup this basically defeats the whole idea of the memory
sealing hardening.

I don't see a way to support both semantics without some extra kernel support,
where either you can mark some process with extra credentials to do the 
required VMA operations (like process_madvise, etc.) or disable sealing during 
the snapshot.

The mseal usage idea was primarily for program loaders, similar to how
mimmutable for OpenBSD; but it seems that some programs also intend to
use the syscall directly for some internal hardening (like Chrome). How
CRIU/gVisor would handle such scenarios?


More information about the Libc-alpha mailing list