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

[Florian Weimer]

* Adhemerval Zanella:

> Memory sealing is an opt-in security feature that requires the new GNU
> property GNU_PROPERTY_MEMORY_SEAL, defined in Linux ABI [3] and
> supported on binutils 2.44 [4]. A GNU property is preferable over a
> new dynamic section tag (like the one proposed for DT_GNU_FLAGS_1) so
> it can be applied to ET_EXEC (for instance on static binaries).
>
> 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.

As discussed, I think we need a feature by which the main program (and
perhaps any initially loaded shared object) can opt out of memory
sealing for the whole process.  Otherwise, we have to build an entire
separate glibc merely for building a dynamically linked CRIU.  At least
the Fedora build of CRIU uses GNUTLS, and statically linking that is
really not something we'd like to do with our current distribution build
system.

I would prefer if we rolled this feature out gradually, and apply
sealing only if all objects say they are compatible.  We don't have to
fail dlopen when loading an incompatible object, we can just continue
and expect the application to provide decent diagnostics for any
mprotect failures.

The sealing range area is separate from that, but I still think it would
be useful.

Thanks,
Florian