Re: vmsplice exploits, stack protector and Makefiles

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxx> wrote:

> > was removed from arch/x86/kernel/process_64.c:__switch_to? that's 
> > the only reason i can think of that would trigger this trace.
> 
> I hand-ported your fixes [the patch was whitespace damaged] so i'm 
> quite sure i got every bit of it - but find it below for reference. I 
> think the percpu changes in .25 might have interfered somewhere. Will 
> investigate.

ok, Arjan found the bug: it was that idle threads didnt have their 
canary set up right.

[ note that this is still not complete because the initial idle thread
  still has a zero canary. But it at least boots now. ]

	Ingo

------------------------->
Subject: x86: setup stack canary for the idle threads
From: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>

The idle threads for non-boot CPUs are a bit special in how they
are created; the result is that these don't have the stack canary
set up properly in their PDA. Easiest fix is to just always set
the PDA up correctly when entering the idle thread; this is a NOP
for the boot cpu.

Signed-off-by: Arjan van de Ven <arjan@xxxxxxxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
---
 arch/x86/kernel/process_64.c |    9 +++++++++
 1 file changed, 9 insertions(+)

Index: linux-x86.q/arch/x86/kernel/process_64.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/process_64.c
+++ linux-x86.q/arch/x86/kernel/process_64.c
@@ -166,6 +166,15 @@ static inline void play_dead(void)
 void cpu_idle(void)
 {
 	current_thread_info()->status |= TS_POLLING;
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+	/*
+	 * If we're the non-boot CPU, nothing set the PDA stack
+	 * canary up for us. This is as good a place as any for
+	 * doing that.
+	 */
+	write_pda(stack_canary, current->stack_canary);
+#endif
 	/* endless idle loop with no priority at all */
 	while (1) {
 		tick_nohz_stop_sched_tick();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/