[RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Ingo Molnar]

Linus,

Please consider pulling the latest x86-pti-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-pti-for-linus

   # HEAD: eeb17ad55b3f7959805ae995fe955d6d93e67e89 Merge branch 'WIP.x86/pti.entry' into x86/pti

These are the x86-64 low level entry code preparatory patches for the page table 
isolation patches - which are required for PTI, which addresses KASLR and similar 
information leaks.

The merges and commits have the following structure:

1)

The tree with HEAD 2533a63618fc is the 'v4.14 backporting base tree': it's a 
handful of x86 entry code specific merges, combined with a handful of cherry-picks.
The cherry-picks are marked in such a clear fashion:

    [ Note, this commit is a cherry-picked version of:
    
        d17a1d97dc20: ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow")
    
      ... for easier x86 entry code testing and back-porting. ]

Otherwise they contain the original changelog. There's also a namespace
preparatory patch:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the namespace

2)

The cherry-picked tree is merged with a matching v4.14 tree in a conflict-free 
fashion, i.e. an upstream tree version is merged where all the cherry-picks match 
and there's no content conflict.

3)

The remaining new commits are the PTI entry code changes:

aaa01e2049fb: x86/entry/64: Don't use the entry stack on XENPV and optimize sync_regs()
c5e1a2f04b59: x86/cpufeatures: Make CPU bugs sticky
1f6688f1b26c: x86/paravirt: Provide a way to check for hypervisors
4a24c80e6f8a: x86/paravirt: Dont patch flush_tlb_single
11a1251e3a3c: x86/entry/64: Make cpu_entry_area.tss read-only
dff71e3c0e18: x86/entry: Clean up the SYSENTER_stack code
f3116218fe9e: x86/entry/64: Remove the SYSENTER stack canary
9e2dc3874178: x86/entry/64: Move the IST stacks into struct cpu_entry_area
65bbc819a025: x86/entry/64: Create a per-CPU SYSCALL entry trampoline
813b4125a835: x86/entry/64: Return to userspace from the trampoline stack
4f79eec94c07: x86/entry/64: Use a per-CPU trampoline stack for IDT entries
21b90b9dc777: x86/espfix/64: Stop assuming that pt_regs is on the entry stack
73761a513764: x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
566999c89d26: x86/entry: Remap the TSS into the CPU entry area
df55611bc5d0: x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct
97a1894ff954: x86/dumpstack: Handle stack overflow on all stacks
5ed1fcd523b9: x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
60b6c4ac2d51: x86/kasan/64: Teach KASAN about the cpu_entry_area
5bf215b74703: x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct cpu_entry_area
f61ef66a7bb4: x86/entry/gdt: Put per-CPU GDT remaps in ascending order
3ae6bdda6853: x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
63372c118470: x86/entry/64: Allocate and enable the SYSENTER stack
69282699385f: x86/irq/64: Print the offending IP in the stack overflow warning
1192b8b8232a: x86/irq: Remove an old outdated comment about context tracking races
b8573e790649: x86/unwinder: Handle stack overflows more gracefully
58b6fe6672f8: x86/unwinder/orc: Dont bail on stack overflow
3961a7f4adc8: x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

The main changes here are Andy Lutomirski's changes to switch the x86-64 entry code
to use the 'entry trampoline stack', which is in the fixmap area, and as such doesn't
require any %gs relative kernel percpu data to enter/exit the kernel. This, besides
helping fix KASLR leaks, also robustifies the x86 entry code.

 Thanks,

	Ingo

------------------>

Andi Kleen (1):
      perf/x86: Enable free running PEBS for REGS_USER/INTR

Andrey Ryabinin (1):
      x86/mm/kasan: Don't use vmemmap_populate() to initialize shadow

Andy Lutomirski (22):
      x86/unwinder/orc: Dont bail on stack overflow
      x86/irq: Remove an old outdated comment about context tracking races
      x86/irq/64: Print the offending IP in the stack overflow warning
      x86/entry/64: Allocate and enable the SYSENTER stack
      x86/dumpstack: Add get_stack_info() support for the SYSENTER stack
      x86/entry/gdt: Put per-CPU GDT remaps in ascending order
      x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce struct cpu_entry_area
      x86/kasan/64: Teach KASAN about the cpu_entry_area
      x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss
      x86/dumpstack: Handle stack overflow on all stacks
      x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct
      x86/entry: Remap the TSS into the CPU entry area
      x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0
      x86/espfix/64: Stop assuming that pt_regs is on the entry stack
      x86/entry/64: Use a per-CPU trampoline stack for IDT entries
      x86/entry/64: Return to userspace from the trampoline stack
      x86/entry/64: Create a per-CPU SYSCALL entry trampoline
      x86/entry/64: Move the IST stacks into struct cpu_entry_area
      x86/entry/64: Remove the SYSENTER stack canary
      x86/entry: Clean up the SYSENTER_stack code
      x86/entry/64: Make cpu_entry_area.tss read-only
      x86/entry/64: Don't use the entry stack on XENPV and optimize sync_regs()

