The new Linux mseal syscall allows mark a memory mapping to avoid
further changes (such as changng the protection flags). The memory
sealing is done in multiple places where the memory is supposed to
be immutable during program execution:
* All shared library dependencies from the binary, including the
read-only segments after PT_GNU_RELRO setup.
* The binary itself, including dynamic and static linked ones. In
both cases, it is up either to binary or the loader to set up the
sealing.
* Any preload libraries, including depedencies.
* Any library loaded with dlopen with RTLD_NODELETE flag.
* Audit modules.
* The loader bump allocator.
The memory sealing is controled by a new gnu attribute,
GNU_PROPERTY_MEMORY_SEAL, added by the new static linker option
'-z memory-seal'. It is set per binary, including statically linked
and shared objects.
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.
Checked on x86_64-linux-gnu and aarch64-linux-gnu.
804c23c942