linux-kernel - [PATCH 21/21] kgr: x86: optimize handling of CPU-bound tasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1403530175-29217-21-git-send-email-jslaby@suse.cz>
Date:	Mon, 23 Jun 2014 15:29:35 +0200
From:	Jiri Slaby <jslaby@...e.cz>
To:	linux-kernel@...r.kernel.org
Cc:	jirislaby@...il.com, Vojtech Pavlik <vojtech@...e.cz>,
	Jiri Kosina <jkosina@...e.cz>, Jiri Slaby <jslaby@...e.cz>
Subject: [PATCH 21/21] kgr: x86: optimize handling of CPU-bound tasks

From: Jiri Kosina <jkosina@...e.cz>

Processes which are running in userspace at the time of patching can
be immediately marked as "migrated" to the new universe, as they are
provably outside the kernel and would have their 'in_progress' flag
cleared upon (eventual) kernel entry anyway.

This eliminates the need to send a SIGSTOP/SIGCONT signal (or perform
any kind of alternative handling that would force the tasks to go
through the kernel) to such tasks. This allows the tasks to run
completely undisturbed by the patching.

We do this by looking at the task's stack trace. This is suboptimal
and perhaps ugly solution but we have not find any other easy way
without interrupting the task's computation. I.e. we are aware of IPIs
and looking at stored regs for example. If anyone can come up with an
idea how to dig out the process' state (whether running in user space
or not) from task_struct or such, please draw faster and shoot this
one dead.

js: remove unneeded headers
js: cleanup

Signed-off-by: Jiri Kosina <jkosina@...e.cz>
Signed-off-by: Jiri Slaby <jslaby@...e.cz>
---
 arch/x86/include/asm/kgraft.h | 30 ++++++++++++++++++++++++++++++
 kernel/kgraft.c               |  3 +++
 2 files changed, 33 insertions(+)

diff --git a/arch/x86/include/asm/kgraft.h b/arch/x86/include/asm/kgraft.h
index 6fc57a85d12c..3b13738f3665 100644
--- a/arch/x86/include/asm/kgraft.h
+++ b/arch/x86/include/asm/kgraft.h
@@ -22,10 +22,40 @@
 #endif
 
 #include <asm/ptrace.h>
+#include <linux/stacktrace.h>
 
 static inline void kgr_set_regs_ip(struct pt_regs *regs, unsigned long ip)
 {
 	regs->ip = ip;
 }
 
+#ifdef CONFIG_STACKTRACE
+/*
+ * Tasks which are running in userspace after the patching has been started
+ * can immediately be marked as migrated to the new universe.
+ *
+ * If this function returns non-zero (i.e. also when error happens), the task
+ * needs to be migrated using kgraft lazy mechanism.
+ */
+static inline bool kgr_needs_lazy_migration(struct task_struct *p)
+{
+	unsigned long s[3];
+	struct stack_trace t = {
+		.nr_entries = 0,
+		.skip = 0,
+		.max_entries = 3,
+		.entries = s,
+	};
+
+	save_stack_trace_tsk(p, &t);
+
+	return t.nr_entries > 2;
+}
+#else
+static inline bool kgr_needs_lazy_migration(struct task_struct *p)
+{
+	return true;
+}
+#endif
+
 #endif
diff --git a/kernel/kgraft.c b/kernel/kgraft.c
index c4b1777604e1..f13a4c081bd4 100644
--- a/kernel/kgraft.c
+++ b/kernel/kgraft.c
@@ -150,6 +150,9 @@ static void kgr_handle_processes(void)
 			 */
 			wake_up_process(p);
 		}
+		/* mark tasks wandering in userspace as already migrated */
+		if (!kgr_needs_lazy_migration(p))
+			kgr_task_safe(p);
 	}
 	read_unlock(&tasklist_lock);
 }
-- 
2.0.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/