[PATCH 7/7] um: skas: refresh stub security notes after closing the known issues

From: Cong Wang <[email protected]>

Drop the stale comment and update the seccomp= setup help text, which still
warned about these exact issues and labelled the mode "insecure".

Assisted-by: Claude:claude-opus-4.8
Signed-off-by: Cong Wang <[email protected]>
---
 arch/um/kernel/skas/stub.c  | 22 ----------------------
 arch/um/os-Linux/start_up.c |  6 ------
 2 files changed, 28 deletions(-)

diff --git a/arch/um/kernel/skas/stub.c b/arch/um/kernel/skas/stub.c
index e09216a20cb5..7845638d595d 100644
--- a/arch/um/kernel/skas/stub.c
+++ b/arch/um/kernel/skas/stub.c
@@ -9,28 +9,6 @@
 #include <sys/socket.h>
 #include <errno.h>
 
-/*
- * Known security issues
- *
- * Userspace can jump to this address to execute *any* syscall that is
- * permitted by the stub. As we will return afterwards, it can do
- * whatever it likes, including:
- * - Tricking the kernel into handing out the memory FD
- * - Using this memory FD to read/write all physical memory
- * - Running in parallel to the kernel processing a syscall
- *   (possibly creating data races?)
- * - Blocking e.g. SIGALRM to avoid time based scheduling
- *
- * To avoid this, the permitted location for each syscall needs to be
- * checked for in the SECCOMP filter (which is reasonably simple). Also,
- * more care will need to go into considerations how the code might be
- * tricked by using a prepared stack (or even modifying the stack from
- * another thread in case SMP support is added).
- *
- * As for the SIGALRM, the best counter measure will be to check in the
- * kernel that the process is reporting back the SIGALRM in a timely
- * fashion.
- */
 static __always_inline int syscall_handler(int fd_map[STUB_MAX_FDS])
 {
 	struct stub_data *d = get_stub_data();
diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 054ac03bbf5e..b01942bec953 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -452,12 +452,6 @@ __uml_setup("seccomp=", uml_seccomp_config,
 "    This method is overall faster than the ptrace based userspace, primarily\n"
 "    because it reduces the number of context switches for (minor) page faults.\n"
 "\n"
-"    However, the SECCOMP filter is not (yet) restrictive enough to prevent\n"
-"    userspace from reading and writing all physical memory. Userspace\n"
-"    processes could also trick the stub into disabling SIGALRM which\n"
-"    prevents it from being interrupted for scheduling purposes.\n"
-"\n"
-"    This is insecure and should only be used with a trusted userspace\n\n"
 );
 
 void __init os_early_checks(void)
-- 
2.43.0