kernel/arch/um/os-Linux/skas, branch linux-rolling-stable

um: Add initial SMP support

2025-10-27T15:41:15Z

Add initial symmetric multi-processing (SMP) support to UML. With this support enabled, users can tell UML to start multiple virtual processors, each represented as a separate host thread. In UML, kthreads and normal threads (when running in kernel mode) can be scheduled and executed simultaneously on different virtual processors. However, the userspace code of normal threads still runs within their respective single-threaded stubs. That is, SMP support is currently available both within the kernel and across different processes, but still remains limited within threads of the same process in userspace. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20251027001815.1666872-6-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: Remove file-based iomem emulation support

2025-10-27T15:37:12Z

The file-based iomem emulation was introduced to support writing paravirtualized drivers based on emulated iomem regions. However, the only driver that makes use of it is an example driver called mmapper, which was written over two decades ago. We now have several modern device emulation mechanisms, such as vhost-user-based virtio-uml. Remove the file-based iomem emulation support to reduce the maintenance burden. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20251027054519.1996090-5-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: Add missing trailing newline to help messages

2025-09-10T12:23:37Z

Some help messages are missing a trailing newline. They should end with two newlines, but only one is present. Add the missing newline to make the --help output more readable. Signed-off-by: Tiwei Bie Signed-off-by: Johannes Berg

um: Stop tracking stub's PID via userspace_pid[]

2025-07-13T17:42:49Z

The PID of the stub process can be obtained from current_mm_id(). There is no need to track it via userspace_pid[]. Stop doing that to simplify the code. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250711065021.2535362-4-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: Remove the pid parameter of handle_trap()

2025-07-13T17:42:49Z

It's no longer used. Remove it. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250711065021.2535362-3-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: Use err consistently in userspace()

2025-07-13T17:42:49Z

Avoid declaring a new variable 'ret' inside the 'if (using_seccomp)' block, as the existing 'err' variable declared at the top of the function already serves the same purpose. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250711065021.2535362-2-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: Make unscheduled_userspace_iterations static

2025-07-11T06:49:17Z

It's only used within process.c. Make it static. Signed-off-by: Tiwei Bie Link: https://patch.msgid.link/20250708090403.1067440-2-tiwei.bie@linux.dev Signed-off-by: Johannes Berg

um: pass FD for memory operations when needed

2025-06-02T14:20:10Z

Instead of always sharing the FDs with the userspace process, only hand over the FDs needed for mmap when required. The idea is that userspace might be able to force the stub into executing an mmap syscall, however, it will not be able to manipulate the control flow sufficiently to have access to an FD that would allow mapping arbitrary memory. Security wise, we need to be sure that only the expected syscalls are executed after the kernel sends FDs through the socket. This is currently not the case, as userspace can trivially jump to the rt_sigreturn syscall instruction to execute any syscall that the stub is permitted to do. With this, it can trick the kernel to send the FD, which in turn allows userspace to freely map any physical memory. As such, this is currently *not* secure. However, in principle the approach should be fine with a more strict SECCOMP filter and a careful review of the stub control flow (as userspace can prepare a stack). With some care, it is likely possible to extend the security model to SMP if desired. Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250602130052.545733-8-benjamin@sipsolutions.net Signed-off-by: Johannes Berg

um: Implement kernel side of SECCOMP based process handling

2025-06-02T13:17:19Z

This adds the kernel side of the seccomp based process handling. Co-authored-by: Johannes Berg Signed-off-by: Benjamin Berg Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250602130052.545733-6-benjamin@sipsolutions.net Signed-off-by: Johannes Berg

um: Track userspace children dying in SECCOMP mode

2025-06-02T13:17:19Z

When in seccomp mode, we would hang forever on the futex if a child has died unexpectedly. In contrast, ptrace mode will notice it and kill the corresponding thread when it fails to run it. Fix this issue using a new IRQ that is fired after a SIGCHLD and keeping an (internal) list of all MMs. In the IRQ handler, find the affected MM and set its PID to -1 as well as the futex variable to FUTEX_IN_KERN. This, together with futex returning -EINTR after the signal is sufficient to implement a race-free detection of a child dying. Note that this also enables IRQ handling while starting a userspace process. This should be safe and SECCOMP requires the IRQ in case the process does not come up properly. Signed-off-by: Benjamin Berg Signed-off-by: Benjamin Berg Link: https://patch.msgid.link/20250602130052.545733-5-benjamin@sipsolutions.net Signed-off-by: Johannes Berg