Remove syscall instructions at fixed addresses

There's a fair amount of code in the vsyscall page, and who knows what will happen if an exploit jumps into the middle of it. Reduce the risk by replacing most of it with short magic incantations that are useless if entered in the middle. This change can be disabled by CONFIG_UNSAFE_VSYSCALLS (default y).

This causes vsyscalls to be a little more expensive than real syscalls. Fortunately sensible programs don't use them.

Some care is taken to make sure that tools like valgrind and ThreadSpotter still work.

This patch is not perfect: the vread_tsc and vread_hpet functions are still at a fixed address. Fixing that might involve making alternative patching work in the vDSO.

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/Kconfig                  |   17 +++++
 arch/x86/kernel/Makefile          |    3 +
 arch/x86/kernel/vsyscall_64.c     |  121 +++++++++++++++++++++++++++++++++++--
 arch/x86/kernel/vsyscall_emu_64.S |   40 ++++++++++++
 4 files changed, 176 insertions(+), 5 deletions(-)
 create mode 100644 arch/x86/kernel/vsyscall_emu_64.S

arch/x86/Kconfig +17 -0

index cc6c53a..186018b 100644
@@ -1650,6 +1650,23 @@ config COMPAT_VDSO
 
 	  If unsure, say Y.
 
+config UNSAFE_VSYSCALLS
+	def_bool y
+	prompt "Unsafe fast legacy vsyscalls"
+	depends on X86_64
+	---help---
+	  Legacy user code expects to be able to issue three syscalls
+	  by calling fixed addresses in kernel space.  If you say N,
+	  then the kernel traps and emulates these calls.  If you say
+	  Y, then there is actual executable code at a fixed address
+	  to implement these calls efficiently.
+
+	  On a system with recent enough glibc (probably 2.14 or
+	  newer) and no static binaries, you can say N without a
+	  performance penalty to improve security
+
+	  If unsure, say Y.
+
 config CMDLINE_BOOL
 	bool "Built-in kernel command line"
 	---help---

arch/x86/kernel/Makefile +3 -0

index a24521b..b901781 100644
@@ -42,6 +42,9 @@ obj-$(CONFIG_X86_32)	+= probe_roms_32.o
 obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)	+= syscall_64.o vsyscall_64.o vread_tsc_64.o
+ifndef CONFIG_UNSAFE_VSYSCALLS
+	obj-$(CONFIG_X86_64)	+= vsyscall_emu_64.o
+endif
 obj-y			+= bootflag.o e820.o
 obj-y			+= pci-dma.o quirks.o topology.o kdebugfs.o
 obj-y			+= alternative.o i8253.o pci-nommu.o hw_breakpoint.o

arch/x86/kernel/vsyscall_64.c +27 -5

index 71fa506..5b3d62a 100644
@@ -48,9 +48,6 @@
 #include <asm/vgtod.h>
 #include <asm/traps.h>
 
