um: Do not flush MM in flush_thread

There should be no need to flush the memory in flush_thread. Doing this
likely worked around some issue where memory was still incorrectly
mapped when creating or cloning an MM.

With the removal of the special clone path, that isn't relevant anymore.
However, add the flush into MM initialization so that any new userspace
MM is guaranteed to be clean.

Signed-off-by: Benjamin Berg <benjamin.berg@intel.com>
Link: https://patch.msgid.link/20240703134536.1161108-10-benjamin@sipsolutions.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

diff --git a/arch/um/kernel/exec.c b/arch/um/kernel/exec.c
index 5c8836b012e932e4d2d41560626cb1a862dfb930..2c15bb2c104c16ead8f500cddc0e6d7c7040a4af 100644 (file)
--- a/arch/um/kernel/exec.c
+++ b/arch/um/kernel/exec.c
@@ -24,11 +24,6 @@ void flush_thread(void)
 {
        arch_flush_thread(&current->thread.arch);
 
-       unmap(&current->mm->context.id, 0, TASK_SIZE);
-       if (syscall_stub_flush(&current->mm->context.id) < 0) {
-               printk(KERN_ERR "%s - clearing address space failed", __func__);
-               force_sig(SIGKILL);
-       }
        get_safe_registers(current_pt_regs()->regs.gp,
                           current_pt_regs()->regs.fp);
 

diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index 697dad49c36bc4d101c8d66e71d4d546ceceb761..47f98d87ea3cfb96e47a8679a8c5ff4f7004630b 100644 (file)
--- a/arch/um/kernel/skas/mmu.c
+++ b/arch/um/kernel/skas/mmu.c
@@ -40,6 +40,30 @@ int init_new_context(struct task_struct *task, struct mm_struct *mm)
                goto out_free;
        }
 
+       /*
+        * Ensure the new MM is clean and nothing unwanted is mapped.
+        *
+        * TODO: We should clear the memory up to STUB_START to ensure there is
+        * nothing mapped there, i.e. we (currently) have:
+        *
+        * |- user memory -|- unused        -|- stub        -|- unused    -|
+        *                 ^ TASK_SIZE      ^ STUB_START
+        *
+        * Meaning we have two unused areas where we may still have valid
+        * mappings from our internal clone(). That isn't really a problem as
+        * userspace is not going to access them, but it is definitely not
+        * correct.
+        *
+        * However, we are "lucky" and if rseq is configured, then on 32 bit
+        * it will fall into the first empty range while on 64 bit it is going
+        * to use an anonymous mapping in the second range. As such, things
+        * continue to work for now as long as we don't start unmapping these
+        * areas.
+        *
+        * Change this to STUB_START once we have a clean userspace.
+        */
+       unmap(new_id, 0, TASK_SIZE);
+
        return 0;
 
  out_free: