[Bug 297427] linuxulator: implement pkey_alloc/pkey_free/pkey_mprotect (x86 memory protection keys)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297427

--- Comment #5 from [email protected] ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=bdb561843e865eaa5bbdc5394ed9d9c91136240c

commit bdb561843e865eaa5bbdc5394ed9d9c91136240c
Author:     Devin Teske <[email protected]>
AuthorDate: 2026-08-16 00:58:19 +0000
Commit:     Devin Teske <[email protected]>
CommitDate: 2026-08-16 00:58:43 +0000

    linux: implement pkey_alloc, pkey_free and pkey_mprotect

    Bridge the Linux memory protection key syscalls to FreeBSD's native
    MPK support instead of returning ENOSYS. Modern Linux software
    probes these at startup: Chromium-based browsers (found via
    www/linux-brave) use protection keys for V8's heap and JIT
    sandboxing, and glibc >= 2.27 exposes the full API.

    pkey_alloc() allocates from a per-process bitmap kept in the process
    emuldata (key 0 implicitly allocated, matching Linux's
    mm_pkey_allocation_map; ENOSPC once keys 1..15 are exhausted or when
    PKU is absent, as Linux returns on such hardware) and applies the
    requested initial access rights to the calling thread's PKRU, located
    in the XSAVE area via xsave_area_offset(). pkey_free() is
    bookkeeping only: as on Linux, freeing neither untags pages nor
    updates PKRU. pkey_mprotect() performs the protection change and
    tags the range through amd64_pkru_update(), factored out of
    sysarch(2)'s AMD64_SET_PKRU/AMD64_CLEAR_PKRU implementation so that
    both share the same argument checking and map read lock
    synchronization with a parallel pmap_vmspace_copy() on fork; tags die
    with the mapping, matching Linux VMA semantics. A pkey of -1
    degrades to plain mprotect.

    The allocation map is inherited on fork and reset on exec. At exec
    the Linux sysvecs initialize PKRU to 0x55555554, Linux's init_pkru
    default (access disabled for keys 1..15), so memory tagged with a
    not yet allocated key is inaccessible to threads that were never
    granted rights -- the property V8's thread isolation relies on.
    Setting PKRU at exec initializes the user FPU state slightly earlier
    than the lazy first-use path; the state would be initialized moments
    later in rtld/libc startup regardless. Protection key faults
    already deliver SEGV_PKUERR through the existing siginfo
    translation.

    The common code carries no architecture ifdefs. Machine-dependent
    state lives in struct linux_pemuldata_md, embedded in the process
    emuldata in the manner of struct mdthread, and common code calls
    per-arch lifecycle hooks (linux_pemuldata_init_md/_exec_md) and pkey
    back ends after performing the parameter validation Linux applies
    regardless of hardware support. On amd64 the implementation lives
    in sys/amd64/linux/linux_pkru.c, compiled into linux_common and
    serving both the 64-bit and 32-bit Linux ABIs. Elsewhere (arm64,
    i386) linux_emul_md.c provides stubs returning what Linux returns on
    hardware without protection keys (ENOSPC from pkey_alloc;
    pkey_mprotect with a pkey of -1 acts as plain mprotect), so
    applications take their normal no-PKU fallback instead of the ENOSYS
    path.

    PR:             297427
    MFC after:      1 month
    Reviewed by:    kib
    Differential Revision:  https://reviews.freebsd.org/D58782

 sys/amd64/amd64/sys_machdep.c         |  85 ++++++-------
 sys/amd64/linux/linux_emul_md.h (new) |  35 ++++++
 sys/amd64/linux/linux_pkru.c (new)    | 226 ++++++++++++++++++++++++++++++++++
 sys/amd64/linux/linux_sysvec.c        |   4 +
 sys/amd64/linux32/linux32_sysvec.c    |   4 +
 sys/arm64/linux/linux_emul_md.c (new) |  52 ++++++++
 sys/arm64/linux/linux_emul_md.h (new) |  18 +++
 sys/compat/linux/linux_dummy.c        |   3 -
 sys/compat/linux/linux_emul.c         |   2 +
 sys/compat/linux/linux_emul.h         |  12 ++
 sys/compat/linux/linux_misc.c         |  22 ++++
 sys/compat/linux/linux_mmap.c         |  38 ++++++
 sys/compat/linux/linux_mmap.h         |  21 ++++
 sys/i386/linux/linux_emul_md.c (new)  |  52 ++++++++
 sys/i386/linux/linux_emul_md.h (new)  |  18 +++
 sys/modules/linux/Makefile            |   1 +
 sys/modules/linux_common/Makefile     |  10 +-
 sys/x86/include/sysarch.h             |   1 +
 18 files changed, 554 insertions(+), 50 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.