aboutsummaryrefslogtreecommitdiff
path: root/malloc/alloc_buffer_alloc_array.c
diff options
context:
space:
mode:
authorAdhemerval Zanella <adhemerval.zanella@linaro.org>2024-12-06 14:37:54 -0300
committerAdhemerval Zanella <adhemerval.zanella@linaro.org>2025-03-07 08:46:48 -0300
commit804c23c942c36f1ac657ef33f80469d466d849bd (patch)
treed1487150e3901a53be3c52990853ead597fd60a5 /malloc/alloc_buffer_alloc_array.c
parent71357a4b68c89f6fcc29a4dc113951d00d833572 (diff)
downloadglibc-804c23c942c36f1ac657ef33f80469d466d849bd.tar.xz
glibc-804c23c942c36f1ac657ef33f80469d466d849bd.zip
elf: Add support to memory sealing
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.
Diffstat (limited to 'malloc/alloc_buffer_alloc_array.c')
0 files changed, 0 insertions, 0 deletions