linux.git/arch/x86/include/asm/stackprotector.h, branch v4.12

x86: Remap GDT tables in the fixmap section

2017-03-16T08:06:35+00:00

Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).

This patch relocates the GDT table for each processor inside the
fixmap section. The space is reserved based on number of supported
processors.

For consistency, the remapping is done by default on 32 and 64-bit.

Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.

This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.

Thanks to Boris Ostrovsky  for testing and
recommending changes for Xen support.

Signed-off-by: Thomas Garnier 
Cc: Alexander Potapenko 
Cc: Andrew Morton 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Chris Wilson 
Cc: Christian Borntraeger 
Cc: Dmitry Vyukov 
Cc: Frederic Weisbecker 
Cc: Jiri Kosina 
Cc: Joerg Roedel 
Cc: Jonathan Corbet 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Kees Cook 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Lorenzo Stoakes 
Cc: Luis R . Rodriguez 
Cc: Matt Fleming 
Cc: Michal Hocko 
Cc: Paolo Bonzini 
Cc: Paul Gortmaker 
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rafael J . Wysocki 
Cc: Rusty Russell 
Cc: Stanislaw Gruszka 
Cc: Thomas Gleixner 
Cc: Tim Chen 
Cc: Vitaly Kuznetsov 
Cc: kasan-dev@googlegroups.com
Cc: kernel-hardening@lists.openwall.com
Cc: kvm@vger.kernel.org
Cc: lguest@lists.ozlabs.org
Cc: linux-doc@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-pm@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: zijun_hu 
Link: http://lkml.kernel.org/r/20170314170508.100882-2-thgarnie@google.com
Signed-off-by: Ingo Molnar

x86/asm/tsc: Rename native_read_tsc() to rdtsc()

2015-07-06T13:23:28+00:00

Now that there is no paravirt TSC, the "native" is
inappropriate. The function does RDTSC, so give it the obvious
name: rdtsc().

Suggested-by: Borislav Petkov 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Huang Rui 
Cc: John Stultz 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Ralf Baechle 
Cc: Thomas Gleixner 
Cc: kvm ML 
Link: http://lkml.kernel.org/r/fd43e16281991f096c1e4d21574d9e1402c62d39.1434501121.git.luto@kernel.org
[ Ported it to v4.2-rc1. ]
Signed-off-by: Ingo Molnar

x86/asm/tsc: Inline native_read_tsc() and remove __native_read_tsc()

2015-07-06T13:23:25+00:00

In the following commit:

  cdc7957d1954 ("x86: move native_read_tsc() offline")

... native_read_tsc() was moved out of line, presumably for some
now-obsolete vDSO-related reason. Undo it.

The entire rdtsc, shl, or sequence is only 11 bytes, and calls
via rdtscl() and similar helpers were already inlined.

Signed-off-by: Andy Lutomirski 
Signed-off-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Huang Rui 
Cc: John Stultz 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Ralf Baechle 
Cc: Thomas Gleixner 
Cc: kvm ML 
Link: http://lkml.kernel.org/r/d05ffe2aaf8468ca475ebc00efad7b2fa174af19.1434501121.git.luto@kernel.org
Signed-off-by: Ingo Molnar

x86/fpu: Move various internal function prototypes to fpu/internal.h

2015-05-19T13:47:48+00:00

There are a number of FPU internal function prototypes and an inline function
in fpu/api.h, mostly placed so historically as the code grew over the years.

Move them over into fpu/internal.h where they belong. (Add sched.h include
to stackprotector.h which incorrectly relied on getting it from fpu/api.h.)

fpu/api.h is now a pure file that only contains FPU APIs intended for driver
use.

Reviewed-by: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Oleg Nesterov 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Signed-off-by: Ingo Molnar

x86: replace percpu_xxx funcs with this_cpu_xxx

2012-05-14T21:15:31+00:00

Since percpu_xxx() serial functions are duplicated with this_cpu_xxx().
Removing percpu_xxx() definition and replacing them by this_cpu_xxx()
in code. There is no function change in this patch, just preparation for
later percpu_xxx serial function removing.

On x86 machine the this_cpu_xxx() serial functions are same as
__this_cpu_xxx() without no unnecessary premmpt enable/disable.

Thanks for Stephen Rothwell, he found and fixed a i386 build error in
the patch.

Also thanks for Andrew Morton, he kept updating the patchset in Linus'
tree.

Signed-off-by: Alex Shi 
Acked-by: Christoph Lameter 
Acked-by: Tejun Heo 
Acked-by: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Andrew Morton 
Signed-off-by: Tejun Heo

Disintegrate asm/system.h for X86

2012-03-28T17:11:12+00:00

Disintegrate asm/system.h for X86.

Signed-off-by: David Howells 
Acked-by: H. Peter Anvin 
cc: x86@kernel.org

x86/i386: Make sure stack-protector segment base is cache aligned

2009-09-03T19:30:51+00:00

The Intel Optimization Reference Guide says:

	In Intel Atom microarchitecture, the address generation unit
	assumes that the segment base will be 0 by default. Non-zero
	segment base will cause load and store operations to experience
	a delay.
		- If the segment base isn't aligned to a cache line
		  boundary, the max throughput of memory operations is
		  reduced to one [e]very 9 cycles.
	[...]
	Assembly/Compiler Coding Rule 15. (H impact, ML generality)
	For Intel Atom processors, use segments with base set to 0
	whenever possible; avoid non-zero segment base address that is
	not aligned to cache line boundary at all cost.

We can't avoid having a non-zero base for the stack-protector
segment, but we can make it cache-aligned.

Signed-off-by: Jeremy Fitzhardinge 
Cc: 
LKML-Reference: <4AA01893.6000507@goop.org>
Signed-off-by: Ingo Molnar

x86: Introduce GDT_ENTRY_INIT()

2009-08-08T15:44:11+00:00

GDT_ENTRY_INIT is static initializer of desc_struct.

We already have similar macro GDT_ENTRY() but it's static
initializer for u64 and it cannot be used for desc_struct.

Signed-off-by: Akinobu Mita 
LKML-Reference: <20090718151219.GD11294@localhost.localdomain>
Signed-off-by: Ingo Molnar

x86: Introduce set_desc_base() and set_desc_limit()

2009-07-19T16:27:52+00:00

Rename set_base()/set_limit to set_desc_base()/set_desc_limit()
and rewrite them in C. These are naturally introduced by the
idea of get_desc_base()/get_desc_limit().

The conversion actually found the bug in apm_32.c:
bad_bios_desc is written at run-time, but it is defined const
variable.

Signed-off-by: Akinobu Mita 
LKML-Reference: <20090718151105.GC11294@localhost.localdomain>
Signed-off-by: Ingo Molnar

x86: fix x86_32 stack protector bugs

2009-02-11T10:33:49+00:00

Impact: fix x86_32 stack protector

Brian Gerst found out that %gs was being initialized to stack_canary
instead of stack_canary - 20, which basically gave the same canary
value for all threads.  Fixing this also exposed the following bugs.

* cpu_idle() didn't call boot_init_stack_canary()

* stack canary switching in switch_to() was being done too late making
  the initial run of a new thread use the old stack canary value.

Fix all of them and while at it update comment in cpu_idle() about
calling boot_init_stack_canary().

Reported-by: Brian Gerst 
Signed-off-by: Tejun Heo 
Signed-off-by: Ingo Molnar