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 <cwang@multikernel.io>
Subject: [RFC PATCH 2/6] um: acquire a stub pidfd via CLONE_PIDFD in seccomp mode
Date: Fri, 10 Jul 2026 13:53:20 -0700 [thread overview]
Message-ID: <20260710205324.1343217-3-xiyou.wangcong@gmail.com> (raw)
In-Reply-To: <20260710205324.1343217-1-xiyou.wangcong@gmail.com>
From: Cong Wang <cwang@multikernel.io>
In SECCOMP mode the monitor will install guest mappings into the stub's
address space directly via pidfd_mmap(), so it needs a pidfd to the
stub. Acquire one atomically at clone() time via CLONE_PIDFD (returned
through the legacy-clone parent_tid argument), store it in
mm_id->stub_pidfd, and close it on teardown. The ptrace (SKAS0) mode
does not use pidfd_mmap and leaves stub_pidfd as -1.
Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Cong Wang <cwang@multikernel.io>
---
arch/um/include/shared/skas/mm_id.h | 1 +
arch/um/kernel/skas/mmu.c | 6 ++++++
arch/um/os-Linux/skas/process.c | 24 ++++++++++++++++++++++--
3 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/arch/um/include/shared/skas/mm_id.h b/arch/um/include/shared/skas/mm_id.h
index 18c0621430d2..cec97189f12b 100644
--- a/arch/um/include/shared/skas/mm_id.h
+++ b/arch/um/include/shared/skas/mm_id.h
@@ -16,6 +16,7 @@ struct mm_id {
int syscall_data_len;
/* Only used with SECCOMP mode */
+ int stub_pidfd; /* pidfd to the stub, or -1 */
int sock;
int syscall_fd_num;
int syscall_fd_map[STUB_MAX_FDS];
diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index b5017096028b..441dcf94ec9c 100644
--- a/arch/um/kernel/skas/mmu.c
+++ b/arch/um/kernel/skas/mmu.c
@@ -54,6 +54,7 @@ int init_new_context(struct task_struct *task, struct mm_struct *mm)
goto out;
new_id->stack = stack;
+ new_id->stub_pidfd = -1;
new_id->syscall_data_len = 0;
new_id->syscall_fd_num = 0;
@@ -103,6 +104,11 @@ void destroy_context(struct mm_struct *mm)
mmu->id.pid = -1;
}
+ if (mmu->id.stub_pidfd >= 0) {
+ os_close_file(mmu->id.stub_pidfd);
+ mmu->id.stub_pidfd = -1;
+ }
+
if (using_seccomp && mmu->id.sock)
os_close_file(mmu->id.sock);
diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index d6c22f8aa06d..3dd97ca7999a 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -34,6 +34,10 @@
#include <asm-generic/rwonce.h>
#include "../internal.h"
+#ifndef CLONE_PIDFD
+#define CLONE_PIDFD 0x00001000
+#endif
+
int is_skas_winch(int pid, int fd, void *data)
{
return pid == getpgrp();
@@ -448,6 +452,9 @@ int start_userspace(struct mm_id *mm_id)
void *stack;
unsigned long sp;
int status, n, err;
+ int stub_pidfd = -1;
+
+ mm_id->stub_pidfd = -1;
/* setup a temporary stack page */
stack = mmap(NULL, UM_KERN_PAGE_SIZE,
@@ -474,15 +481,25 @@ int start_userspace(struct mm_id *mm_id)
if (using_seccomp)
proc_data->futex = FUTEX_IN_CHILD;
+ /*
+ * In SECCOMP mode, acquire a pidfd to the stub via CLONE_PIDFD (it is
+ * returned through the legacy-clone parent_tid argument). The monitor
+ * installs guest mappings into the stub's mm directly via pidfd_mmap(),
+ * so the stub itself never needs the mmap capability. The ptrace mode
+ * does not use it and drives the stub directly.
+ */
mm_id->pid = clone(userspace_tramp, (void *) sp,
- CLONE_VFORK | CLONE_VM | SIGCHLD,
- (void *)&tramp_data);
+ CLONE_VFORK | CLONE_VM | (using_seccomp ? CLONE_PIDFD : 0) |
+ SIGCHLD,
+ (void *)&tramp_data, &stub_pidfd);
if (mm_id->pid < 0) {
err = -errno;
printk(UM_KERN_ERR "%s : clone failed, errno = %d\n",
__func__, errno);
goto out_close;
}
+ if (using_seccomp)
+ mm_id->stub_pidfd = stub_pidfd;
if (using_seccomp) {
wait_stub_done_seccomp(mm_id, 1, 1);
@@ -534,8 +551,11 @@ int start_userspace(struct mm_id *mm_id)
out_close:
close(tramp_data.sockpair[0]);
close(tramp_data.sockpair[1]);
+ if (stub_pidfd >= 0)
+ close(stub_pidfd);
mm_id->pid = -1;
+ mm_id->stub_pidfd = -1;
return err;
}
--
2.43.0
next prev parent 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 [RFC PATCH 0/6] um: introduce pidfd_mmap()/pidfd_munmap() syscalls Cong Wang
2026-07-10 20:53 ` [RFC PATCH 1/6] pidfd: add " Cong Wang
2026-07-10 20:53 ` Cong Wang [this message]
2026-07-10 20:53 ` [RFC PATCH 3/6] um: install guest mappings via pidfd_mmap() in seccomp mode 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-3-xiyou.wangcong@gmail.com \
--to=xiyou.wangcong@gmail.com \
--cc=anton.ivanov@cambridgegreys.com \
--cc=benjamin@sipsolutions.net \
--cc=cwang@multikernel.io \
--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