What do you mean by this? This report is super cryptic and although some may be familiar with it, users looking to see if this issue matches the issues they are experiencing this report means nothing to them.

We use this bug tracker for feature development work, not just for user bug reports. This is not a bug report, it's a feature tracking bug; by definition this will not match any issues users are seeing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8

commit 97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8
Author: Andy Lutomirski <luto@amacapital.net>
Date: Fri Oct 27 23:13:53 2017

BACKPORT: x86: Clean up cr4 manipulation

[ Upstream commit 375074cc736ab1d89a708c0a8d7baa4a70d5d476 ]

CR4 manipulation was split, seemingly at random, between direct
(write_cr4) and using a helper (set/clear_in_cr4).  Unfortunately,
the set_in_cr4 and clear_in_cr4 helpers also poke at the boot code,
which only a small subset of users actually wanted.

This patch replaces all cr4 access in functions that don't leave cr4
exactly the way they found it with new helpers cr4_set_bits,
cr4_clear_bits, and cr4_set_bits_and_update_boot.

(Cherry-picked from 3.18 stable to reduce conflicts.)

Change-Id: I7083d630fd830a62944e363a48ef47c1a524c23b
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Vince Weaver <vince@deater.net>
Cc: "hillf.zj" <hillf.zj@alibaba-inc.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/495a10bdc9e67016b8fd3945700d46cfd5c12c2f.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
BUG= chromium:778348 
TEST=Build kernel, remote trybot.
Reviewed-on: https://chromium-review.googlesource.com/738273
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/drivers/lguest/x86/core.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/i387.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/xsave.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/include/asm/processor.h
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/process.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/include/asm/virtext.h
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/cpu/mcheck/mce.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/cpu/perf_event.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/cpu/mcheck/winchip.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/mm/init.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/include/asm/tlbflush.h
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/xen/enlighten.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/cpu/common.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kernel/cpu/mcheck/p5.c
[modify] https://crrev.com/97a9b40af9a021ae6d0bfed4100a35d1c89ae1b8/arch/x86/kvm/vmx.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/f597a8b411b53a8b7bd0902c551331e6158f97fa

commit f597a8b411b53a8b7bd0902c551331e6158f97fa
Author: Andy Lutomirski <luto@amacapital.net>
Date: Fri Oct 27 23:13:54 2017

BACKPORT: x86: Store a per-cpu shadow copy of CR4

[ Upstream commit 1e02ce4cccdcb9688386e5b8d2c9fa4660b45389 ]

Context switches and TLB flushes can change individual bits of CR4.
CR4 reads take several cycles, so store a shadow copy of CR4 in a
per-cpu variable.

To avoid wasting a cache line, I added the CR4 shadow to
cpu_tlbstate, which is already touched in switch_mm.  The heaviest
users of the cr4 shadow will be switch_mm and __switch_to_xtra, and
__switch_to_xtra is called shortly after switch_mm during context
switch, so the cacheline is likely to be hot.

(Cherry-picked from 3.18 stable to reduce conflicts.)

Change-Id: I340efb66508bcab52d944693ab091ccb462eed11
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Vince Weaver <vince@deater.net>
Cc: "hillf.zj" <hillf.zj@alibaba-inc.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/3a54dd3353fffbf84804398e00dfdc5b7c1afd7d.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
BUG= chromium:778348 
TEST=Build kernel, remote trybot.
Reviewed-on: https://chromium-review.googlesource.com/738274
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/include/asm/special_insns.h
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/head32.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/mm/tlb.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/process_64.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/realmode/init.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/include/asm/virtext.h
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/cpu/mtrr/generic.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/power/cpu.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kvm/svm.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/cpu/mtrr/cyrix.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/process_32.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/acpi/sleep.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/include/asm/paravirt.h
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/mm/fault.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kvm/vmx.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/mm/init.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/include/asm/tlbflush.h
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/setup.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/cpu/common.c
[modify] https://crrev.com/f597a8b411b53a8b7bd0902c551331e6158f97fa/arch/x86/kernel/head64.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/858bf59678990906f4db290b47d6bc7e4e2161f7

