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

[Aleksandr Mikhalitsyn]

On Thu, Feb 6, 2025 at 3:25 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> 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?

Dear friends,

I've quickly read a patchset [PATCH v8 0/8] Add support for memory
sealing (https://sourceware.org/pipermail/libc-alpha/2025-January/164361.html)
and noticed that on
https://sourceware.org/pipermail/libc-alpha/2025-January/164368.html
it's said:
>The GNU_PROPERTY_MEMORY_SEAL enforcement depends on whether the kernel
>supports the mseal syscall and how glibc is configured.  On the default
>configuration that aims to support older kernel releases, the memory
>sealing attribute is taken as a hint. If glibc is configured with a
>minimum kernel of 6.10, where mseal is implied to be supported,
>sealing is enforced.

=> if I understand it right, it makes memory sealing to be enabled by
default if the kernel supports it even without a linker flag, right?

I don't really understand what "glibc is configured with a minimum
kernel of 6.10" means from the user perspective.
I'm not very familiar with glibc internals, so can somebody put some
light on this, please?

I can't see how this can break the CRIU dump for us (I believe it
shouldn't but still worth checking), but for CRIU restore it's
definitely a problem
and reminds me of the rseq()&CRIU story we had a few years ago. My
current understanding is:

*during CRIU restore*
0. somehow disable mseal for CRIU binary itself, to make sure that
when CRIU do clone() we don't get any mappings sealed
1. restore all memory mappings of the restorable process without
mseal() applied to them
2. at the later criu restore stage go over them and apply mseal()

I have a bad feeling that I still miss something, but even step 0 is a
problem right now if we go with the current approach from this
patch series, isn't it?

Kind regards,
Alex