Boris Ostrovsky (1):
      x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

Ingo Molnar (3):
      x86/cpufeatures: Re-tabulate the X86_FEATURE definitions
      x86/cpufeatures: Fix various details in the feature definitions
      drivers/misc/intel/pti: Rename the header file to free up the namespace

Josh Poimboeuf (1):
      x86/unwinder: Handle stack overflows more gracefully

Kirill A. Shutemov (1):
      x86/xen: Provide pre-built page tables only for CONFIG_XEN_PV=y and CONFIG_XEN_PVH=y

Ricardo Neri (1):
      x86/cpufeature: Add User-Mode Instruction Prevention definitions

Rudolf Marek (1):
      x86: Make X86_BUG_FXSAVE_LEAK detectable in CPUID on AMD

Thomas Gleixner (3):
      x86/paravirt: Dont patch flush_tlb_single
      x86/paravirt: Provide a way to check for hypervisors
      x86/cpufeatures: Make CPU bugs sticky

Will Deacon (1):
      locking/barriers: Convert users of lockless_dereference() to READ_ONCE()


 arch/x86/entry/entry_32.S            |   6 +-
 arch/x86/entry/entry_64.S            | 189 ++++++++++++++++++++++++++++++-----
 arch/x86/entry/entry_64_compat.S     |   7 +-
 arch/x86/include/asm/cpufeature.h    |   2 +
 arch/x86/include/asm/desc.h          |  11 +-
 arch/x86/include/asm/fixmap.h        |  68 ++++++++++++-
 arch/x86/include/asm/hypervisor.h    |  25 +++--
 arch/x86/include/asm/irqflags.h      |   3 +
 arch/x86/include/asm/kdebug.h        |   1 +
 arch/x86/include/asm/paravirt.h      |   9 ++
 arch/x86/include/asm/processor.h     |  59 +++++++----
 arch/x86/include/asm/stacktrace.h    |   3 +
 arch/x86/include/asm/switch_to.h     |   8 +-
 arch/x86/include/asm/thread_info.h   |   2 +-
 arch/x86/include/asm/traps.h         |   1 -
 arch/x86/include/asm/unwind.h        |   7 ++
 arch/x86/kernel/asm-offsets.c        |   6 ++
 arch/x86/kernel/asm-offsets_32.c     |   9 +-
 arch/x86/kernel/asm-offsets_64.c     |   4 +
 arch/x86/kernel/cpu/common.c         | 170 ++++++++++++++++++++++---------
 arch/x86/kernel/doublefault.c        |  36 ++++---
 arch/x86/kernel/dumpstack.c          |  74 +++++++++++---
 arch/x86/kernel/dumpstack_32.c       |   6 ++
 arch/x86/kernel/dumpstack_64.c       |   6 ++
 arch/x86/kernel/ioport.c             |   2 +-
 arch/x86/kernel/irq.c                |  12 ---
 arch/x86/kernel/irq_64.c             |   4 +-
 arch/x86/kernel/paravirt_patch_64.c  |   2 -
 arch/x86/kernel/process.c            |  19 ++--
 arch/x86/kernel/process_32.c         |   2 +-
 arch/x86/kernel/process_64.c         |  14 +--
 arch/x86/kernel/traps.c              |  69 ++++++++-----
 arch/x86/kernel/unwind_orc.c         |  88 +++++++---------
 arch/x86/kernel/vmlinux.lds.S        |   9 ++
 arch/x86/kvm/vmx.c                   |   2 +-
 arch/x86/lib/delay.c                 |   4 +-
 arch/x86/mm/kasan_init_64.c          |  18 +++-
 arch/x86/power/cpu.c                 |  16 +--
 arch/x86/xen/enlighten_pv.c          |   2 +-
 arch/x86/xen/mmu_pv.c                |   2 +-
 drivers/misc/pti.c                   |   2 +-
 include/linux/{pti.h => intel-pti.h} |   6 +-
 42 files changed, 695 insertions(+), 290 deletions(-)

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Linus Torvalds]

On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar <mingo@kernel.org> wrote:
>
> These are the x86-64 low level entry code preparatory patches for the page table
> isolation patches - which are required for PTI, which addresses KASLR and similar
> information leaks.