commit 858bf59678990906f4db290b47d6bc7e4e2161f7
Author: Peter Zijlstra <peterz@infradead.org>
Date: Fri Oct 27 23:13:55 2017

UPSTREAM: rcu: Move lockless_dereference() out of rcupdate.h

commit 0a04b0166929405cd833c1cc40f99e862b965ddc upstream.

I want to use lockless_dereference() from seqlock.h, which would mean
including rcupdate.h from it, however rcupdate.h already includes
seqlock.h.

Avoid this by moving lockless_dereference() into compiler.h. This is
somewhat tricky since it uses smp_read_barrier_depends() which isn't
available there, but its a CPP macro so we can get away with it.

The alternative would be moving it into asm/barrier.h, but that would
be updating each arch (I can do if people feel that is more
appropriate).

Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ luis: 3.16 prereq for:
  37868fe113ff "x86/ldt: Make modify_ldt synchronous" ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>

Change-Id: I5db812c9708c029e1ce9c2dfda0bf871b5fbefb6
Signed-off-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
BUG= chromium:778348 
TEST=Build kernel, remote trybot.
Reviewed-on: https://chromium-review.googlesource.com/738275
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/858bf59678990906f4db290b47d6bc7e4e2161f7/include/linux/compiler.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e7a4caae4c546772f594c6aa7c7f0d17a7297263

commit e7a4caae4c546772f594c6aa7c7f0d17a7297263
Author: Andy Lutomirski <luto@kernel.org>
Date: Fri Oct 27 23:13:56 2017

BACKPORT: x86/ldt: Make modify_ldt synchronous

[ Upstream commit 37868fe113ff2ba814b3b4eb12df214df555f8dc ]

modify_ldt() has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

This fixes some fallout from the CVE-2015-5157 fixes.

(Cherry-picked from 3.18 stable to reduce conflicts.)

Change-Id: I6007b9f915b80c05e9bc353ea19621efc66b2f9d
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org <security@kernel.org>
Cc: <stable@vger.kernel.org>
Cc: xen-devel <xen-devel@lists.xen.org>
Link: http://lkml.kernel.org/r/4c6978476782160600471bd865b318db34c7b628.1438291540.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
BUG= chromium:778348 
TEST=Build kernel, remote trybot.
Reviewed-on: https://chromium-review.googlesource.com/738276
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/power/cpu.c
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/include/asm/mmu_context.h
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/kernel/ldt.c
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/kernel/step.c
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/kernel/cpu/perf_event.c
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/include/asm/desc.h
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/kernel/cpu/common.c
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/include/asm/mmu.h
[modify] https://crrev.com/e7a4caae4c546772f594c6aa7c7f0d17a7297263/arch/x86/kernel/process_64.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ec8d458e9617efc7cfe36161cca457a2927a545d

commit ec8d458e9617efc7cfe36161cca457a2927a545d
Author: Juergen Gross <jgross@suse.com>
Date: Fri Oct 27 23:13:58 2017

UPSTREAM: x86/ldt: Correct LDT access in single stepping logic

[ Upstream commit 136d9d83c07c5e30ac49fc83b27e8c4842f108fc ]

Commit 37868fe113ff ("x86/ldt: Make modify_ldt synchronous")
introduced a new struct ldt_struct anchored at mm->context.ldt.

convert_ip_to_linear() was changed to reflect this, but indexing
into the ldt has to be changed as the pointer is no longer void *.

(Cherry-picked from 3.18 stable to avoid conflicts.)

Change-Id: Ib718342fad44c15f1d9a75749e68d20717d38e85
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Andy Lutomirski <luto@kernel.org>
Cc: <stable@vger.kernel.org> # On top of: 37868fe113ff: x86/ldt: Make modify_ldt synchronous
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@suse.de
Link: http://lkml.kernel.org/r/1438848278-12906-1-git-send-email-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
BUG= chromium:778348 
TEST=Build kernel, remote trybot.
Reviewed-on: https://chromium-review.googlesource.com/738277
Reviewed-by: Guenter Roeck <groeck@chromium.org>

[modify] https://crrev.com/ec8d458e9617efc7cfe36161cca457a2927a545d/arch/x86/kernel/step.c