-#define __vsyscall(nr) \
-		__attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace
-
 DEFINE_VVAR(int, vgetcpu_mode);
 DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data) =
 {

@@ -96,6 +93,7 @@ static void warn_bad_vsyscall(struct pt_regs *regs, bool is_warning,
 		return;
 
 	tsk = current;
+
 	printk("%s%s[%d] %s ip:%lx sp:%lx ax:%lx si:%lx di:%lx",
 	       is_warning ? KERN_WARNING : KERN_INFO,
 	       tsk->comm, task_pid_nr(tsk),

@@ -106,6 +104,12 @@ static void warn_bad_vsyscall(struct pt_regs *regs, bool is_warning,
 	printk("\n");
 }
 
+#ifdef CONFIG_UNSAFE_VSYSCALLS
+
+#define __vsyscall(nr)							\
+	__attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace
+
+
 /* RED-PEN may want to readd seq locking, but then the variable should be
  * write-once.
  */

@@ -117,8 +121,11 @@ static __always_inline void do_get_tz(struct timezone * tz)
 static __always_inline int fallback_gettimeofday(struct timeval *tv)
 {
 	int ret;
-	/* Invoke do_emulate_vsyscall. */
-	asm volatile("movb $0xce, %%al;\n\t"
+	/*
+	 * Invoke do_emulate_vsyscall.  Intentionally incompatible with
+	 * the CONFIG_UNSAFE_VSYSCALLS=n case.
+	 */
+	asm volatile("mov $0xce, %%al;\n\t"
 		     "int %[vec]"
 		     : "=a" (ret)
 		     : "D" (tv), [vec] "i" (VSYSCALL_EMU_VECTOR));

@@ -237,6 +244,8 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
 	long ret;
 
 	/* Kernel code must never get here. */
+	if (!user_mode(regs))
+		early_printk("oh crap!\n");
 	BUG_ON(!user_mode(regs));
 
 	local_irq_enable();

@@ -278,6 +287,106 @@ out:
 	local_irq_disable();
 }
 
+#else /* CONFIG_UNSAFE_VSYSCALLS=n below */
+
+static inline unsigned long vsyscall_intcc_addr(int vsyscall_nr)
+{
+	return VSYSCALL_START + 1024*vsyscall_nr + 2;
+}
+
+void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
+{
+	u8 vsyscall_nr, al;
+	long ret;
+
+	/* Kernel code must never get here. */

arch/x86/kernel/vsyscall_64.c +79 -0

+	if (vsyscall_nr > 2 || al != (vsyscall_nr << 1) + 0xcc) {
+		warn_bad_vsyscall(regs, false, "illegal int 0xcc "
+				  "(exploit attempt?)");
+		force_sig(SIGSEGV, current);
+		goto out;
+	}
+
+	if (regs->ip - 2 != vsyscall_intcc_addr(vsyscall_nr)) {
+		if (in_vsyscall_page(regs->ip - 2)) {
+			/* This should not be possible. */
+			warn_bad_vsyscall(regs, true, "int 0xcc severe badness"
+					  " (exploit attempt?)");
+			force_sig(SIGSEGV, current);
+			goto out;
+		} else {
+			/*
+			 * We allow the call because tools like ThreadSpotter
+			 * might copy the int 0xcc instruction to user memory.
+			 * We make it annoying, though, to try to persuade
+			 * the authors to stop doing that...
+			 */
+			warn_bad_vsyscall(regs, true, "int 0xcc in user code "
+					  "(exploit attempt? legacy "
+					  "instrumented code?)");
+		}
+	}
+
+	if (current->seccomp.mode) {
+		do_exit(SIGKILL);
+		goto out;
+	}
+
+	switch(vsyscall_nr)
+	{
+	case 0:
+		ret = sys_gettimeofday(
+			(struct timeval __user *)regs->di,
+			(struct timezone __user *)regs->si);
+		break;
+
+	case 1:
+		ret = sys_time((time_t __user *)regs->di);
+		break;
+
+	case 2:
+		ret = sys_getcpu((unsigned __user *)regs->di,
+				 (unsigned __user *)regs->si,
+				 0);
+		break;
+
+	default:
+		unreachable();
+	}
+
+	if (ret == -EFAULT) {
+		/*
+		 * Bad news -- userspace fed a bad pointer to a vsyscall.
+		 *
+		 * With a real vsyscall, that would have caused SIGSEGV.
+		 * To make writing reliable exploits using the emulated
+		 * vsyscalls harder, generate SIGSEGV here as well.
+		 */
+		warn_bad_vsyscall(regs, false,
+				  "vsyscall fault (exploit attempt?)");
+		force_sig(SIGSEGV, current);
+		goto out;
+	}
+
+	regs->ax = ret;
+
+out:
+	local_irq_disable();
+	return;
+}
+
+#endif /* CONFIG_UNSAFE_VSYSCALLS */
+
 /* Assume __initcall executes before all user space. Hopefully kmod
    doesn't violate that. We'll find out if it does. */
 static void __cpuinit vsyscall_set_cpu(int cpu)

@@ -331,11 +440,13 @@ void __init map_vsyscall(void)
 
 static int __init vsyscall_init(void)
 {
+#ifdef CONFIG_UNSAFE_VSYSCALLS
 	BUG_ON(((unsigned long) &vgettimeofday !=
 			VSYSCALL_ADDR(__NR_vgettimeofday)));
 	BUG_ON((unsigned long) &vtime != VSYSCALL_ADDR(__NR_vtime));
 	BUG_ON((VSYSCALL_ADDR(0) != __fix_to_virt(VSYSCALL_FIRST_PAGE)));
 	BUG_ON((unsigned long) &vgetcpu != VSYSCALL_ADDR(__NR_vgetcpu));
+#endif
 	on_each_cpu(cpu_vsyscall_init, NULL, 1);
 	/* notifier priority > KVM */
 	hotcpu_notifier(cpu_vsyscall_notifier, 30);

arch/x86/kernel/vsyscall_emu_64.S new file +40 -0

new file mode 100644
index 0000000..3e1cad2
@@ -0,0 +1,40 @@
+/*
+ * vsyscall_emu_64.S: Vsyscall emulation page
+ * Copyright (c) 2011 Andy Lutomirski
+ * Subject to the GNU General Public License, version 2
+*/
+
+#include <linux/linkage.h>
+#include <asm/irq_vectors.h>
+
+/*
+ * These magic incantations are chosen so that they fault if entered anywhere
+ * other than an instruction boundary.  The movb instruction is two bytes, and
+ * the int imm8 instruction is also two bytes, so the only misaligned places
+ * to enter are the immediate values for the two instructions.  0xcc is int3
+ * (always faults), 0xce is into (faults on x64-64, and 32-bit code can't get
+ * here), and 0xf0 is lock (lock int is invalid).
+ *
+ * The unused parts of the page are filled with 0xcc by the linker script.
+ */
+
+.section .vsyscall_0, "a"
+ENTRY(vsyscall_0)
+	movb $0xcc, %al
+	int $VSYSCALL_EMU_VECTOR
+	ret
+END(vsyscall_0)
+
+.section .vsyscall_1, "a"
+ENTRY(vsyscall_1)
+	movb $0xce, %al
+	int $VSYSCALL_EMU_VECTOR
+	ret
+END(vsyscall_1)
+
+.section .vsyscall_2, "a"
+ENTRY(vsyscall_2)
+	movb $0xf0, %al
+	int $VSYSCALL_EMU_VECTOR
+	ret
+END(vsyscall_2)

Signature · 1 line

1.7.5.1

Quoted 142 lines · Andy Lutomirski

There's a fair amount of code in the vsyscall page, and who knows what will happen if an exploit jumps into the middle of it.  Reduce the risk by replacing most of it with short magic incantations that are useless if entered in the middle.  This change can be disabled by CONFIG_UNSAFE_VSYSCALLS (default y).

This causes vsyscalls to be a little more expensive than real syscalls.  Fortunately sensible programs don't use them.

Some care is taken to make sure that tools like valgrind and ThreadSpotter still work.

This patch is not perfect: the vread_tsc and vread_hpet functions are still at a fixed address.  Fixing that might involve making alternative patching work in the vDSO.

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/Kconfig                  |   17 +++++ arch/x86/kernel/Makefile          |    3 + arch/x86/kernel/vsyscall_64.c     |  121 +++++++++++++++++++++++++++++++++++-- arch/x86/kernel/vsyscall_emu_64.S |   40 ++++++++++++

 4 files changed, 176 insertions(+), 5 deletions(-)

 create mode 100644 arch/x86/kernel/vsyscall_emu_64.S

arch/x86/Kconfig +0 -0

index cc6c53a..186018b 100644
@@ -1650,6 +1650,23 @@ config COMPAT_VDSO
 

        If unsure, say Y.

arch/x86/Kconfig +17 -0

+config UNSAFE_VSYSCALLS
+     def_bool y
+     prompt "Unsafe fast legacy vsyscalls"
+     depends on X86_64
+     ---help---
+       Legacy user code expects to be able to issue three syscalls
+       by calling fixed addresses in kernel space.  If you say N,
+       then the kernel traps and emulates these calls.  If you say
+       Y, then there is actual executable code at a fixed address
+       to implement these calls efficiently.
+
+       On a system with recent enough glibc (probably 2.14 or
+       newer) and no static binaries, you can say N without a
+       performance penalty to improve security
+
+       If unsure, say Y.
+

 config CMDLINE_BOOL
      bool "Built-in kernel command line"
      ---help---

arch/x86/kernel/Makefile +0 -0

index a24521b..b901781 100644
@@ -42,6 +42,9 @@ obj-$(CONFIG_X86_32)        += probe_roms_32.o

 obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o obj-$(CONFIG_X86_64) += syscall_64.o vsyscall_64.o vread_tsc_64.o

arch/x86/kernel/Makefile +3 -0

+ifndef CONFIG_UNSAFE_VSYSCALLS
+     obj-$(CONFIG_X86_64)    += vsyscall_emu_64.o
+endif

 obj-y                        += bootflag.o e820.o
 obj-y                        += pci-dma.o quirks.o topology.o kdebugfs.o obj-y                        += alternative.o i8253.o pci-nommu.o hw_breakpoint.o

arch/x86/kernel/vsyscall_64.c +0 -3

index 71fa506..5b3d62a 100644
@@ -48,9 +48,6 @@
  #include <asm/vgtod.h>
  #include <asm/traps.h>
 
-#define __vsyscall(nr) \
-             __attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace
-
  DEFINE_VVAR(int, vgetcpu_mode);

 DEFINE_VVAR(struct vsyscall_gtod_data, vsyscall_gtod_data) = {

arch/x86/kernel/vsyscall_64.c +12 -2

@@ -96,6 +93,7 @@ static void warn_bad_vsyscall(struct pt_regs *regs, bool is_warning,
               return;
 
       tsk = current;
+
       printk("%s%s[%d] %s ip:%lx sp:%lx ax:%lx si:%lx di:%lx",
              is_warning ? KERN_WARNING : KERN_INFO,
              tsk->comm, task_pid_nr(tsk),

@@ -106,6 +104,12 @@ static void warn_bad_vsyscall(struct pt_regs *regs, bool is_warning,
       printk("\n");
  }
 
+#ifdef CONFIG_UNSAFE_VSYSCALLS
+
+#define __vsyscall(nr)                                                       \
+     __attribute__ ((unused, __section__(".vsyscall_" #nr))) notrace
+
+
  /* RED-PEN may want to readd seq locking, but then the variable should be
   * write-once.
   */

@@ -117,8 +121,11 @@ static __always_inline void do_get_tz(struct timezone * tz)
  static __always_inline int fallback_gettimeofday(struct timeval *tv)
  {
       int ret;
-     /* Invoke do_emulate_vsyscall. */
-     asm volatile("movb $0xce, %%al;\n\t"
+     /*
+      * Invoke do_emulate_vsyscall.  Intentionally incompatible with
+      * the CONFIG_UNSAFE_VSYSCALLS=n case.
+      */
+     asm volatile("mov $0xce, %%al;\n\t"

                   "int %[vec]"
                   : "=a" (ret)
                   : "D" (tv), [vec] "i" (VSYSCALL_EMU_VECTOR));

arch/x86/kernel/vsyscall_64.c +15 -0

@@ -237,6 +244,8 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
       long ret;
 
       /* Kernel code must never get here. */
+     if (!user_mode(regs))
+             early_printk("oh crap!\n");
       BUG_ON(!user_mode(regs));
 
       local_irq_enable();

@@ -278,6 +287,106 @@ out:
       local_irq_disable();
  }
 
+#else /* CONFIG_UNSAFE_VSYSCALLS=n below */
+
+static inline unsigned long vsyscall_intcc_addr(int vsyscall_nr)
+{
+     return VSYSCALL_START + 1024*vsyscall_nr + 2;
+}
+
+void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
+{
+     u8 vsyscall_nr, al;
+     long ret;
+
+     /* Kernel code must never get here. */

arch/x86/kernel/vsyscall_64.c out: · line 312

Quoted 10 lines

arch/x86/kernel/vsyscall_64.c +10 -0

+     BUG_ON(!user_mode(regs));
+
+     local_irq_enable();
+
+     /*
+      * Decode the vsyscall number.
+      * 0xcc -> 0, 0xce -> 1, 0xf0 -> 2; see vsyscall_emu_64.S for why.
+      */
+     al = regs->ax & 0xff;
+     vsyscall_nr = (al - 0xcc) >> 1;

Ok, but

       (0xf0 - 0xcc) >> 1 == 0x12

Don't you mean 0xd0 here? Although 0xd0 is opcode for all those rotate/shift insns. What am I missing?

There's a fair amount of code in the vsyscall page, and who knows what will happen if an exploit jumps into the middle of it. Reduce the risk by replacing most of it with short magic incantations that are useless if entered in the middle. This change can be disabled by CONFIG_UNSAFE_VSYSCALLS (default y).

Quoted 5 lines · Andy Lutomirski

There's a fair amount of code in the vsyscall page, and who knows what will happen if an exploit jumps into the middle of it.  Reduce the risk by replacing most of it with short magic incantations that are useless if entered in the middle.  This change can be disabled by CONFIG_UNSAFE_VSYSCALLS (default y).

btw., please flip the default or consider removing the option altogether.

We want to improve security and we want safe vsyscalls the default, and it's no good if we make it too easy for users to keep the fire door open all the time! :-)

Quoted 9 lines · Ingo Molnar

Quoted 5 lines · Andy Lutomirski

There's a fair amount of code in the vsyscall page, and who knows what will happen if an exploit jumps into the middle of it.  Reduce the risk by replacing most of it with short magic incantations that are useless if entered in the middle.  This change can be disabled by CONFIG_UNSAFE_VSYSCALLS (default y).

Quoted 6 lines

btw., please flip the default or consider removing the option altogether.

We want to improve security and we want safe vsyscalls the default, and it's no good if we make it too easy for users to keep the fire door open all the time! :-)

I'd advocate waiting until glibc 2.14 comes out with this change:

http://sourceware.org/git/?p=glibc.git;a=commit;h=a8509ca540427502bd955f35296ff7b727c7a8a1

I want to add a warning (ratelimited to an extremely low rate) in v3 whenever any of the vsyscalls get used telling users that their legacy code is suffering a performance impact, but it seems like bad form to tell people to build glibc from git to avoid a regression.

Quoted 5 lines · Andrew Lutomirski

I'd advocate waiting until glibc 2.14 comes out with this change:

http://sourceware.org/git/?p=glibc.git;a=commit;h=a8509ca540427502bd955f35296ff7b727c7a8a1

Quoted 4 lines

I want to add a warning (ratelimited to an extremely low rate) in v3 whenever any of the vsyscalls get used telling users that their legacy code is suffering a performance impact, but it seems like bad form to tell people to build glibc from git to avoid a regression.

But only statically built binaries would be impacted in practice, right? The number of statically built binaries that heavily rely on vsyscalls ought to be a very small set ...

Quoted 13 lines · Ingo Molnar

Quoted 9 lines · Andrew Lutomirski

I'd advocate waiting until glibc 2.14 comes out with this change:

http://sourceware.org/git/?p=glibc.git;a=commit;h=a8509ca540427502bd955f35296ff7b727c7a8a1

I want to add a warning (ratelimited to an extremely low rate) in v3 whenever any of the vsyscalls get used telling users that their legacy code is suffering a performance impact, but it seems like bad form to tell people to build glibc from git to avoid a regression.

Quoted 3 lines

But only statically built binaries would be impacted in practice, right? The number of statically built binaries that heavily rely on vsyscalls ought to be a very small set ...

With current glibc even dynamic binaries take the hit on time().

With the emulation warning (coming in v3), I get (on a Fedora 15-based VM):

[    0.635493] init[1] emulated legacy vsyscall time(); upgrade your

code to avoid a performance hit. ip:ffffffffff600404 sp:7fff277fe9c8 caller:3da3e9e27d in libc.so.6[3da3e00000+192000]

Quoted 14 lines · Andrew Lutomirski

Quoted 13 lines · Ingo Molnar

Quoted 9 lines · Andrew Lutomirski

I'd advocate waiting until glibc 2.14 comes out with this change:

http://sourceware.org/git/?p=glibc.git;a=commit;h=a8509ca540427502bd955f35296ff7b727c7a8a1

I want to add a warning (ratelimited to an extremely low rate) in v3 whenever any of the vsyscalls get used telling users that their legacy code is suffering a performance impact, but it seems like bad form to tell people to build glibc from git to avoid a regression.

Quoted 5 lines

Quoted 3 lines

But only statically built binaries would be impacted in practice, right? The number of statically built binaries that heavily rely on vsyscalls ought to be a very small set ...

With current glibc even dynamic binaries take the hit on time().

Indeed, you are right, i completely forgot that again :)

Quoted 3 lines

With the emulation warning (coming in v3), I get (on a Fedora 15-based VM):

Quoted 3 lines

[    0.635493] init[1] emulated legacy vsyscall time(); upgrade your code to avoid a performance hit. ip:ffffffffff600404 sp:7fff277fe9c8 caller:3da3e9e27d in libc.so.6[3da3e00000+192000]

Ok, so we should leave the option enabled by default and distros can flip it as they upgrade/fix glibc, right?

But I'll make the option control just time() instead of all three. That will also reduce the size of the patch :)

Quoted 1 line

Quoted 1 line · Andy Lutomirski

This causes vsyscalls to be a little more expensive than real syscalls. Fortunately sensible programs don't use them.

arch/x86/Kconfig +17 -0

@@ -1650,6 +1650,23 @@ config COMPAT_VDSO
 
 	  If unsure, say Y.
 
+config UNSAFE_VSYSCALLS
+	def_bool y
+	prompt "Unsafe fast legacy vsyscalls"
+	depends on X86_64
+	---help---
+	  Legacy user code expects to be able to issue three syscalls
+	  by calling fixed addresses in kernel space.  If you say N,
+	  then the kernel traps and emulates these calls.  If you say
+	  Y, then there is actual executable code at a fixed address
+	  to implement these calls efficiently.
+
+	  On a system with recent enough glibc (probably 2.14 or
+	  newer) and no static binaries, you can say N without a
+	  performance penalty to improve security
+
+	  If unsure, say Y.
+
 config CMDLINE_BOOL
 	bool "Built-in kernel command line"
 	---help---

arch/x86/kernel/Makefile +0 -0

 obj-y			+= bootflag.o e820.o
 obj-y			+= pci-dma.o quirks.o topology.o kdebugfs.o
 obj-y			+= alternative.o i8253.o pci-nommu.o hw_breakpoint.o

Quoted 3 lines

Quoted 1 line

Quoted 1 line · Andy Lutomirski

This causes vsyscalls to be a little more expensive than real syscalls. Fortunately sensible programs don't use them.

Hmm - weren't vsyscalls there for performance reasons?

Quoted 3 lines

Quoted 1 line

Quoted 1 line · Andy Lutomirski

This causes vsyscalls to be a little more expensive than real syscalls.  Fortunately sensible programs don't use them.

Hmm - weren't vsyscalls there for performance reasons?

Besides that, just a mostly cosmetic remark:

Quoted 32 lines

arch/x86/Kconfig +0 -0

@@ -1650,6 +1650,23 @@ config COMPAT_VDSO
 

        If unsure, say Y.

arch/x86/Kconfig +17 -0

+config UNSAFE_VSYSCALLS
+     def_bool y
+     prompt "Unsafe fast legacy vsyscalls"
+     depends on X86_64
+     ---help---
+       Legacy user code expects to be able to issue three syscalls
+       by calling fixed addresses in kernel space.  If you say N,
+       then the kernel traps and emulates these calls.  If you say
+       Y, then there is actual executable code at a fixed address
+       to implement these calls efficiently.
+
+       On a system with recent enough glibc (probably 2.14 or
+       newer) and no static binaries, you can say N without a
+       performance penalty to improve security
+
+       If unsure, say Y.
+

 config CMDLINE_BOOL
      bool "Built-in kernel command line"
      ---help---

arch/x86/kernel/Makefile +0 -0

@@ -42,6 +42,9 @@ obj-$(CONFIG_X86_32)        += probe_roms_32.o

 obj-$(CONFIG_X86_32) += sys_i386_32.o i386_ksyms_32.o obj-$(CONFIG_X86_64) += sys_x86_64.o x8664_ksyms_64.o obj-$(CONFIG_X86_64) += syscall_64.o vsyscall_64.o vread_tsc_64.o

arch/x86/kernel/Makefile obj-$(CONFIG_X86_32) += probe_roms_32.o · line 47

Quoted 3 lines

arch/x86/kernel/Makefile +3 -0

+ifndef CONFIG_UNSAFE_VSYSCALLS
+     obj-$(CONFIG_X86_64)    += vsyscall_emu_64.o
+endif

With the Kconfig dependency on X86_64 above and the new variable being a boolean one, these three lines can be written as just

obj-$(CONFIG_UNSAFE_VSYSCALLS) += vsyscall_emu_64.o

Signed-off-by Andy Lutomirski <[email protected]>

---
 Documentation/x86/entry_64.txt |   95 ++++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/entry_64.S     |    2 +
 2 files changed, 97 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/x86/entry_64.txt

Documentation/x86/entry_64.txt new file +0 -0

new file mode 100644
index 0000000..081c405

Documentation/x86/entry_64.txt new file +23 -0

+
+The IDT vector assignments are listed in arch/x86/include/irq_vectors.h.
+
+Some of these entries are:
+
+ - system_call: syscall instruction from 64-bit code.
+
+ - ia32_syscall: int 0x80 from 32-bit or 64-bit code; compat syscall
+   either way.
+
+ - ia32_syscall, ia32_sysenter: syscall and sysenter from 32-bit code
+
+ - interrupt: An array of entries.  Every IDT vector that doesn't
+   explicitly point somewhere else gets set to the corresponding value
+   in interrupts.  These point to a whole array of magically-generated
+   functions that make their way to do_IRQ with the interrupt number
+   as a parameter.
+
+ - emulate_vsyscall: int 0xcc, a special non-ABI entry used by
+   vsyscall emulation.
+
+ - APIC interrupts: Various special-purpose interrupts for things like
+   TLB shootdown.

Documentation/x86/entry_64.txt new file +53 -0

+
+Dealing with the swapgs instruction is especially tricky.  Swapgs
+toggles whether gs is the kernel gs or the user gs.  The swapgs
+instruction is rather fragile: it must nest perfectly and only in
+single depth, it should only be used if entering from user mode to
+kernel mode and then when returning to user-space, and precisely
+so. If we mess that up even slightly, we crash.
+
+So when we have a secondary entry, already in kernel mode, we *must
+not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's
+not switched/swapped yet.
+
+Now, there's a secondary complication: there's a cheap way to test
+which mode the CPU is in and an expensive way.
+
+The cheap way is to pick this info off the entry frame on the kernel
+stack, from the CS of the ptregs area of the kernel stack:
+
+	xorl %ebx,%ebx
+	testl $3,CS+8(%rsp)
+	je error_kernelspace
+	SWAPGS
+
+The expensive (paranoid) way is to read back the MSR_GS_BASE value
+(which is what SWAPGS modifies):
+
+	movl $1,%ebx
+	movl $MSR_GS_BASE,%ecx
+	rdmsr
+	testl %edx,%edx
+	js 1f   /* negative -> in kernel */
+	SWAPGS
+	xorl %ebx,%ebx
+1:	ret
+
+and the whole paranoid non-paranoid macro complexity is about whether
+to suffer that RDMSR cost.
+
+If we are at an interrupt or user-trap/gate-alike boundary then we can
+use the faster check: the stack will be a reliable indicator of
+whether SWAPGS was already done: if we see that we are a secondary
+entry interrupting kernel mode execution, then we know that the GS
+base has already been switched. If it says that we interrupted
+user-space execution then we must do the SWAPGS.
+
+But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context,
+which might have triggered right after a normal entry wrote CS to the
+stack but before we executed SWAPGS, then the only safe way to check
+for GS is the slower method: the RDMSR.
+
+So we try only to mark those entry methods 'paranoid' that absolutely
+need the more expensive check for the GS base - and we generate all
+'normal' entry points with the regular (faster) entry macros.

arch/x86/kernel/entry_64.S +2 -0

index bee7e81..e949793 100644
@@ -9,6 +9,8 @@
 /*
  * entry.S contains the system-call and fault low-level handling routines.
  *
+ * Some of this is documented in Documentation/x86/entry_64.txt
+ *
  * NOTE: This code handles signal-recognition, which happens every time
  * after an interrupt and after each system call.
  *

Signature · 1 line

1.7.5.1

Quoted 1 line · Andy Lutomirski

Signed-off-by Andy Lutomirski <[email protected]>

Oh yeah!

Acked-by Borislav Petkov <[email protected]>

Documentation/x86/entry_64.txt

Quoted 3 lines

Documentation/x86/entry_64.txt new file +3 -0

+The x86 architecture has quite a few different ways to jump into
+kernel code.  Most of these entry points are registered in
+arch/x86/kernel/traps.c and implemented in arch/x86/kernel/entry_64.S

and arch/x86/ia32/ia32entry.S

Documentation/x86/entry_64.txt line 42

Quoted 8 lines

Documentation/x86/entry_64.txt new file +8 -0

+
+There are a few complexities here.  The different x86-64 entries have
+different calling conventions.  The syscall and sysenter instructions
+have their own peculiar calling conventions.  Some of the IDT entries
+push an error code onto the stack; others don't.  IDT entries using
+the IST alternative stack mechanism need their own magic to get the
+stack frames right.  (You can find some documentation in the Intel
+SDM, Volume 3, Chapter 6.)

and the AMD APM Volume 2, Chapter 8.

(And whose idea was it to have pushing the error code be optional?)