Ugh.

Ok, I've read through this, and while I like most of it (I do like the
percpu syscall stack), I have this urge to wait until after rc4. With
the suspend/resume issues, we've had a horrible track record for 4.15
rc's so far, I'l like to not pull another low-level x86 change just
before an rc release and potentially make it four for four broken
rc's.

And I absolutely detest how that cherry-pick branch was done. I can
see why, but:

 - now we have those extra cherry-picks that I already have

 - and the merge commit isn't even a no-op!

Dammit, if the point was to have a branch that worked for 4.14, I can
see that. But look at that merge (on the "other side"), and notice how
the end result is *not* identical to the parent.

IOW, that

  9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
up cherry-picked base tree and preparatory patches

was supposed to be a synchronization point, but if you do

    git diff 9a818d1a3235..9a818d1a3235^

it isn't actually synchronized. It's *almost* synchronized, but not
quite. How did those cherry-picks that were already upstream end up
causing *changes* upstream? That's odd.

So there are some technical oddities in there.

I'll read through it tomorrow again.. Maybe I'll change my mind.

               Linus

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Ingo Molnar]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > These are the x86-64 low level entry code preparatory patches for the page table
> > isolation patches - which are required for PTI, which addresses KASLR and similar
> > information leaks.
> 
> Ugh.
> 
> Ok, I've read through this, and while I like most of it (I do like the
> percpu syscall stack), I have this urge to wait until after rc4. With
> the suspend/resume issues,

Yeah, so as a response to those breakages I recently started testing s2ram as a 
regular part of -tip testing, so every tree I send to you does s2ram fine on my 
(suspendable) testsystems. That's still not full coverage, but should be better 
than what we had.

> [...] we've had a horrible track record for 4.15 rc's so far, I'l like to not 
> pull another low-level x86 change just before an rc release and potentially make 
> it four for four broken rc's.

Yeah, I can understand that. I knew the weekend timing is awkward, but I tried to 
post it as soon as I felt it was ready and as soon upstream (x86) stability looked 
good.

> And I absolutely detest how that cherry-pick branch was done. I can
> see why, but:
> 
>  - now we have those extra cherry-picks that I already have
> 
>  - and the merge commit isn't even a no-op!
> 
> Dammit, if the point was to have a branch that worked for 4.14, I can
> see that. But look at that merge (on the "other side"), and notice how
> the end result is *not* identical to the parent.
> 
> IOW, that
> 
>   9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
> up cherry-picked base tree and preparatory patches
> 
> was supposed to be a synchronization point, but if you do
> 
>     git diff 9a818d1a3235..9a818d1a3235^
> 
> it isn't actually synchronized. It's *almost* synchronized, but not
> quite. How did those cherry-picks that were already upstream end up
> causing *changes* upstream? That's odd.
> 
> So there are some technical oddities in there.

Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, 
except these two commits:

One of the PTI namespace preparatory patches ended up in the 'base' tree:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the namespace

plus there's this cherry-pick from a very recent upstream kernel:

  c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h

which was required for UML to build and be testable.

We can move both commits to a later stage in the tree to make the v4.14 base tree 
an 'obvious' upstream-identical tree.

Will respin it all tomorrow.

Thanks,

	Ingo

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> > was supposed to be a synchronization point, but if you do
> > 
> >     git diff 9a818d1a3235..9a818d1a3235^
> > 
> > it isn't actually synchronized. It's *almost* synchronized, but not
> > quite. How did those cherry-picks that were already upstream end up
> > causing *changes* upstream? That's odd.
> > 
> > So there are some technical oddities in there.
> 
> Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, 
> except these two commits:
> 
> One of the PTI namespace preparatory patches ended up in the 'base' tree:
> 
>   d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the namespace
> 
> plus there's this cherry-pick from a very recent upstream kernel:
> 
>   c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h
> 
> which was required for UML to build and be testable.
> 
> We can move both commits to a later stage in the tree to make the v4.14 base tree 
> an 'obvious' upstream-identical tree.
> 
> Will respin it all tomorrow.

So today I've respun it all, and I think it all got cleaner. I'm going to send you 
3 pull requests:

1) a 'preparatory tree' that is a single commit that frees up the PTI namespace

2) the 'v4.14 backport base tree' which is fully synchronized an should be a no-op 
   merge on your side. I also organized it a bit better with all cherry-picks in a 
   single linear range of commits, with clear notations.

3) the 'per CPU syscall tree', which will be a clean, linear series of commits 
   with no merge distractions whatsoever.

The first two you could pull today, with very low risk levels.

Thanks,

	Ingo