Introduction of mseal

Author:

Jeff Xu <jeffxu@chromium.org>

Modern CPUs support memory permissions such as RW and NX bits. The memorypermission feature improves security stance on memory corruption bugs, i.e.the attacker can’t just write to arbitrary memory and point the code to it,the memory has to be marked with X bit, or else an exception will happen.

Memory sealing additionally protects the mapping itself againstmodifications. This is useful to mitigate memory corruption issues where acorrupted pointer is passed to a memory management system. For example,such an attacker primitive can break control-flow integrity guaranteessince read-only memory that is supposed to be trusted can become writableor .text pages can get remapped. Memory sealing can automatically beapplied by the runtime loader to seal .text and .rodata pages andapplications can additionally seal security critical data at runtime.

A similar feature already exists in the XNU kernel with theVM_FLAGS_PERMANENT flag [1] and on OpenBSD with the mimmutable syscall [2].

SYSCALL

mseal syscall signature

intmseal(void*addr,size_tlen,unsignedlongflags)

addr/len: virtual memory address range.
The address range set byaddr/len must meet:

  • The start address must be in an allocated VMA.

  • The start address must be page aligned.

  • The end address (addr +len) must be in an allocated VMA.

  • no gap (unallocated memory) between start and end address.

Thelen will be paged aligned implicitly by the kernel.

flags: reserved for future use.

Return values:

  • 0: Success.

  • -EINVAL:

    • Invalid inputflags.

    • The start address (addr) is not page aligned.

    • Address range (addr +len) overflow.

  • -ENOMEM:

    • The start address (addr) is not allocated.

    • The end address (addr +len) is not allocated.

    • A gap (unallocated memory) between start and end address.

  • -EPERM:

    • sealing is supported only on 64-bit CPUs, 32-bit is not supported.

Note about error return:

  • For above error cases, users can expect the given memory range isunmodified, i.e. no partial update.

  • There might be other internal errors/cases not listed here, e.g.error during merging/splitting VMAs, or the process reaching the maximumnumber of supported VMAs. In those cases, partial updates to the givenmemory range could happen. However, those cases should be rare.

Architecture support:

mseal only works on 64-bit CPUs, not 32-bit CPUs.

Idempotent:

users can call mseal multiple times. mseal on an already sealed memoryis a no-action (not error).

no munseal

Once mapping is sealed, it can’t be unsealed. The kernel should neverhave munseal, this is consistent with other sealing feature, e.g.F_SEAL_SEAL for file.

Blocked mm syscall for sealed mapping

It might be important to note:once the mapping is sealed, it willstay in the process’s memory until the process terminates.

Example:

*ptr = mmap(0, 4096, PROT_READ, MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);rc = mseal(ptr, 4096, 0);/* munmap will fail */rc = munmap(ptr, 4096);assert(rc < 0);
Blocked mm syscall:

  • munmap

  • mmap

  • mremap

  • mprotect and pkey_mprotect

  • some destructive madvise behaviors: MADV_DONTNEED, MADV_FREE,MADV_DONTNEED_LOCKED, MADV_FREE, MADV_DONTFORK, MADV_WIPEONFORK

The first set of syscalls to block is munmap, mremap, mmap. They caneither leave an empty space in the address space, therefore allowingreplacement with a new mapping with new set of attributes, or canoverwrite the existing mapping with another mapping.

mprotect and pkey_mprotect are blocked because they changes theprotection bits (RWX) of the mapping.

Certain destructive madvise behaviors, specifically MADV_DONTNEED,MADV_FREE, MADV_DONTNEED_LOCKED, and MADV_WIPEONFORK, can introducerisks when applied to anonymous memory by threads lacking writepermissions. Consequently, these operations are prohibited under suchconditions. The aforementioned behaviors have the potential to modifyregion contents by discarding pages, effectively performing a memset(0)operation on the anonymous memory.

Kernel will return -EPERM for blocked syscalls.

When blocked syscall return -EPERM due to sealing, the memory regions mayor may not be changed, depends on the syscall being blocked:

  • munmap: munmap is atomic. If one of VMAs in the given range issealed, none of VMAs are updated.

  • mprotect, pkey_mprotect, madvise: partial update might happen, e.g.when mprotect over multiple VMAs, mprotect might update the beginningVMAs before reaching the sealed VMA and return -EPERM.

  • mmap and mremap: undefined behavior.

Use cases

  • glibc:The dynamic linker, during loading ELF executables, can apply sealing tomapping segments.

  • Chrome browser: protect some security sensitive data structures.

  • System mappings:The system mappings are created by the kernel and includes vdso, vvar,vvar_vclock, vectors (arm compat-mode), sigpage (arm compat-mode), uprobes.

    Those system mappings are readonly only or execute only, memory sealing canprotect them from ever changing to writable or unmmap/remapped as differentattributes. This is useful to mitigate memory corruption issues where acorrupted pointer is passed to a memory management system.

    If supported by an architecture (CONFIG_ARCH_SUPPORTS_MSEAL_SYSTEM_MAPPINGS),the CONFIG_MSEAL_SYSTEM_MAPPINGS seals all system mappings of thisarchitecture.

    The following architectures currently support this feature: x86-64, arm64,loongarch and s390.

    WARNING: This feature breaks programs which rely on relocatingor unmapping system mappings. Known broken software at the timeof writing includes CHECKPOINT_RESTORE, UML, gVisor, rr. Thereforethis config can’t be enabled universally.

When not to use mseal

Applications can apply sealing to any virtual memory region from userspace,but it iscrucial to thoroughly analyze the mapping’s lifetime prior toapply the sealing. This is because the sealed mappingwon’t be unmappeduntil the process terminates or the exec system call is invoked.

For example:

  • aio/shmaio/shm can call mmap and munmap on behalf of userspace, e.g.ksys_shmdt() in shm.c. The lifetimes of those mapping are not tied tothe lifetime of the process. If those memories are sealed from userspace,then munmap will fail, causing leaks in VMA address space during thelifetime of the process.

  • ptr allocated by malloc (heap)Don’t use mseal on the memory ptr return frommalloc().malloc() is implemented by allocator, e.g. by glibc. Heap manager mightallocate a ptr from brk or mapping created by mmap.If an app calls mseal on a ptr returned frommalloc(), this can affectthe heap manager’s ability to manage the mappings; the outcome isnon-deterministic.

    Example:

    ptr = malloc(size);/* don't call mseal on ptr return from malloc. */mseal(ptr, size);/* free will success, allocator can't shrink heap lower than ptr */free(ptr);

mseal doesn’t block

In a nutshell, mseal blocks certain mm syscall from modifying some of VMA’sattributes, such as protection bits (RWX). Sealed mappings doesn’t mean thememory is immutable.

As Jann Horn pointed out in [3], there are still a few ways to writeto RO memory, which is, in a way, by design. And those could be blockedby different security measures.

Those cases are:

  • Write to read-only memory through /proc/self/mem interface (FOLL_FORCE).

  • Write to read-only memory through ptrace (such as PTRACE_POKETEXT).

  • userfaultfd.

The idea that inspired this patch comes from Stephen Röttger’s work in V8CFI [4]. Chrome browser in ChromeOS will be the first user of this API.

Reference