From: Cong Wang <xiyou.wangcong@gmail.com>
To: Richard Weinberger <richard@nod.at>,
Anton Ivanov <anton.ivanov@cambridgegreys.com>,
Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Berg <benjamin@sipsolutions.net>,
linux-um@lists.infradead.org, linux-kernel@vger.kernel.org,
Cong Wang <xiyou.wangcong@gmail.com>
Subject: [RFC PATCH 0/6] um: introduce pidfd_mmap()/pidfd_munmap() syscalls
Date: Fri, 10 Jul 2026 13:53:18 -0700 [thread overview]
Message-ID: <20260710205324.1343217-1-xiyou.wangcong@gmail.com> (raw)
This RFC adds two syscalls, pidfd_mmap() and pidfd_munmap(), that let a
supervisor install or remove a mapping in another process's address space
without target-side cooperation, and converts User Mode Linux to use them.
pidfd_mmap(int pidfd, struct pidfd_mmap_args *uargs, unsigned int flags)
pidfd_munmap(int pidfd, unsigned long addr, unsigned long len)
The backing fd (if any) is resolved in the *caller's* fd table, mirroring
pidfd_getfd()'s cross-task install model. Both are gated by
ptrace_may_access(PTRACE_MODE_ATTACH_REALCREDS); LSM/fsnotify hooks run
against the caller. pidfd_mmap() takes an extensible, size-versioned
argument struct (clone3/openat2 style) since an mmap-shaped call exceeds
the 6-argument syscall limit.
They build on the mm-side remote-install primitives vm_mmap_remote()/
vm_munmap_remote(), posted separately as:
https://lore.kernel.org/all/20260704231831.354543-2-xiyou.wangcong@gmail.com/
UML is the motivating user. Its SKAS monitor previously installed guest
mappings by driving the stub to execute mmap/munmap itself: in seccomp
mode it passed the physmem fd to the stub over SCM_RIGHTS, and in ptrace
mode it batched STUB_SYSCALL_MMAP/MUNMAP entries for the stub to run.
pidfd_mmap() lets the monitor install mappings into the stub's mm
directly, so the stub never touches the fd or executes mmap/munmap. With
both modes converted, the entire stub-syscall batcher and the SCM_RIGHTS
fd-passing become dead code and are removed (net ~530 lines). The ptrace
conversion (patch 5) is included mainly to demonstrate the primitive's
reach; the security caveats pidfd_mmap() does *not* address (e.g. a guest
blocking SIGALRM to dodge scheduling) are preserved in stub.c.
As this is an RFC, the UML side _intentionally_ does not handle host
portability: it assumes a host kernel that provides pidfd_mmap() and
deliberately omits any detection or fallback for older hosts (which would
otherwise pick the ptrace path, or fail the seccomp probe). That belongs
in a non-RFC version and is left out here to keep the series focused on
demonstrating the impact on UML.
---
Cong Wang (6):
pidfd: add pidfd_mmap()/pidfd_munmap() syscalls
um: acquire a stub pidfd via CLONE_PIDFD in seccomp mode
um: install guest mappings via pidfd_mmap() in seccomp mode
um: forbid mmap/munmap in the stub seccomp filter
um: install guest mappings via pidfd_mmap() in both modes
selftests/pidfd: add pidfd_mmap()/pidfd_munmap() tests
arch/um/include/shared/os.h | 4 -
arch/um/include/shared/skas/mm_id.h | 8 +-
arch/um/include/shared/skas/stub-data.h | 28 --
arch/um/kernel/skas/mmu.c | 9 +-
arch/um/kernel/skas/stub.c | 151 ++--------
arch/um/kernel/skas/stub_exe.c | 20 +-
arch/um/os-Linux/skas/mem.c | 275 ++----------------
arch/um/os-Linux/skas/process.c | 92 ++----
arch/um/os-Linux/start_up.c | 8 +-
arch/x86/entry/syscalls/syscall_64.tbl | 2 +
include/linux/syscalls.h | 5 +
include/uapi/linux/pidfd.h | 18 ++
kernel/pid.c | 132 +++++++++
scripts/syscall.tbl | 2 +
tools/testing/selftests/pidfd/Makefile | 3 +-
tools/testing/selftests/pidfd/pidfd.h | 34 +++
.../testing/selftests/pidfd/pidfd_mmap_test.c | 234 +++++++++++++++
17 files changed, 520 insertions(+), 505 deletions(-)
create mode 100644 tools/testing/selftests/pidfd/pidfd_mmap_test.c
base-commit: 69288464b0af40a988958c0e1b29ff15ccd2acb7
--
2.43.0
next reply other threads:[~2026-07-10 20:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 20:53 Cong Wang [this message]
2026-07-10 20:53 ` [RFC PATCH 1/6] pidfd: add pidfd_mmap()/pidfd_munmap() syscalls Cong Wang
2026-07-10 20:53 ` [RFC PATCH 2/6] um: acquire a stub pidfd via CLONE_PIDFD in seccomp mode Cong Wang
2026-07-10 20:53 ` [RFC PATCH 3/6] um: install guest mappings via pidfd_mmap() " Cong Wang
2026-07-10 20:53 ` [RFC PATCH 4/6] um: forbid mmap/munmap in the stub seccomp filter Cong Wang
2026-07-10 20:53 ` [RFC PATCH 5/6] um: install guest mappings via pidfd_mmap() in both modes Cong Wang
2026-07-10 20:53 ` [RFC PATCH 6/6] selftests/pidfd: add pidfd_mmap()/pidfd_munmap() tests Cong Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260710205324.1343217-1-xiyou.wangcong@gmail.com \
--to=xiyou.wangcong@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=benjamin@sipsolutions.net \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox