um: skas: harden the seccomp userspace stub
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest7 patches 6 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/7 | um: skas: create a seccomp USER_NOTIF listener and hand it to the monitorarch/ arch/ arch/ | +45 | 0 replies | |
| 2/7 | um: skas: gate stub mmap() through the USER_NOTIF monitorarch/ arch/ | +89 | 0 replies | |
| 3/7 | um: skas: validate stub mmap() against the guest page tablearch/ arch/ arch/ | +50 | 0 replies | |
| 4/7 | um: skas: handle out-of-batch stub mmap notificationsarch/ | +19 | 0 replies | |
| 5/7 | um: skas: validate stub munmap() against the guest address rangearch/ arch/ arch/ +1 more | +35 | 0 replies | |
| 6/7 | um: skas: kill stubs that block SIGALRM via a watchdog threadarch/ | +129 | 0 replies | |
| 7/7 | um: skas: refresh stub security notes after closing the known issuesarch/ arch/ | +0 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/7] um: skas: harden the seccomp userspace stub
From: Cong Wang <[email protected]>
In the seccomp ("SECCOMP") userspace mode, each guest userspace process runs in a stub under a seccomp filter and traps to the monitor (the UML kernel) on every syscall. Two items on the stub.c "Known security issues" list could not be addressed by the filter alone:
- a hijacked stub could mmap() arbitrary physmem offsets, which is an intra-guest disclosure and, on this base (single physmem fd, no kernel/user split), a host escape; and
- a hijacked stub could block SIGALRM via a crafted rt_sigreturn to evade preemption and wedge the monitor indefinitely.
This series closes both:
1-2: route the stub's mmap() through a SECCOMP_RET_USER_NOTIF listener
owned by the monitor (no behavioural change yet).
3-4: validate each mmap() against the mm's page table -- allowed iff the
PTE already maps the requested frame with no more access than it grants -- including out-of-batch mmaps a hijacked stub issues on its own.
5: route and validate munmap() the same way (range-confined below
STUB_START).
6: add a watchdog thread that detects a stub which stops reporting
back (e.g. blocked SIGALRM) and SIGKILLs it, letting the monitor recover via the existing teardown.
7: drop the now-resolved "Known security issues" note and refresh the
seccomp= help text.
After the series a hijacked stub is confined to the frames its own page tables reference and can no longer reach arbitrary guest/host memory; one that evades preemption is detected out of band and killed rather than wedging the monitor.
Verified on UML (UP and 2-CPU SMP): boots and survives fork/exec storms and heavy mmap/munmap churn with zero false denials or false kills; an artificially SIGALRM-blocked busy loop is killed in ~5s and the monitor recovers, while syscall-making processes are untouched. Each patch builds and the series is bisectable.
---
Cong Wang (7):
um: skas: create a seccomp USER_NOTIF listener and hand it to the
monitor
um: skas: gate stub mmap() through the USER_NOTIF monitor
um: skas: validate stub mmap() against the guest page table
um: skas: handle out-of-batch stub mmap notifications
um: skas: validate stub munmap() against the guest address range
um: skas: kill stubs that block SIGALRM via a watchdog thread
um: skas: refresh stub security notes after closing the known issues
arch/um/include/shared/skas/mm_id.h | 1 + arch/um/include/shared/skas/skas.h | 5 + arch/um/kernel/skas/stub.c | 22 -- arch/um/kernel/skas/stub_exe.c | 19 +- arch/um/kernel/skas/uaccess.c | 48 +++++ arch/um/os-Linux/skas/process.c | 315 ++++++++++++++++++++++++---- arch/um/os-Linux/start_up.c | 6 - 7 files changed, 344 insertions(+), 72 deletions(-)
base-commit: 1a3746ccbb0a97bed3c06ccde6b880013b1dddc1
Signature · 1 line
2.43.0