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

commit c15d7575754d4a6e5bba27c7e020df71c97db90b
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 04:56:26 2018

UPSTREAM: KVM: emulate: fix CMPXCHG8B on 32-bit hosts

commit 4ff6f8e61eb7f96d3ca535c6d240f863ccd6fb7d upstream.

This has been broken for a long time: it broke first in 2.6.35, then was
almost fixed in 2.6.36 but this one-liner slipped through the cracks.
The bug shows up as an infinite loop in Windows 7 (and newer) boot on
32-bit hosts without EPT.

Windows uses CMPXCHG8B to write to page tables, which causes a
page fault if running without EPT; the emulator is then called from
kvm_mmu_page_fault.  The loop then happens if the higher 4 bytes are
not 0; the common case for this is that the NX bit (bit 63) is 1.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I1165b0469ad00d238813be2d2e6c96bd990f1cfa
Fixes: 6550e1f165f384f3a46b60a1be9aba4bc3c2adad
Fixes: 16518d5ada690643453eb0aef3cc7841d3623c2d
Reported-by: Erik Rull <erik.rull@rdsoftware.de>
Tested-by: Erik Rull <erik.rull@rdsoftware.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit c8b6504b25d2894e7e3b4909bae15ebcd740120b
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068358

[modify] https://crrev.com/c15d7575754d4a6e5bba27c7e020df71c97db90b/arch/x86/kvm/emulate.c

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

commit 7bb44c8d73699f87bf30ad9fb72583849ecf35a6
Author: Stephan Mueller <smueller@chronox.de>
Date: Wed May 23 04:56:28 2018

UPSTREAM: crypto: aesni - fix memory usage in GCM decryption

[ Upstream commit ccfe8c3f7e52ae83155cb038753f4c75b774ca8a ]

The kernel crypto API logic requires the caller to provide the
length of (ciphertext || authentication tag) as cryptlen for the
AEAD decryption operation. Thus, the cipher implementation must
calculate the size of the plaintext output itself and cannot simply use
cryptlen.

The RFC4106 GCM decryption operation tries to overwrite cryptlen memory
in req->dst. As the destination buffer for decryption only needs to hold
the plaintext memory but cryptlen references the input buffer holding
(ciphertext || authentication tag), the assumption of the destination
buffer length in RFC4106 GCM operation leads to a too large size. This
patch simply uses the already calculated plaintext size.

In addition, this patch fixes the offset calculation of the AAD buffer
pointer: as mentioned before, cryptlen already includes the size of the
tag. Thus, the tag does not need to be added. With the addition, the AAD
will be written beyond the already allocated buffer.

Note, this fixes a kernel crash that can be triggered from user space
via AF_ALG(aead) -- simply use the libkcapi test application
from [1] and update it to use rfc4106-gcm-aes.

Using [1], the changes were tested using CAVS vectors to demonstrate
that the crypto operation still delivers the right results.

[1] http://www.chronox.de/libkcapi.html

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I7b1d0989e787260815c4caaf4b7de72677f214f8
CC: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 3b389956156c23d7936f5a863cf7ac18a92dfee1
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068359

[modify] https://crrev.com/7bb44c8d73699f87bf30ad9fb72583849ecf35a6/arch/x86/crypto/aesni-intel_glue.c

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

commit 8f9cd2ffa84cca08a5a0843e27060d6ed81ec23b
Author: Oleg Nesterov <oleg@redhat.com>
Date: Wed May 23 04:56:29 2018

UPSTREAM: x86/fpu: Avoid math_state_restore() without used_math() in __restore_xstate_sig()

[ Upstream commit a7c80ebcac3068b1c3cb27d538d29558c30010c8 ]

math_state_restore() assumes it is called with irqs disabled,
but this is not true if the caller is __restore_xstate_sig().

This means that if ia32_fxstate == T and __copy_from_user()
fails, __restore_xstate_sig() returns with irqs disabled too.

This triggers:

  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:41
   dump_stack
   ___might_sleep
   ? _raw_spin_unlock_irqrestore
   __might_sleep
   down_read
   ? _raw_spin_unlock_irqrestore
   print_vma_addr
   signal_fault
   sys32_rt_sigreturn

Change __restore_xstate_sig() to call set_used_math()
unconditionally. This avoids enabling and disabling interrupts
in math_state_restore(). If copy_from_user() fails, we can
simply do fpu_finit() by hand.

[ Note: this is only the first step. math_state_restore() should
        not check used_math(), it should set this flag. While
	init_fpu() should simply die. ]

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie47e6505d5512d4597870ed96af063855e3bdedc
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150307153844.GB25954@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 1a29c27a0feda99289ddc41cb5dfbe010d37d374
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068360

[modify] https://crrev.com/8f9cd2ffa84cca08a5a0843e27060d6ed81ec23b/arch/x86/kernel/xsave.c

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

commit 598f098a6f856e3d44758f5e07ffae20c7770608
Author: Oleg Nesterov <oleg@redhat.com>
Date: Wed May 23 04:56:31 2018

UPSTREAM: x86/fpu: Drop_fpu() should not assume that tsk equals current

[ Upstream commit f4c3686386393c120710dd34df2a74183ab805fd ]

drop_fpu() does clear_used_math() and usually this is correct
because tsk == current.

However switch_fpu_finish()->restore_fpu_checking() is called before
__switch_to() updates the "current_task" variable. If it fails,
we will wrongly clear the PF_USED_MATH flag of the previous task.

So use clear_stopped_child_used_math() instead.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Id0484fb8c16fa0a32b2ceb12a71df4a3a0b8c34e
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Rik van Riel <riel@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pekka Riikonen <priikone@iki.fi>
Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20150309171041.GB11388@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 1b6bd91982a1f8b67684a1886dea0373c26e73c2
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068361

[modify] https://crrev.com/598f098a6f856e3d44758f5e07ffae20c7770608/arch/x86/include/asm/fpu-internal.h

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

commit 010ee8547cf3cf90a8c1af4a7f6633e016a65edd
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 04:56:32 2018

UPSTREAM: kvm: move advertising of KVM_CAP_IRQFD to common code

[ Upstream commit dc9be0fac70a2ad86e31a81372bb0bdfb6945353 ]

POWER supports irqfds but forgot to advertise them.  Some userspace does
not check for the capability, but others check it---thus they work on
x86 and s390 but not POWER.

To avoid that other architectures in the future make the same mistake, let
common code handle KVM_CAP_IRQFD the same way as KVM_CAP_IRQFD_RESAMPLE.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: If76f4c922d09e2b89c6e18d6e41c86ae7186b2d9
Reported-and-tested-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org
Fixes: 297e21053a52f060944e9f0de4c64fad9bcd72fc
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 9ab9ee7a87bbea7b4719e0445bcda2d7f0b7d197
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068362

[modify] https://crrev.com/010ee8547cf3cf90a8c1af4a7f6633e016a65edd/arch/x86/kvm/x86.c
[modify] https://crrev.com/010ee8547cf3cf90a8c1af4a7f6633e016a65edd/arch/s390/kvm/kvm-s390.c
[modify] https://crrev.com/010ee8547cf3cf90a8c1af4a7f6633e016a65edd/virt/kvm/kvm_main.c

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

commit b38d0b85e8bc4e82c0d9dc2ef4cdd6b11eeae12e
Author: Jiri Slaby <jslaby@suse.cz>
Date: Wed May 23 04:56:33 2018

UPSTREAM: x86/vdso: Fix the build on GCC5

[ Upstream commit e893286918d2cde3a94850d8f7101cd1039e0c62 ]

On gcc5 the kernel does not link:

  ld: .eh_frame_hdr table[4] FDE at 0000000000000648 overlaps table[5] FDE at 0000000000000670.

Because prior GCC versions always emitted NOPs on ALIGN directives, but
gcc5 started omitting them.

.LSTARTFDEDLSI1 says:

        /* HACK: The dwarf2 unwind routines will subtract 1 from the
           return address to get an address in the middle of the
           presumed call instruction.  Since we didn't get here via
           a call, we need to include the nop before the real start
           to make up for it.  */
        .long .LSTART_sigreturn-1-.     /* PC-relative start address */

But commit 69d0627a7f6e ("x86 vDSO: reorder vdso32 code") from 2.6.25
replaced .org __kernel_vsyscall+32,0x90 by ALIGN right before
__kernel_sigreturn.

Of course, ALIGN need not generate any NOP in there. Esp. gcc5 collapses
vclock_gettime.o and int80.o together with no generated NOPs as "ALIGN".

So fix this by adding to that point at least a single NOP and make the
function ALIGN possibly with more NOPs then.

Kudos for reporting and diagnosing should go to Richard.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5ce12fb22f347505600ec431f6ed78cc7abd93dc
Reported-by: Richard Biener <rguenther@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: <stable@vger.kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1425543211-12542-1-git-send-email-jslaby@suse.cz
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit ad927769865b3e162266faf215918d4f83f7bb84
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068363

[modify] https://crrev.com/b38d0b85e8bc4e82c0d9dc2ef4cdd6b11eeae12e/arch/x86/vdso/vdso32/sigreturn.S

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

commit f236fd44ef5ba1360aad085c5b7fca256243599b
Author: Daniel J Blueman <daniel@numascale.com>
Date: Wed May 23 04:56:35 2018

UPSTREAM: x86: numachip: Fix 16-bit APIC ID truncation

[ Upstream commit 00e7977dd1bbd46e336d7ef907d0fb6b6a4c294f ]

Prevent 16-bit APIC IDs being truncated by using correct mask. This fixes
booting large systems, where the wrong core would receive the startup and
init IPIs, causing hanging.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I071843dd2e7146d07af0fc1ae92d6d33e519668f
Signed-off-by: Daniel J Blueman <daniel@numascale.com>
Cc: Steffen Persvold <sp@numascale.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1415089784-28779-1-git-send-email-daniel@numascale.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit f8ac6343a34f407b237a7b7924f2182a1ddb7216
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068364

[modify] https://crrev.com/f236fd44ef5ba1360aad085c5b7fca256243599b/arch/x86/kernel/apic/apic_numachip.c

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

commit 20e309866caaee92cc8c28e56a070990615f5d52
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed May 23 16:12:16 2018

BACKPORT: x86/nmi/64: Fix a paravirt stack-clobbering bug in the NMI code

[ Upstream commit 83c133cf11fb0e68a51681447e372489f052d40e ]

The NMI entry code that switches to the normal kernel stack needs to
be very careful not to clobber any extra stack slots on the NMI
stack.  The code is fine under the assumption that SWAPGS is just a
normal instruction, but that assumption isn't really true.  Use
SWAPGS_UNSAFE_STACK instead.

This is part of a fix for some random crashes that Sasha saw.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Iee37483403d7f78c59328793815786465b2fe3f9
Fixes: 9b6e6a8334d5 ("x86/nmi/64: Switch stacks on userspace NMI entry")
Reported-and-tested-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/974bc40edffdb5c2950a5c4977f821a446b76178.1442791737.git.luto@kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit a70046a8f849fb1a98c5aee0c3504ddf61461eab
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: context conflict with 565ec1909b081e]
 Conflicts:
	arch/x86/kernel/entry_64.S
Reviewed-on: https://chromium-review.googlesource.com/1068415
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/20e309866caaee92cc8c28e56a070990615f5d52/arch/x86/kernel/entry_64.S

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

commit 3d35dd594d15838b95b938fc37179428c1de9227
Author: Steven Rostedt <rostedt@goodmis.org>
Date: Wed May 23 16:12:18 2018

UPSTREAM: x86: Init per-cpu shadow copy of CR4 on 32-bit CPUs too

[ Upstream commit 5b2bdbc84556774afbe11bcfd24c2f6411cfa92b ]

Commit:

   1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")

added a shadow CR4 such that reads and writes that do not
modify the CR4 execute much faster than always reading the
register itself.

The change modified cpu_init() in common.c, so that the
shadow CR4 gets initialized before anything uses it.

Unfortunately, there's two cpu_init()s in common.c. There's
one for 64-bit and one for 32-bit. The commit only added
the shadow init to the 64-bit path, but the 32-bit path
needs the init too.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: If9cd68dc843cf4ec34adf55ce2adf604c1020119
Link: http://lkml.kernel.org/r/20150227125208.71c36402@gandalf.local.home Fixes: 1e02ce4cccdc "x86: Store a per-cpu shadow copy of CR4"
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20150227145019.2bdd4354@gandalf.local.home
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 4534a1c432551e5588955a5eb8f6cb26c69b047f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068416

[modify] https://crrev.com/3d35dd594d15838b95b938fc37179428c1de9227/arch/x86/kernel/cpu/common.c

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

commit 5a61cd1f3312a586e5447270fbc1c6f0100baf03
Author: Eric Northup <digitaleric@google.com>
Date: Wed May 23 16:12:19 2018

UPSTREAM: KVM: x86: work around infinite loop in microcode when #AC is delivered

[ Upstream commit 54a20552e1eae07aa240fa370a0293e006b5faed ]

It was found that a guest can DoS a host by triggering an infinite
stream of "alignment check" (#AC) exceptions.  This causes the
microcode to enter an infinite loop where the core never receives
another interrupt.  The host kernel panics pretty quickly due to the
effects (CVE-2015-5307).

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ice849029041513fbb516d815dca03736de9c458a
Signed-off-by: Eric Northup <digitaleric@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 79e62de2efb2f586726e46342c792360a9644319
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068417

[modify] https://crrev.com/5a61cd1f3312a586e5447270fbc1c6f0100baf03/arch/x86/kvm/svm.c
[modify] https://crrev.com/5a61cd1f3312a586e5447270fbc1c6f0100baf03/arch/x86/include/uapi/asm/svm.h
[modify] https://crrev.com/5a61cd1f3312a586e5447270fbc1c6f0100baf03/arch/x86/kvm/vmx.c

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

commit 3575023b0718f408be90516b999f2c7ca1f4851f
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Wed May 23 16:12:21 2018

UPSTREAM: KVM: x86: Use new is_noncanonical_address in _linearize

[ Upstream commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 ]

Replace the current canonical address check with the new function which is
identical.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I289a4d67acd41764231b5642878a57cdb29fc162
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 5b4df4648d73b9794f2a15f75ebb43d609d72694
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068418

[modify] https://crrev.com/3575023b0718f408be90516b999f2c7ca1f4851f/arch/x86/kvm/emulate.c

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

commit 808a47cd1e33005c6ddcb47353505ddd6baa639c
Author: Matt Fleming <matt@codeblueprint.co.uk>
Date: Wed May 23 16:12:23 2018

UPSTREAM: x86/mm/pat: Avoid truncation when converting cpa->numpages to address

[ Upstream commit 742563777e8da62197d6cb4b99f4027f59454735 ]

There are a couple of nasty truncation bugs lurking in the pageattr
code that can be triggered when mapping EFI regions, e.g. when we pass
a cpa->pgd pointer. Because cpa->numpages is a 32-bit value, shifting
left by PAGE_SHIFT will truncate the resultant address to 32-bits.

Viorel-Ctlin managed to trigger this bug on his Dell machine that
provides a ~5GB EFI region which requires 1236992 pages to be mapped.
When calling populate_pud() the end of the region gets calculated
incorrectly in the following buggy expression,

  end = start + (cpa->numpages << PAGE_SHIFT);

And only 188416 pages are mapped. Next, populate_pud() gets invoked
for a second time because of the loop in __change_page_attr_set_clr(),
only this time no pages get mapped because shifting the remaining
number of pages (1048576) by PAGE_SHIFT is zero. At which point the
loop in __change_page_attr_set_clr() spins forever because we fail to
map progress.

Hitting this bug depends very much on the virtual address we pick to
map the large region at and how many pages we map on the initial run
through the loop. This explains why this issue was only recently hit
with the introduction of commit

  a5caa209ba9c ("x86/efi: Fix boot crash by mapping EFI memmap
   entries bottom-up at runtime, instead of top-down")

It's interesting to note that safe uses of cpa->numpages do exist in
the pageattr code. If instead of shifting ->numpages we multiply by
PAGE_SIZE, no truncation occurs because PAGE_SIZE is a UL value, and
so the result is unsigned long.

To avoid surprises when users try to convert very large cpa->numpages
values to addresses, change the data type from 'int' to 'unsigned
long', thereby making it suitable for shifting by PAGE_SHIFT without
any type casting.

The alternative would be to make liberal use of casting, but that is
far more likely to cause problems in the future when someone adds more
code and fails to cast properly; this bug was difficult enough to
track down in the first place.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Icbd28e9fb261b4bdf5f74d49d79e9742459bd11e
Reported-and-tested-by: Viorel-Ctlin Rpieanu <rapiteanu.catalin@gmail.com>
Acked-by: Borislav Petkov <bp@alien8.de>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=110131
Link: http://lkml.kernel.org/r/1454067370-10374-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit ec118360037fdd1c370263d0e618b1541420d0f0
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068419

[modify] https://crrev.com/808a47cd1e33005c6ddcb47353505ddd6baa639c/arch/x86/mm/pageattr.c

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

commit 7fbd46f7eac3e79feb91350f74ab830f6accac0b
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed May 23 16:12:24 2018

UPSTREAM: x86/entry/compat: Add missing CLAC to entry_INT80_32

commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa upstream.

This doesn't seem to fix a regression -- I don't think the CLAC was
ever there.

I double-checked in a debugger: entries through the int80 gate do
not automatically clear AC.

Stable maintainers: I can provide a backport to 4.3 and earlier if
needed.  This needs to be backported all the way to 3.10.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I142a4451d26e9480c22bcc497f0ef25e0f8b725f
Reported-by: Brian Gerst <brgerst@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org> # v3.10 and later
Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access")
Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ kamal: backport to 3.10 through 3.19-stable: file rename; context ]
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 06a0f04fa071ac532f619959c6e908bb7e313852
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068420

[modify] https://crrev.com/7fbd46f7eac3e79feb91350f74ab830f6accac0b/arch/x86/ia32/ia32entry.S

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

commit 5cbea2aa2740fccf9e40854933acbd35f569ac76
Author: Mike Krinkin <krinkin.m.u@gmail.com>
Date: Wed May 23 16:12:26 2018

UPSTREAM: KVM: x86: MMU: fix ubsan index-out-of-range warning

[ Upstream commit 17e4bce0ae63c7e03f3c7fa8d80890e7af3d4971 ]

Ubsan reports the following warning due to a typo in
update_accessed_dirty_bits template, the patch fixes
the typo:

[  168.791851] ================================================================================
[  168.791862] UBSAN: Undefined behaviour in arch/x86/kvm/paging_tmpl.h:252:15
[  168.791866] index 4 is out of range for type 'u64 [4]'
[  168.791871] CPU: 0 PID: 2950 Comm: qemu-system-x86 Tainted: G           O L  4.5.0-rc5-next-20160222 #7
[  168.791873] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  168.791876]  0000000000000000 ffff8801cfcaf208 ffffffff81c9f780 0000000041b58ab3
[  168.791882]  ffffffff82eb2cc1 ffffffff81c9f6b4 ffff8801cfcaf230 ffff8801cfcaf1e0
[  168.791886]  0000000000000004 0000000000000001 0000000000000000 ffffffffa1981600
[  168.791891] Call Trace:
[  168.791899]  [<ffffffff81c9f780>] dump_stack+0xcc/0x12c
[  168.791904]  [<ffffffff81c9f6b4>] ? _atomic_dec_and_lock+0xc4/0xc4
[  168.791910]  [<ffffffff81da9e81>] ubsan_epilogue+0xd/0x8a
[  168.791914]  [<ffffffff81daafa2>] __ubsan_handle_out_of_bounds+0x15c/0x1a3
[  168.791918]  [<ffffffff81daae46>] ? __ubsan_handle_shift_out_of_bounds+0x2bd/0x2bd
[  168.791922]  [<ffffffff811287ef>] ? get_user_pages_fast+0x2bf/0x360
[  168.791954]  [<ffffffffa1794050>] ? kvm_largepages_enabled+0x30/0x30 [kvm]
[  168.791958]  [<ffffffff81128530>] ? __get_user_pages_fast+0x360/0x360
[  168.791987]  [<ffffffffa181b818>] paging64_walk_addr_generic+0x1b28/0x2600 [kvm]
[  168.792014]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[  168.792019]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[  168.792044]  [<ffffffffa1819cf0>] ? init_kvm_mmu+0x1100/0x1100 [kvm]
[  168.792076]  [<ffffffffa181c36d>] paging64_gva_to_gpa+0x7d/0x110 [kvm]
[  168.792121]  [<ffffffffa181c2f0>] ? paging64_walk_addr_generic+0x2600/0x2600 [kvm]
[  168.792130]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[  168.792178]  [<ffffffffa17d9a4a>] emulator_read_write_onepage+0x27a/0x1150 [kvm]
[  168.792208]  [<ffffffffa1794d44>] ? __kvm_read_guest_page+0x54/0x70 [kvm]
[  168.792234]  [<ffffffffa17d97d0>] ? kvm_task_switch+0x160/0x160 [kvm]
[  168.792238]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[  168.792263]  [<ffffffffa17daa07>] emulator_read_write+0xe7/0x6d0 [kvm]
[  168.792290]  [<ffffffffa183b620>] ? em_cr_write+0x230/0x230 [kvm]
[  168.792314]  [<ffffffffa17db005>] emulator_write_emulated+0x15/0x20 [kvm]
[  168.792340]  [<ffffffffa18465f8>] segmented_write+0xf8/0x130 [kvm]
[  168.792367]  [<ffffffffa1846500>] ? em_lgdt+0x20/0x20 [kvm]
[  168.792374]  [<ffffffffa14db512>] ? vmx_read_guest_seg_ar+0x42/0x1e0 [kvm_intel]
[  168.792400]  [<ffffffffa1846d82>] writeback+0x3f2/0x700 [kvm]
[  168.792424]  [<ffffffffa1846990>] ? em_sidt+0xa0/0xa0 [kvm]
[  168.792449]  [<ffffffffa185554d>] ? x86_decode_insn+0x1b3d/0x4f70 [kvm]
[  168.792474]  [<ffffffffa1859032>] x86_emulate_insn+0x572/0x3010 [kvm]
[  168.792499]  [<ffffffffa17e71dd>] x86_emulate_instruction+0x3bd/0x2110 [kvm]
[  168.792524]  [<ffffffffa17e6e20>] ? reexecute_instruction.part.110+0x2e0/0x2e0 [kvm]
[  168.792532]  [<ffffffffa14e9a81>] handle_ept_misconfig+0x61/0x460 [kvm_intel]
[  168.792539]  [<ffffffffa14e9a20>] ? handle_pause+0x450/0x450 [kvm_intel]
[  168.792546]  [<ffffffffa15130ea>] vmx_handle_exit+0xd6a/0x1ad0 [kvm_intel]
[  168.792572]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[  168.792597]  [<ffffffffa17f6bcd>] kvm_arch_vcpu_ioctl_run+0xd3d/0x6090 [kvm]
[  168.792621]  [<ffffffffa17f6a6c>] ? kvm_arch_vcpu_ioctl_run+0xbdc/0x6090 [kvm]
[  168.792627]  [<ffffffff8293b530>] ? __ww_mutex_lock_interruptible+0x1630/0x1630
[  168.792651]  [<ffffffffa17f5e90>] ? kvm_arch_vcpu_runnable+0x4f0/0x4f0 [kvm]
[  168.792656]  [<ffffffff811eeb30>] ? preempt_notifier_unregister+0x190/0x190
[  168.792681]  [<ffffffffa17e0447>] ? kvm_arch_vcpu_load+0x127/0x650 [kvm]
[  168.792704]  [<ffffffffa178e9a3>] kvm_vcpu_ioctl+0x553/0xda0 [kvm]
[  168.792727]  [<ffffffffa178e450>] ? vcpu_put+0x40/0x40 [kvm]
[  168.792732]  [<ffffffff8129e350>] ? debug_check_no_locks_freed+0x350/0x350
[  168.792735]  [<ffffffff82946087>] ? _raw_spin_unlock+0x27/0x40
[  168.792740]  [<ffffffff8163a943>] ? handle_mm_fault+0x1673/0x2e40
[  168.792744]  [<ffffffff8129daa8>] ? trace_hardirqs_on_caller+0x478/0x6c0
[  168.792747]  [<ffffffff8129dcfd>] ? trace_hardirqs_on+0xd/0x10
[  168.792751]  [<ffffffff812e848b>] ? debug_lockdep_rcu_enabled+0x7b/0x90
[  168.792756]  [<ffffffff81725a80>] do_vfs_ioctl+0x1b0/0x12b0
[  168.792759]  [<ffffffff817258d0>] ? ioctl_preallocate+0x210/0x210
[  168.792763]  [<ffffffff8174aef3>] ? __fget+0x273/0x4a0
[  168.792766]  [<ffffffff8174acd0>] ? __fget+0x50/0x4a0
[  168.792770]  [<ffffffff8174b1f6>] ? __fget_light+0x96/0x2b0
[  168.792773]  [<ffffffff81726bf9>] SyS_ioctl+0x79/0x90
[  168.792777]  [<ffffffff82946880>] entry_SYSCALL_64_fastpath+0x23/0xc1
[  168.792780] ================================================================================

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I0a7741b6cdebe25db92bb84afd175d35bfb16da9
Signed-off-by: Mike Krinkin <krinkin.m.u@gmail.com>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 38973f72a668e864dde5a740a92a503b4bbd5c5f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068421

[modify] https://crrev.com/5cbea2aa2740fccf9e40854933acbd35f569ac76/arch/x86/kvm/paging_tmpl.h

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

commit c9c2137875c57695a1f6326f2b5058192be37180
Author: Todd E Brandt <todd.e.brandt@linux.intel.com>
Date: Wed May 23 16:12:27 2018

UPSTREAM: PM / sleep / x86: Fix crash on graph trace through x86 suspend

[ Upstream commit 92f9e179a702a6adbc11e2fedc76ecd6ffc9e3f7 ]

Pause/unpause graph tracing around do_suspend_lowlevel as it has
inconsistent call/return info after it jumps to the wakeup vector.
The graph trace buffer will otherwise become misaligned and
may eventually crash and hang on suspend.

To reproduce the issue and test the fix:
Run a function_graph trace over suspend/resume and set the graph
function to suspend_devices_and_enter. This consistently hangs the
system without this fix.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I20a1fd5291abce2037e465e0894575fda723faa4
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit d9b930d53bfdefab2d8a55a5bd584bdea8e23fd6
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068422

[modify] https://crrev.com/c9c2137875c57695a1f6326f2b5058192be37180/arch/x86/kernel/acpi/sleep.c

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

commit 7969f4e9460568f385ca09416ebdaa2c4cd44afe
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date: Wed May 23 16:12:29 2018

UPSTREAM: KVM: x86: move steal time initialization to vcpu entry time

[ Upstream commit 7cae2bedcbd4680b155999655e49c27b9cf020fa ]

As reported at https://bugs.launchpad.net/qemu/+bug/1494350,
it is possible to have vcpu->arch.st.last_steal initialized
from a thread other than vcpu thread, say the iothread, via
KVM_SET_MSRS.

Which can cause an overflow later (when subtracting from vcpu threads
sched_info.run_delay).

To avoid that, move steal time accumulation to vcpu entry time,
before copying steal time data to guest.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ifd00a1ebaade537c3974db9554ef644014a7d39f
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit e5aa9bc4adeca95a3858e14ac5d1698efefa737d
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068423

[modify] https://crrev.com/7969f4e9460568f385ca09416ebdaa2c4cd44afe/arch/x86/kvm/x86.c

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

commit d1fc8c05f9a1cdb1179a61d614fd872dcf5d78a9
Author: Radim Krčmář <rkrcmar@redhat.com>
Date: Wed May 23 16:12:30 2018

UPSTREAM: KVM: VMX: disable PEBS before a guest entry

[ Upstream commit 7099e2e1f4d9051f31bbfa5803adf954bb5d76ef ]

Linux guests on Haswell (and also SandyBridge and Broadwell, at least)
would crash if you decided to run a host command that uses PEBS, like
  perf record -e 'cpu/mem-stores/pp' -a

This happens because KVM is using VMX MSR switching to disable PEBS, but
SDM [2015-12] 18.4.4.4 Re-configuring PEBS Facilities explains why it
isn't safe:
  When software needs to reconfigure PEBS facilities, it should allow a
  quiescent period between stopping the prior event counting and setting
  up a new PEBS event. The quiescent period is to allow any latent
  residual PEBS records to complete its capture at their previously
  specified buffer address (provided by IA32_DS_AREA).

There might not be a quiescent period after the MSR switch, so a CPU
ends up using host's MSR_IA32_DS_AREA to access an area in guest's
memory.  (Or MSR switching is just buggy on some models.)

The guest can learn something about the host this way:
If the guest doesn't map address pointed by MSR_IA32_DS_AREA, it results
in #PF where we leak host's MSR_IA32_DS_AREA through CR2.

After that, a malicious guest can map and configure memory where
MSR_IA32_DS_AREA is pointing and can therefore get an output from
host's tracing.

This is not a critical leak as the host must initiate with PEBS tracing
and I have not been able to get a record from more than one instruction
before vmentry in vmx_vcpu_run() (that place has most registers already
overwritten with guest's).

We could disable PEBS just few instructions before vmentry, but
disabling it earlier shouldn't affect host tracing too much.
We also don't need to switch MSR_IA32_PEBS_ENABLE on VMENTRY, but that
optimization isn't worth its code, IMO.

(If you are implementing PEBS for guests, be sure to handle the case
 where both host and guest enable PEBS, because this patch doesn't.)

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ibc9a6604b3a17fde5bea0f91244f7827b82c9495
Fixes: 26a4f3c08de4 ("perf/x86: disable PEBS on a guest entry.")
Cc: <stable@vger.kernel.org>
Reported-by: Ji Ola <jolsa@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 306cc4da64fe0782ab5a984e888e7476be268d6d
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068424

[modify] https://crrev.com/d1fc8c05f9a1cdb1179a61d614fd872dcf5d78a9/arch/x86/kvm/vmx.c

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

commit 8be4b1896f59bfe581877973df98c1ed1c4e7993
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed May 23 16:12:32 2018

UPSTREAM: x86/iopl/64: Properly context-switch IOPL on Xen PV

commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.

On Xen PV, regs->flags doesn't reliably reflect IOPL and the
exit-to-userspace code doesn't change IOPL.  We need to context
switch it manually.

I'm doing this without going through paravirt because this is
specific to Xen PV.  After the dust settles, we can merge this with
the 32-bit code, tidy up the iopl syscall implementation, and remove
the set_iopl pvop entirely.

Fixes XSA-171.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I3f7ca4382df15303f5c65c102a3a872e23d35ed6
Reviewewd-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
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: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[ kamal: backport to 3.19-stable: no X86_FEATURE_XENPV so just call
  xen_pv_domain() directly ]
Acked-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 9dac025573bbde6e69bd2238b803cdd4d881d83b
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068425

[modify] https://crrev.com/8be4b1896f59bfe581877973df98c1ed1c4e7993/arch/x86/include/asm/xen/hypervisor.h
[modify] https://crrev.com/8be4b1896f59bfe581877973df98c1ed1c4e7993/arch/x86/kernel/process_64.c
[modify] https://crrev.com/8be4b1896f59bfe581877973df98c1ed1c4e7993/arch/x86/xen/enlighten.c

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

commit 85396409538056243bd5279f92bd6925bebe9934
Author: Andrew Honig <ahonig@google.com>
Date: Wed May 23 16:12:34 2018

UPSTREAM: KVM: x86: Reload pit counters for all channels when restoring state

[ Upstream commit 0185604c2d82c560dab2f2933a18f797e74ab5a8 ]

Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash.  This will ensure
that 0 values are converted to 65536 as per the spec.

This is CVE-2015-7513.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I08cb49ee5feef0b471289965fc58aa89951db51c
Signed-off-by: Andy Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 8dc1d26b1bae170d1d11e6460cf745ef10d90bfd
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068426

[modify] https://crrev.com/85396409538056243bd5279f92bd6925bebe9934/arch/x86/kvm/x86.c

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

commit 518798de1e8882382f2cbd59fa036026e63e5dda
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Wed May 23 16:12:35 2018

UPSTREAM: x86, irq: Keep balance of IOAPIC pin reference count

[ Upstream commit cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ]

To keep balance of IOAPIC pin reference count, we need to protect
pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
from reentrance. There are two cases which will cause reentrance.

The first case is caused by suspend/hibernation. If pcibios_disable_irq
is called during suspending/hibernating, we don't release the assigned
IRQ number, otherwise it may break the suspend/hibernation. So late when
pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
number again.

The second case is that function acpi_pci_irq_enable() may be called
twice for PCI devices present at boot time as below:
1) pci_acpi_init()
	--> acpi_pci_irq_enable() if pci_routeirq is true
2) pci_enable_device()
	--> pcibios_enable_device()
		--> acpi_pci_irq_enable()
We can't kill kernel parameter pci_routeirq yet because it's still
needed for debugging purpose.

So flag irq_managed is introduced to track whether IRQ number is
assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
and intel_mid_pci_irq_enable() from reentrance.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Id4a1c0fda58cd0fee12061dfd4735b380aeae231
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit ec5e2836d844e57bfe26640c998f62678c415ac6
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068427

[modify] https://crrev.com/518798de1e8882382f2cbd59fa036026e63e5dda/drivers/acpi/pci_irq.c
[modify] https://crrev.com/518798de1e8882382f2cbd59fa036026e63e5dda/arch/x86/pci/intel_mid_pci.c
[modify] https://crrev.com/518798de1e8882382f2cbd59fa036026e63e5dda/arch/x86/pci/irq.c
[modify] https://crrev.com/518798de1e8882382f2cbd59fa036026e63e5dda/include/linux/pci.h

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

commit d52fe302ad96eb9f27afdb82be4e9b8e75d09575
Author: Radim Krčmář <rkrcmar@redhat.com>
Date: Wed May 23 16:12:37 2018

UPSTREAM: KVM: i8254: change PIT discard tick policy

[ Upstream commit 7dd0fdff145c5be7146d0ac06732ae3613412ac1 ]

Discard policy uses ack_notifiers to prevent injection of PIT interrupts
before EOI from the last one.

This patch changes the policy to always try to deliver the interrupt,
which makes a difference when its vector is in ISR.
Old implementation would drop the interrupt, but proposed one injects to
IRR, like real hardware would.

The old policy breaks legacy NMI watchdogs, where PIT is used through
virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
thus a guest deadlock with disabled interrupts will stop NMIs.

Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
through IOAPIC.  (KVM's PIT is deeply rotten and luckily not used much
in modern systems.)

Even though there is a chance of regressions, I think we can fix the
LVT0 NMI bug without introducing a new tick policy.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie69fffee527c882b21e3045d97f4df67d10afeb5
Cc: <stable@vger.kernel.org>
Reported-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 948536bf4148ad08cc2d87aedde1ab97ff3d5291
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068428

[modify] https://crrev.com/d52fe302ad96eb9f27afdb82be4e9b8e75d09575/arch/x86/kvm/i8254.c

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

commit 31dfe548ccf2619e2976e1f6c5ff363e64a68251
Author: Stephane Eranian <eranian@google.com>
Date: Wed May 23 16:12:39 2018

UPSTREAM: perf/x86/intel: Add definition for PT PMI bit

[ Upstream commit 5690ae28e472d25e330ad0c637a5cea3fc39fb32 ]

This patch adds a definition for GLOBAL_OVFL_STATUS bit 55
which is used with the Processor Trace (PT) feature.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Id281a35cfac131252ec0c0d3bcd924dc08a2c297
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: adrian.hunter@intel.com
Cc: kan.liang@intel.com
Cc: namhyung@kernel.org
Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 1011e8d090703e119111809f7550c8453d572444
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068429

[modify] https://crrev.com/31dfe548ccf2619e2976e1f6c5ff363e64a68251/arch/x86/include/asm/perf_event.h

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

commit f329069e85fcbd9766177d0c745f0d1db916feda
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed May 23 16:12:40 2018

UPSTREAM: x86/iopl: Fix iopl capability check on Xen PV

[ Upstream commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e ]

iopl(3) is supposed to work if iopl is already 3, even if
unprivileged.  This didn't work right on Xen PV.  Fix it.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I015a8e48f4531b8d82a09daf4bd9f1f2d428313d
Reviewewd-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
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: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 9c6167f2e64c024b1e9b8ee2e484599c33352a9c
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068430

[modify] https://crrev.com/f329069e85fcbd9766177d0c745f0d1db916feda/arch/x86/kernel/ioport.c

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

commit 536e6a8cd9f9ed51cd34d3b6421ad892bd8af1d5
Author: Dave Jones <davej@codemonkey.org.uk>
Date: Wed May 23 16:12:42 2018

UPSTREAM: x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()

[ Upstream commit 7834c10313fb823e538f2772be78edcdeed2e6e3 ]

Since 4.4, I've been able to trigger this occasionally:

===============================
[ INFO: suspicious RCU usage. ]
4.5.0-rc7-think+ #3 Not tainted
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

-------------------------------
./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/3/0.

stack backtrace:
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
 ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
 ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
 ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
Call Trace:
 <IRQ>  [<ffffffff92560c2a>] dump_stack+0x67/0x9d
 [<ffffffff921376a6>] lockdep_rcu_suspicious+0xe6/0x100
 [<ffffffff925ae7a7>] do_trace_write_msr+0x127/0x1a0
 [<ffffffff92061c83>] native_apic_msr_eoi_write+0x23/0x30
 [<ffffffff92054408>] smp_trace_call_function_interrupt+0x38/0x360
 [<ffffffff92d1ca60>] trace_call_function_interrupt+0x90/0xa0
 <EOI>  [<ffffffff92ac5124>] ? cpuidle_enter_state+0x1b4/0x520

Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
tells the RCU susbstems to end the extended quiescent state, so that the
following trace call in ack_APIC_irq() works correctly.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ib22e1d7a692fbeda66611185476028d0cae73a42
Suggested-by: Andi Kleen <ak@linux.intel.com>
Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 3496f12f95df9beb21e79dee3a78a704b0951187
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068431

[modify] https://crrev.com/536e6a8cd9f9ed51cd34d3b6421ad892bd8af1d5/arch/x86/include/asm/apic.h

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

commit a5a0ae11c78a0f8ba8127ac87bfffe39b0e8807f
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 16:12:44 2018

UPSTREAM: KVM: VMX: avoid guest hang on invalid invept instruction

[ Upstream commit 2849eb4f99d54925c543db12917127f88b3c38ff ]

A guest executing an invalid invept instruction would hang
because the instruction pointer was not updated.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I1cee71c4273d0454140ea4742e65b0dd00e3f2df
Cc: stable@vger.kernel.org
Fixes: bfd0a56b90005f8c8a004baf407ad90045c2b11e
Reviewed-by: David Matlack <dmatlack@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 7aae44c91487a1f7210a1fb7e3ed608f6f6ef653
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068432

[modify] https://crrev.com/a5a0ae11c78a0f8ba8127ac87bfffe39b0e8807f/arch/x86/kvm/vmx.c

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

commit 7aae0ce394ea5c68dc7eec7080199af176cf3202
Author: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Date: Wed May 23 16:12:45 2018

UPSTREAM: KVM: x86: Inject pending interrupt even if pending nmi exist

[ Upstream commit 321c5658c5e9192dea0d58ab67cf1791e45b2b26 ]

Non maskable interrupts (NMI) are preferred to interrupts in current
implementation. If a NMI is pending and NMI is blocked by the result
of nmi_allowed(), pending interrupt is not injected and
enable_irq_window() is not executed, even if interrupts injection is
allowed.

In old kernel (e.g. 2.6.32), schedule() is often called in NMI context.
In this case, interrupts are needed to execute iret that intends end
of NMI. The flag of blocking new NMI is not cleared until the guest
execute the iret, and interrupts are blocked by pending NMI. Due to
this, iret can't be invoked in the guest, and the guest is starved
until block is cleared by some events (e.g. canceling injection).

This patch injects pending interrupts, when it's allowed, even if NMI
is blocked. And, If an interrupts is pending after executing
inject_pending_event(), enable_irq_window() is executed regardless of
NMI pending counter.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie3f652f50a4e9d9d52e4360f1244f5428b5305c2
Cc: stable@vger.kernel.org
Signed-off-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 1cbab78d2f11ad12efc8b61e2ae66f020f7b8ce1
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068433

[modify] https://crrev.com/7aae0ce394ea5c68dc7eec7080199af176cf3202/arch/x86/kvm/x86.c

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

commit 4eb04f76513451a6d55da9a9dbbaaea1cf0cc4da
Author: David Matlack <dmatlack@google.com>
Date: Wed May 23 16:12:47 2018

UPSTREAM: kvm: x86: do not leak guest xcr0 into host interrupt handlers

[ Upstream commit fc5b7f3bf1e1414bd4e91db6918c85ace0c873a5 ]

An interrupt handler that uses the fpu can kill a KVM VM, if it runs
under the following conditions:
 - the guest's xcr0 register is loaded on the cpu
 - the guest's fpu context is not loaded
 - the host is using eagerfpu

Note that the guest's xcr0 register and fpu context are not loaded as
part of the atomic world switch into "guest mode". They are loaded by
KVM while the cpu is still in "host mode".

Usage of the fpu in interrupt context is gated by irq_fpu_usable(). The
interrupt handler will look something like this:

if (irq_fpu_usable()) {
        kernel_fpu_begin();

        [... code that uses the fpu ...]

        kernel_fpu_end();
}

As long as the guest's fpu is not loaded and the host is using eager
fpu, irq_fpu_usable() returns true (interrupted_kernel_fpu_idle()
returns true). The interrupt handler proceeds to use the fpu with
the guest's xcr0 live.

kernel_fpu_begin() saves the current fpu context. If this uses
XSAVE[OPT], it may leave the xsave area in an undesirable state.
According to the SDM, during XSAVE bit i of XSTATE_BV is not modified
if bit i is 0 in xcr0. So it's possible that XSTATE_BV[i] == 1 and
xcr0[i] == 0 following an XSAVE.

kernel_fpu_end() restores the fpu context. Now if any bit i in
XSTATE_BV == 1 while xcr0[i] == 0, XRSTOR generates a #GP. The
fault is trapped and SIGSEGV is delivered to the current process.

Only pre-4.2 kernels appear to be vulnerable to this sequence of
events. Commit 653f52c ("kvm,x86: load guest FPU context more eagerly")
from 4.2 forces the guest's fpu to always be loaded on eagerfpu hosts.

This patch fixes the bug by keeping the host's xcr0 loaded outside
of the interrupts-disabled region where KVM switches into guest mode.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ib43e9dd38a4cad7bf88c5489696cf68926a89abf
Cc: stable@vger.kernel.org
Suggested-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: David Matlack <dmatlack@google.com>
[Move load after goto cancel_injection. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 9081260396898ff62cdbf1a829b290779f246c34
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068434

[modify] https://crrev.com/4eb04f76513451a6d55da9a9dbbaaea1cf0cc4da/arch/x86/kvm/x86.c

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

commit 6e9ae8342a4a5ec208361e58b2318ec3e558b639
Author: Xiaodong Liu <xiaodong.liu@intel.com>
Date: Wed May 23 16:12:49 2018

UPSTREAM: crypto: sha1-mb - use corrcet pointer while completing jobs

[ Upstream commit 0851561d9c965df086ef8a53f981f5f95a57c2c8 ]

In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used
when check and complete other jobs. If the memory of first completed req
is freed, while still completing other jobs in the func, kernel will
crash since NULL pointer is assigned to RIP.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ief89ef52bce35b43754cab88c8b596a43f83f478
Cc: <stable@vger.kernel.org>
Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 5630c73cc47a028e0d2c8ff298f73ba86226d4a3
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068435

[modify] https://crrev.com/6e9ae8342a4a5ec208361e58b2318ec3e558b639/arch/x86/crypto/sha-mb/sha1_mb.c

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

commit c955b4bfbfabaac5d1032cf6a4f2b67176ec1c70
Author: Jan Beulich <JBeulich@suse.com>
Date: Wed May 23 16:12:50 2018

UPSTREAM: x86/mm/xen: Suppress hugetlbfs in PV guests

[ Upstream commit 103f6112f253017d7062cd74d17f4a514ed4485c ]

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode: 0000 [#1] SMP
  ...
  RIP: e030:[<ffffffff811c333b>]  [<ffffffff811c333b>] remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [<ffffffff811c3415>] hugetlbfs_evict_inode+0x15/0x40
   [<ffffffff81167b3d>] evict+0xbd/0x1b0
   [<ffffffff8116514a>] __dentry_kill+0x19a/0x1f0
   [<ffffffff81165b0e>] dput+0x1fe/0x220
   [<ffffffff81150535>] __fput+0x155/0x200
   [<ffffffff81079fc0>] task_work_run+0x60/0xa0
   [<ffffffff81063510>] do_exit+0x160/0x400
   [<ffffffff810637eb>] do_group_exit+0x3b/0xa0
   [<ffffffff8106e8bd>] get_signal+0x1ed/0x470
   [<ffffffff8100f854>] do_signal+0x14/0x110
   [<ffffffff810030e9>] prepare_exit_to_usermode+0xe9/0xf0
   [<ffffffff814178a5>] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I04669811331433a1e005425969b9be9d38dcf71c
Reported-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
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: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Juergen Gross <JGross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: stable@vger.kernel.org
Cc: xen-devel <xen-devel@lists.xenproject.org>
Link: http://lkml.kernel.org/r/57188ED802000078000E431C@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 24b769352bd519d6d932ea070e295e8b13f43af8
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068436

[modify] https://crrev.com/c955b4bfbfabaac5d1032cf6a4f2b67176ec1c70/arch/x86/include/asm/hugetlb.h

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

commit ab2cfd35ce5aa21b7c3b1f55c775640fd8f78acd
Author: Wang YanQing <udknight@gmail.com>
Date: Wed May 23 16:12:52 2018

UPSTREAM: x86/sysfb_efi: Fix valid BAR address range check

[ Upstream commit c10fcb14c7afd6688c7b197a814358fecf244222 ]

The code for checking whether a BAR address range is valid will break
out of the loop when a start address of 0x0 is encountered.

This behaviour is wrong since by breaking out of the loop we may miss
the BAR that describes the EFI frame buffer in a later iteration.

Because of this bug I can't use video=efifb: boot parameter to get
efifb on my new ThinkPad E550 for my old linux system hard disk with
3.10 kernel. In 3.10, efifb is the only choice due to DRM/I915 not
supporting the GPU.

This patch also add a trivial optimization to break out after we find
the frame buffer address range without testing later BARs.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I839b6e3cb07716917ec8682e78147d4b7c89dcfc
Signed-off-by: Wang YanQing <udknight@gmail.com>
[ Rewrote changelog. ]
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Reviewed-by: Peter Jones <pjones@redhat.com>
Cc: <stable@vger.kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1462454061-21561-2-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 12de322789aabf55f41ce73eb5b6a5c33fc4313e
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068437

[modify] https://crrev.com/ab2cfd35ce5aa21b7c3b1f55c775640fd8f78acd/arch/x86/kernel/sysfb_efi.c

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

commit 7f597a3a42e98caa86fb4fcd5d6571471915e0da
Author: Kirill A. Shutemov <kirill@shutemov.name>
Date: Wed May 23 16:12:53 2018

UPSTREAM: mm: fix huge zero page accounting in smaps report

[ Upstream commit c164e038eee805147e95789dddb88ae3b3aca11c ]

As a small zero page, huge zero page should not be accounted in smaps
report as normal page.

For small pages we rely on vm_normal_page() to filter out zero page, but
vm_normal_page() is not designed to handle pmds.  We only get here due
hackish cast pmd to pte in smaps_pte_range() -- pte and pmd format is not
necessary compatible on each and every architecture.

Let's add separate codepath to handle pmds.  follow_trans_huge_pmd() will
detect huge zero page for us.

We would need pmd_dirty() helper to do this properly.  The patch adds it
to THP-enabled architectures which don't yet have one.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ibe6b1af850e7d09a01463e6ff941ae9d2d68f51e
[akpm@linux-foundation.org: use do_div to fix 32-bit build]
Signed-off-by: "Kirill A. Shutemov" <kirill@shutemov.name>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengwei Yin <yfw.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 20b97db882d78bedb7c66c40008bbd3a0d7edabd
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068438

[modify] https://crrev.com/7f597a3a42e98caa86fb4fcd5d6571471915e0da/arch/sparc/include/asm/pgtable_64.h
[modify] https://crrev.com/7f597a3a42e98caa86fb4fcd5d6571471915e0da/arch/arm64/include/asm/pgtable.h
[modify] https://crrev.com/7f597a3a42e98caa86fb4fcd5d6571471915e0da/arch/powerpc/include/asm/pgtable-ppc64.h
[modify] https://crrev.com/7f597a3a42e98caa86fb4fcd5d6571471915e0da/arch/x86/include/asm/pgtable.h
[modify] https://crrev.com/7f597a3a42e98caa86fb4fcd5d6571471915e0da/fs/proc/task_mmu.c

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

commit 2a215436f2783831b48dec11398d74df8822e3f3
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Wed May 23 16:12:55 2018

UPSTREAM: x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi

[ Upstream commit 8abb850a03a3a8b11a0e92949e5b99d9cc178e35 ]

Xen overrides __acpi_register_gsi and leaves __acpi_unregister_gsi as is.
That means, an IRQ allocated by acpi_register_gsi_xen_hvm() or
acpi_register_gsi_xen() will be freed by acpi_unregister_gsi_ioapic(),
which may cause undesired effects. So override __acpi_unregister_gsi to
NULL for safety.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: If692e9b5d497865e17b5a32f2b5b896e8774811e
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Tested-by: Sander Eikelenboom <linux@eikelenboom.it>
Cc: Tony Luck <tony.luck@intel.com>
Cc: xen-devel@lists.xenproject.org
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Graeme Gregory <graeme.gregory@linaro.org>
Cc: Lv Zheng <lv.zheng@intel.com>
Link: http://lkml.kernel.org/r/1421720467-7709-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 72895bf864d56ad4035f34b216b3344bb0fd6caa
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068439

[modify] https://crrev.com/2a215436f2783831b48dec11398d74df8822e3f3/arch/x86/include/asm/acpi.h
[modify] https://crrev.com/2a215436f2783831b48dec11398d74df8822e3f3/arch/x86/pci/xen.c

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

commit c0c5fa092ccfa4985b0bc4d68ae460649cbe1421
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Wed May 23 16:12:56 2018

UPSTREAM: xen/x86: actually allocate legacy interrupts on PV guests

[ Upstream commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 ]

b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Iae9ed526749d02635c218dc5901f3b4c7f94350e
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit baff1938adce472142447ba686c2bf84acfb1260
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068440

[modify] https://crrev.com/c0c5fa092ccfa4985b0bc4d68ae460649cbe1421/arch/x86/pci/xen.c

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

commit e249f94c24c24036126841be087b645f8d3586a4
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 16:12:58 2018

UPSTREAM: KVM: x86: fix OOPS after invalid KVM_SET_DEBUGREGS

[ Upstream commit d14bdb553f9196169f003058ae1cdabe514470e6 ]

MOV to DR6 or DR7 causes a #GP if an attempt is made to write a 1 to
any of bits 63:32.  However, this is not detected at KVM_SET_DEBUGREGS
time, and the next KVM_RUN oopses:

   general protection fault: 0000 [#1] SMP
   CPU: 2 PID: 14987 Comm: a.out Not tainted 4.4.9-300.fc23.x86_64 #1
   Hardware name: LENOVO 2325F51/2325F51, BIOS G2ET32WW (1.12 ) 05/30/2012
   [...]
   Call Trace:
    [<ffffffffa072c93d>] kvm_arch_vcpu_ioctl_run+0x141d/0x14e0 [kvm]
    [<ffffffffa071405d>] kvm_vcpu_ioctl+0x33d/0x620 [kvm]
    [<ffffffff81241648>] do_vfs_ioctl+0x298/0x480
    [<ffffffff812418a9>] SyS_ioctl+0x79/0x90
    [<ffffffff817a0f2e>] entry_SYSCALL_64_fastpath+0x12/0x71
   Code: 55 83 ff 07 48 89 e5 77 27 89 ff ff 24 fd 90 87 80 81 0f 23 fe 5d c3 0f 23 c6 5d c3 0f 23 ce 5d c3 0f 23 d6 5d c3 0f 23 de 5d c3 <0f> 23 f6 5d c3 0f 0b 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
   RIP  [<ffffffff810639eb>] native_set_debugreg+0x2b/0x40
    RSP <ffff88005836bd50>

Testcase (beautified/reduced from syzkaller output):

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <string.h>
    #include <stdint.h>
    #include <linux/kvm.h>
    #include <fcntl.h>
    #include <sys/ioctl.h>

    long r[8];

    int main()
    {
        struct kvm_debugregs dr = { 0 };

        r[2] = open("/dev/kvm", O_RDONLY);
        r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
        r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);

        memcpy(&dr,
               "\x5d\x6a\x6b\xe8\x57\x3b\x4b\x7e\xcf\x0d\xa1\x72"
               "\xa3\x4a\x29\x0c\xfc\x6d\x44\x00\xa7\x52\xc7\xd8"
               "\x00\xdb\x89\x9d\x78\xb5\x54\x6b\x6b\x13\x1c\xe9"
               "\x5e\xd3\x0e\x40\x6f\xb4\x66\xf7\x5b\xe3\x36\xcb",
               48);
        r[7] = ioctl(r[4], KVM_SET_DEBUGREGS, &dr);
        r[6] = ioctl(r[4], KVM_RUN, 0);
    }

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Idebf5ef05e969737a6966eee0e9aaafb0f51a7f8
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 26c6a77797c961c345b3d9c2be96f2cbde6276a1
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068441

[modify] https://crrev.com/e249f94c24c24036126841be087b645f8d3586a4/arch/x86/kvm/x86.c

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

commit 21f939fe91890bf3f6889a443f565111f584d58e
Author: H. Peter Anvin <hpa@zytor.com>
Date: Wed May 23 16:12:59 2018

UPSTREAM: x86, build: copy ldlinux.c32 to image.iso

[ Upstream commit 9c77679cadb118c0aa99e6f88533d91765a131ba ]

For newer versions of Syslinux, we need ldlinux.c32 in addition to
isolinux.bin to reside on the boot disk, so if the latter is found,
copy it, too, to the isoimage tree.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ib54b8e23aefaebaf53615050ec89811e73341fc8
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Linux Stable Tree <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit 2c34097fbfbcfdafca183139cc3524c4e29e27eb
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068442

[modify] https://crrev.com/21f939fe91890bf3f6889a443f565111f584d58e/arch/x86/boot/Makefile

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

commit b5403fe5c177fa8b09cc96131b0a0e1929ab804a
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed May 23 16:13:01 2018

UPSTREAM: kprobes/x86: Clear TF bit in fault on single-stepping

[ Upstream commit dcfc47248d3f7d28df6f531e6426b933de94370d ]

Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
the flags register in the case of a fault fixup on single-stepping.

If we put a kprobe on the instruction which caused a
page fault (e.g. actual mov instructions in copy_user_*),
that fault happens on the single-stepping buffer. In this
case, kprobes resets running instance so that the CPU can
retry execution on the original ip address.

However, current code forgets to reset the TF bit. Since this
fault happens with TF bit set for enabling single-stepping,
when it retries, it causes a debug exception and kprobes
can not handle it because it already reset itself.

On the most of x86-64 platform, it can be easily reproduced
by using kprobe tracer. E.g.

  # cd /sys/kernel/debug/tracing
  # echo p copy_user_enhanced_fast_string+5 > kprobe_events
  # echo 1 > events/kprobes/enable

And you'll see a kernel panic on do_debug(), since the debug
trap is not handled by kprobes.

To fix this problem, we just need to clear the TF bit when
resetting running kprobe.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I08a7e3e91157d541db1c28a14a8dea6d3729fe6b
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.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: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: systemtap@sourceware.org
Cc: stable@vger.kernel.org # All the way back to ancient kernels
Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
[ Updated the comments. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit cd6ec94ca6112389d6e893298271332cacc743a7
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068443

[modify] https://crrev.com/b5403fe5c177fa8b09cc96131b0a0e1929ab804a/arch/x86/kernel/kprobes/core.c

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

commit 1a91da8c58f843a98c54a4e2ec351539f1a97ee1
Author: Karol Herbst <nouveau@karolherbst.de>
Date: Wed May 23 16:13:03 2018

UPSTREAM: x86/mm/kmmio: Fix mmiotrace for hugepages

[ Upstream commit cfa52c0cfa4d727aa3e457bf29aeff296c528a08 ]

Because Linux might use bigger pages than the 4K pages to handle those mmio
ioremaps, the kmmio code shouldn't rely on the pade id as it currently does.

Using the memory address instead of the page id lets us look up how big the
page is and what its base address is, so that we won't get a page fault
within the same page twice anymore.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5c4ae86943b23d5579870344e9e2f82b775a73d9
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
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: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Luis R. Rodriguez <mcgrof@suse.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: linux-mm@kvack.org
Cc: linux-x86_64@vger.kernel.org
Cc: nouveau@lists.freedesktop.org
Cc: pq@iki.fi
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1456966991-6861-1-git-send-email-nouveau@karolherbst.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
(cherry picked from commit c02c72265e3730b64c785df1e9e4d9270326abcd
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068444

[modify] https://crrev.com/1a91da8c58f843a98c54a4e2ec351539f1a97ee1/arch/x86/mm/kmmio.c

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

commit 1ab6f5dee6e42c0c1652a27a4d7436616e99a161
Author: Borislav Petkov <bp@suse.de>
Date: Wed May 23 16:13:04 2018

UPSTREAM: x86/amd_nb: Fix boot crash on non-AMD systems

[ Upstream commit 1ead852dd88779eda12cb09cc894a03d9abfe1ec ]

Fix boot crash that triggers if this driver is built into a kernel and
run on non-AMD systems.

AMD northbridges users call amd_cache_northbridges() and it returns
a negative value to signal that we weren't able to cache/detect any
northbridges on the system.

At least, it should do so as all its callers expect it to do so. But it
does return a negative value only when kmalloc() fails.

Fix it to return -ENODEV if there are no NBs cached as otherwise, amd_nb
users like amd64_edac, for example, which relies on it to know whether
it should load or not, gets loaded on systems like Intel Xeons where it
shouldn't.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ia967a701c7a0fc1203c273350102a6abca0b00aa
Reported-and-tested-by: Tony Battersby <tonyb@cybernetics.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1466097230-5333-2-git-send-email-bp@alien8.de
Link: https://lkml.kernel.org/r/5761BEB0.9000807@cybernetics.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 82736d510a43d7362f0899f7cc61429f0b342647
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068445

[modify] https://crrev.com/1ab6f5dee6e42c0c1652a27a4d7436616e99a161/arch/x86/kernel/amd_nb.c

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

commit e65bcfdef0f09d78dd110c3a1f305edc8d2902f9
Author: Lukas Wunner <lukas@wunner.de>
Date: Wed May 23 16:13:06 2018

UPSTREAM: x86/quirks: Add early quirk to reset Apple AirPort card

[ Upstream commit abb2bafd295fe962bbadc329dbfb2146457283ac ]

The EFI firmware on Macs contains a full-fledged network stack for
downloading OS X images from osrecovery.apple.com. Unfortunately
on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331
wireless card on every boot and leaves it enabled even after
ExitBootServices has been called. The card continues to assert its IRQ
line, causing spurious interrupts if the IRQ is shared. It also corrupts
memory by DMAing received packets, allowing for remote code execution
over the air. This only stops when a driver is loaded for the wireless
card, which may be never if the driver is not installed or blacklisted.

The issue seems to be constrained to the Broadcom 4331. Chris Milsted
has verified that the newer Broadcom 4360 built into the MacBookPro11,3
(2013/2014) does not exhibit this behaviour. The chances that Apple will
ever supply a firmware fix for the older machines appear to be zero.

The solution is to reset the card on boot by writing to a reset bit in
its mmio space. This must be done as an early quirk and not as a plain
vanilla PCI quirk to successfully combat memory corruption by DMAed
packets: Matthew Garrett found out in 2012 that the packets are written
to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
This type of memory is made available to the page allocator by
efi_free_boot_services(). Plain vanilla PCI quirks run much later, in
subsys initcall level. In-between a time window would be open for memory
corruption. Random crashes occurring in this time window and attributed
to DMAed packets have indeed been observed in the wild by Chris
Bainbridge.

When Matthew Garrett analyzed the memory corruption issue in 2012, he
sought to fix it with a grub quirk which transitions the card to D3hot:
http://git.savannah.gnu.org/cgit/grub.git/commit/?id=9d34bb85da56

This approach does not help users with other bootloaders and while it
may prevent DMAed packets, it does not cure the spurious interrupts
emanating from the card. Unfortunately the card's mmio space is
inaccessible in D3hot, so to reset it, we have to undo the effect of
Matthew's grub patch and transition the card back to D0.

Note that the quirk takes a few shortcuts to reduce the amount of code:
The size of BAR 0 and the location of the PM capability is identical
on all affected machines and therefore hardcoded. Only the address of
BAR 0 differs between models. Also, it is assumed that the BCMA core
currently mapped is the 802.11 core. The EFI driver seems to always take
care of this.

Michael Bsch, Bjorn Helgaas and Matt Fleming contributed feedback
towards finding the best solution to this problem.

The following should be a comprehensive list of affected models:
    iMac13,1        2012  21.5"       [Root Port 00:1c.3 = 8086:1e16]
    iMac13,2        2012  27"         [Root Port 00:1c.3 = 8086:1e16]
    Macmini5,1      2011  i5 2.3 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,2      2011  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini5,3      2011  i7 2.0 GHz  [Root Port 00:1c.1 = 8086:1c12]
    Macmini6,1      2012  i5 2.5 GHz  [Root Port 00:1c.1 = 8086:1e12]
    Macmini6,2      2012  i7 2.3 GHz  [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro8,1   2011  13"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,2   2011  15"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro8,3   2011  17"         [Root Port 00:1c.1 = 8086:1c12]
    MacBookPro9,1   2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro9,2   2012  13"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,1  2012  15"         [Root Port 00:1c.1 = 8086:1e12]
    MacBookPro10,2  2012  13"         [Root Port 00:1c.1 = 8086:1e12]

For posterity, spurious interrupts caused by the Broadcom 4331 wireless
card resulted in splats like this (stacktrace omitted):

    irq 17: nobody cared (try booting with the "irqpoll" option)
    handlers:
    [<ffffffff81374370>] pcie_isr
    [<ffffffffc0704550>] sdhci_irq [sdhci] threaded [<ffffffffc07013c0>] sdhci_thread_irq [sdhci]
    [<ffffffffc0a0b960>] azx_interrupt [snd_hda_codec]
    Disabling IRQ #17

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic3fa7a0085a13c904c4d08715f8be19739858104
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79301
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111781
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=728916
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=895951#c16
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1009819
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1098621
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1149632#c5
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1279130
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1332732
Tested-by: Konstantin Simanov <k.simanov@stlk.ru>        # [MacBookPro8,1]
Tested-by: Lukas Wunner <lukas@wunner.de>                # [MacBookPro9,1]
Tested-by: Bryan Paradis <bryan.paradis@gmail.com>       # [MacBookPro9,2]
Tested-by: Andrew Worsley <amworsley@gmail.com>          # [MacBookPro10,1]
Tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> # [MacBookPro10,2]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Rafa Miecki <zajec5@gmail.com>
Acked-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chris Milsted <cmilsted@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Michael Buesch <m@bues.ch>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: b43-dev@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: stable@vger.kernel.org
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Apply nvidia_bugs quirk only on root bus
Cc: stable@vger.kernel.org # 123456789abc: x86/quirks: Reintroduce scanning of secondary buses
Link: http://lkml.kernel.org/r/48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de
[ Did minor readability edits. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 26c5fd38db944f152851ce64f25af0c00dea0d26
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068446

[modify] https://crrev.com/e65bcfdef0f09d78dd110c3a1f305edc8d2902f9/drivers/bcma/bcma_private.h
[modify] https://crrev.com/e65bcfdef0f09d78dd110c3a1f305edc8d2902f9/include/linux/bcma/bcma.h
[modify] https://crrev.com/e65bcfdef0f09d78dd110c3a1f305edc8d2902f9/arch/x86/kernel/early-quirks.c

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

commit 47ad82b3b26489d86dd82c73c06562818819b8a9
Author: Lukas Wunner <lukas@wunner.de>
Date: Wed May 23 16:13:07 2018

UPSTREAM: x86/quirks: Apply nvidia_bugs quirk only on root bus

[ Upstream commit 447d29d1d3aed839e74c2401ef63387780ac51ed ]

Since the following commit:

  8659c406ade3 ("x86: only scan the root bus in early PCI quirks")

... early quirks are only applied to devices on the root bus.

The motivation was to prevent application of the nvidia_bugs quirk on
secondary buses.

We're about to reintroduce scanning of secondary buses for a quirk to
reset the Broadcom 4331 wireless card on 2011/2012 Macs. To prevent
regressions, open code the requirement to apply nvidia_bugs only on the
root bus.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I2e43d9aac4025261515229bfa89b6f5385465997
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.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: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/4d5477c1d76b2f0387a780f2142bbcdd9fee869b.1465690253.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 927dc15e3c07ce4fba29b06e470b83f4723eb23e
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068447

[modify] https://crrev.com/47ad82b3b26489d86dd82c73c06562818819b8a9/arch/x86/kernel/early-quirks.c

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

commit 3e4ea2f1e6f2796998e5ab6d82e83506d8aa821c
Author: Lukas Wunner <lukas@wunner.de>
Date: Wed May 23 16:13:09 2018

UPSTREAM: x86/quirks: Reintroduce scanning of secondary buses

[ Upstream commit 850c321027c2e31d0afc71588974719a4b565550 ]

We used to scan secondary buses until the following commit that
was applied in 2009:

  8659c406ade3 ("x86: only scan the root bus in early PCI quirks")

which commit constrained early quirks to the root bus only. Its
motivation was to prevent application of the nvidia_bugs quirk
on secondary buses.

We're about to add a quirk to reset the Broadcom 4331 wireless card on
2011/2012 Macs, which is located on a secondary bus behind a PCIe root
port. To facilitate that, reintroduce scanning of secondary buses.

The commit message of 8659c406ade3 notes that scanning only the root bus
"saves quite some unnecessary scanning work". The algorithm used prior
to 8659c406ade3 was particularly time consuming because it scanned
buses 0 to 31 brute force. To avoid lengthening boot time, employ a
recursive strategy which only scans buses that are actually reachable
from the root bus.

Yinghai Lu pointed out that the secondary bus number read from a
bridge's config space may be invalid, in particular a value of 0 would
cause an infinite loop. The PCI core goes beyond that and recurses to a
child bus only if its bus number is greater than the parent bus number
(see pci_scan_bridge()). Since the root bus is numbered 0, this implies
that secondary buses may not be 0. Do the same on early scanning.

If this algorithm is found to significantly impact boot time or cause
infinite loops on broken hardware, it would be possible to limit its
recursion depth: The Broadcom 4331 quirk applies at depth 1, all others
at depth 0, so the bus need not be scanned deeper than that for now. An
alternative approach would be to revert to scanning only the root bus,
and apply the Broadcom 4331 quirk to the root ports 8086:1c12, 8086:1e12
and 8086:1e16. Apple always positioned the card behind either of these
three ports. The quirk would then check presence of the card in slot 0
below the root port and do its deed.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I57c3e57da8bf63c550c2611b8899a935e102250a
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.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: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: linux-pci@vger.kernel.org
Link: http://lkml.kernel.org/r/f0daa70dac1a9b2483abdb31887173eb6ab77bdf.1465690253.git.lukas@wunner.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit dcb5a62d60438aa5a47b2659e8d170622941c27e
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068448

[modify] https://crrev.com/3e4ea2f1e6f2796998e5ab6d82e83506d8aa821c/arch/x86/kernel/early-quirks.c

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

commit a858ac6fc8019cc9abe83701c7bf9a4f60795d44
Author: Jim Mattson <jmattson@google.com>
Date: Wed May 23 16:13:10 2018

UPSTREAM: KVM: nVMX: Fix memory corruption when using VMCS shadowing

[ Upstream commit 2f1fe81123f59271bddda673b60116bde9660385 ]

When freeing the nested resources of a vcpu, there is an assumption that
the vcpu's vmcs01 is the current VMCS on the CPU that executes
nested_release_vmcs12(). If this assumption is violated, the vcpu's
vmcs01 may be made active on multiple CPUs at the same time, in
violation of Intel's specification. Moreover, since the vcpu's vmcs01 is
not VMCLEARed on every CPU on which it is active, it can linger in a
CPU's VMCS cache after it has been freed and potentially
repurposed. Subsequent eviction from the CPU's VMCS cache on a capacity
miss can result in memory corruption.

It is not sufficient for vmx_free_vcpu() to call vmx_load_vmcs01(). If
the vcpu in question was last loaded on a different CPU, it must be
migrated to the current CPU before calling vmx_load_vmcs01().

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Id22ba2e9b34a7153fa73e3555172b130d55ffbd0
Signed-off-by: Jim Mattson <jmattson@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 2aa2e066287e796f1ead8476a0b1306b10777f8f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068449

[modify] https://crrev.com/a858ac6fc8019cc9abe83701c7bf9a4f60795d44/arch/x86/kvm/vmx.c
[modify] https://crrev.com/a858ac6fc8019cc9abe83701c7bf9a4f60795d44/virt/kvm/kvm_main.c

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

commit d21c3f26f090433baaed2cc5b0fb4f35856801f8
Author: Sasha Levin <alexander.levin@verizon.com>
Date: Wed May 23 16:13:12 2018

UPSTREAM: x86/syscalls/64: Add compat_sys_keyctl for 32-bit userspace

[ Upstream commit f7d665627e103e82d34306c7d3f6f46f387c0d8b ]

x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than
calling sys_keyctl(). The latter will work in a lot of cases, thereby
hiding the issue.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ia03d258274dd849d310a31a632415e97415cec9c
Reported-by: Stephan Mueller <smueller@chronox.de>
Tested-by: Stephan Mueller <smueller@chronox.de>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
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: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/146961615805.14395.5581949237156769439.stgit@warthog.procyon.org.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 40ca045fb7b27303845538f7aa14b13eb33cebb4
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068450

[modify] https://crrev.com/d21c3f26f090433baaed2cc5b0fb4f35856801f8/arch/x86/syscalls/syscall_32.tbl

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

commit 1561d539a0000417b1dee8ac39fc0c3fa8e47639
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date: Wed May 23 16:13:13 2018

UPSTREAM: perf/x86: Fix undefined shift on 32-bit kernels

[ Upstream commit 6d6f2833bfbf296101f9f085e10488aef2601ba5 ]

Jim reported:

	UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12
	shift exponent 35 is too large for 32-bit type 'long unsigned int'

The use of 'unsigned long' type obviously is not correct here, make it
'unsigned long long' instead.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ieabe0917712f8fcded82999bef78a0c156acae53
Reported-by: Jim Cromie <jim.cromie@gmail.com>
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Imre Palik <imrep@amazon.de>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Fixes: 2c33645d366d ("perf/x86: Honor the architectural performance monitoring version")
Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 8f03e30ef13219ea2520f44d2b01daad5c95f30f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068451

[modify] https://crrev.com/1561d539a0000417b1dee8ac39fc0c3fa8e47639/arch/x86/kernel/cpu/perf_event_intel.c

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

commit 536b686445994cff18a71cab7dec49c008b2b323
Author: Steven Rostedt <rostedt@goodmis.org>
Date: Wed May 23 16:13:15 2018

UPSTREAM: x86/paravirt: Do not trace _paravirt_ident_*() functions

[ Upstream commit 15301a570754c7af60335d094dd2d1808b0641a5 ]

ukasz Daniluk reported that on a RHEL kernel that his machine would lock up
after enabling function tracer. I asked him to bisect the functions within
available_filter_functions, which he did and it came down to three:

  _paravirt_nop(), _paravirt_ident_32() and _paravirt_ident_64()

It was found that this is only an issue when noreplace-paravirt is added
to the kernel command line.

This means that those functions are most likely called within critical
sections of the funtion tracer, and must not be traced.

In newer kenels _paravirt_nop() is defined within gcc asm(), and is no
longer an issue.  But both _paravirt_ident_{32,64}() causes the
following splat when they are traced:

 mm/pgtable-generic.c:33: bad pmd ffff8800d2435150(0000000001d00054)
 mm/pgtable-generic.c:33: bad pmd ffff8800d3624190(0000000001d00070)
 mm/pgtable-generic.c:33: bad pmd ffff8800d36a5110(0000000001d00054)
 mm/pgtable-generic.c:33: bad pmd ffff880118eb1450(0000000001d00054)
 NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [systemd-journal:469]
 Modules linked in: e1000e
 CPU: 2 PID: 469 Comm: systemd-journal Not tainted 4.6.0-rc4-test+ #513
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
 task: ffff880118f740c0 ti: ffff8800d4aec000 task.ti: ffff8800d4aec000
 RIP: 0010:[<ffffffff81134148>]  [<ffffffff81134148>] queued_spin_lock_slowpath+0x118/0x1a0
 RSP: 0018:ffff8800d4aefb90  EFLAGS: 00000246
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88011eb16d40
 RDX: ffffffff82485760 RSI: 000000001f288820 RDI: ffffea0000008030
 RBP: ffff8800d4aefb90 R08: 00000000000c0000 R09: 0000000000000000
 R10: ffffffff821c8e0e R11: 0000000000000000 R12: ffff880000200fb8
 R13: 00007f7a4e3f7000 R14: ffffea000303f600 R15: ffff8800d4b562e0
 FS:  00007f7a4e3d7840(0000) GS:ffff88011eb00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f7a4e3f7000 CR3: 00000000d3e71000 CR4: 00000000001406e0
 Call Trace:
   _raw_spin_lock+0x27/0x30
   handle_pte_fault+0x13db/0x16b0
   handle_mm_fault+0x312/0x670
   __do_page_fault+0x1b1/0x4e0
   do_page_fault+0x22/0x30
   page_fault+0x28/0x30
   __vfs_read+0x28/0xe0
   vfs_read+0x86/0x130
   SyS_read+0x46/0xa0
   entry_SYSCALL_64_fastpath+0x1e/0xa8
 Code: 12 48 c1 ea 0c 83 e8 01 83 e2 30 48 98 48 81 c2 40 6d 01 00 48 03 14 c5 80 6a 5d 82 48 89 0a 8b 41 08 85 c0 75 09 f3 90 8b 41 08 <85> c0 74 f7 4c 8b 09 4d 85 c9 74 08 41 0f 18 09 eb 02 f3 90 8b

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I2d0bfcd80fb42f6dd87d6c44a6e2a72518fd7e49
Reported-by: ukasz Daniluk <lukasz.daniluk@intel.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 18ec3adc3d999b303bcf0e1cb907d7dbfb645677
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068452

[modify] https://crrev.com/536b686445994cff18a71cab7dec49c008b2b323/arch/x86/kernel/paravirt.c

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

commit 56a7af804a11d45ce12c6f3b08e00eaa52d830dc
Author: Emanuel Czirai <icanrealizeum@gmail.com>
Date: Wed May 23 16:13:16 2018

UPSTREAM: x86/AMD: Apply erratum 665 on machines without a BIOS fix

[ Upstream commit d1992996753132e2dafe955cccb2fb0714d3cfc4 ]

AMD F12h machines have an erratum which can cause DIV/IDIV to behave
unpredictably. The workaround is to set MSRC001_1029[31] but sometimes
there is no BIOS update containing that workaround so let's do it
ourselves unconditionally. It is simple enough.

[ Borislav: Wrote commit message. ]

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I3f3abbd0d9935de2aaaed8c0955794d28ba5452f
Signed-off-by: Emanuel Czirai <icanrealizeum@gmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Yaowu Xu <yaowu@google.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20160902053550.18097-1-bp@alien8.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 7c17faccf5276b2a85dadb877d2abc3e73041213
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068453

[modify] https://crrev.com/56a7af804a11d45ce12c6f3b08e00eaa52d830dc/arch/x86/kernel/cpu/amd.c

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

commit 17b310ae03d0ac9cb33a8966cdeba18720ef1b61
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Wed May 23 16:13:18 2018

UPSTREAM: fix minor infoleak in get_user_ex()

[ Upstream commit 1c109fabbd51863475cd12ac206bdd249aee35af ]

get_user_ex(x, ptr) should zero x on failure.  It's not a lot of a leak
(at most we are leaking uninitialized 64bit value off the kernel stack,
and in a fairly constrained situation, at that), but the fix is trivial,
so...

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I342f3bf5d3f272afafbe759f301cbc015d676c16
Cc: stable@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[ This sat in different branch from the uaccess fixes since mid-August ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit e58d9a8251584d92976d4cc7f46ab30963c9e99a
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068454

[modify] https://crrev.com/17b310ae03d0ac9cb33a8966cdeba18720ef1b61/arch/x86/include/asm/uaccess.h

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

commit ad7e085f75f7dfd8a78e130604b35e4da0bc1f42
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed May 23 16:13:20 2018

UPSTREAM: x86/cpu: Fix SMAP check in PVOPS environments

[ Upstream commit 581b7f158fe0383b492acd1ce3fb4e99d4e57808 ]

There appears to be no formal statement of what pv_irq_ops.save_fl() is
supposed to return precisely.  Native returns the full flags, while lguest and
Xen only return the Interrupt Flag, and both have comments by the
implementations stating that only the Interrupt Flag is looked at.  This may
have been true when initially implemented, but no longer is.

To make matters worse, the Xen PVOP leaves the upper bits undefined, making
the BUG_ON() undefined behaviour.  Experimentally, this now trips for 32bit PV
guests on Broadwell hardware.  The BUG_ON() is consistent for an individual
build, but not consistent for all builds.  It has also been a sitting timebomb
since SMAP support was introduced.

Use native_save_fl() instead, which will obtain an accurate view of the AC
flag.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I59cb5923f82fd6c5c4f35d1fbc88fff9246e78e6
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Tested-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: <lguest@lists.ozlabs.org>
Cc: Xen-devel <xen-devel@lists.xen.org>
CC: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1433323874-6927-1-git-send-email-andrew.cooper3@citrix.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit bb2f5ed8935a47f78a70ac48e58e993de46430e0
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068455

[modify] https://crrev.com/ad7e085f75f7dfd8a78e130604b35e4da0bc1f42/arch/x86/kernel/cpu/common.c

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

commit 23586e07a3e649103cfb58a613d799c28aaf2e88
Author: Andy Lutomirski <luto@kernel.org>
Date: Wed May 23 16:13:21 2018

UPSTREAM: x86/init: Fix cr4_init_shadow() on CR4-less machines

[ Upstream commit e1bfc11c5a6f40222a698a818dc269113245820e ]

cr4_init_shadow() will panic on 486-like machines without CR4.  Fix
it using __read_cr4_safe().

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I97ea2433d0a6dc73ae8face094322e51542dedf1
Reported-by: david@saggiorato.net
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
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: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Fixes: 1e02ce4cccdc ("x86: Store a per-cpu shadow copy of CR4")
Link: http://lkml.kernel.org/r/43a20f81fb504013bf613913dc25574b45336a61.1475091074.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 0e3f4b0fd5f8031d56251a452630a3448133895c
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068456

[modify] https://crrev.com/23586e07a3e649103cfb58a613d799c28aaf2e88/arch/x86/include/asm/tlbflush.h

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

commit c41f0e8c30341ba4ed97521262d94262e89b6533
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Wed May 23 16:13:23 2018

UPSTREAM: x86/kexec: add -fno-PIE

[ Upstream commit 90944e40ba1838de4b2a9290cf273f9d76bd3bdd ]

If the gcc is configured to do -fPIE by default then the build aborts
later with:
| Unsupported relocation type: unknown type rel type name (29)

Tagging it stable so it is possible to compile recent stable kernels as
well.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5ce74594559f05bddff081c6f4163faa199f9bf0
Cc: stable@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
(cherry picked from commit 5341057bf2727736bfaecd75009145972b5c4d2e
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068457

[modify] https://crrev.com/c41f0e8c30341ba4ed97521262d94262e89b6533/arch/x86/purgatory/Makefile

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

commit 60baf0573a0f9ad8fb95aa478c46b7b2a643a15d
Author: Juergen Gross <jgross@suse.com>
Date: Wed May 23 16:13:24 2018

UPSTREAM: x86/xen: fix upper bound of pmd loop in xen_cleanhighmap()

commit 1cf38741308c64d08553602b3374fb39224eeb5a upstream.

xen_cleanhighmap() is operating on level2_kernel_pgt only. The upper
bound of the loop setting non-kernel-image entries to zero should not
exceed the size of level2_kernel_pgt.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I08567de9db0829e80f8deee7e2bfadd720303b43
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 696ebb3a3a1f252301299c3168139dd20b6363da
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068458

[modify] https://crrev.com/60baf0573a0f9ad8fb95aa478c46b7b2a643a15d/arch/x86/xen/mmu.c

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

commit 727e4e2b46d1d7783e0b0cf9bfb9dad9de0d10ea
Author: Ingo Molnar <mingo@kernel.org>
Date: Wed May 23 16:13:26 2018

BACKPORT: x86/boot: Add CONFIG_PARAVIRT_SPINLOCKS quirk to arch/x86/boot/compressed/misc.h

commit 927392d73a97d8d235bb65400e2e3c7f0bec2b6f upstream.

Linus reported the following new warning on x86 allmodconfig with GCC 5.1:

  > ./arch/x86/include/asm/spinlock.h: In function arch_spin_lock:
  > ./arch/x86/include/asm/spinlock.h:119:3: warning: implicit declaration
  > of function __ticket_lock_spinning [-Wimplicit-function-declaration]
  >    __ticket_lock_spinning(lock, inc.tail);
  >    ^

This warning triggers because of these hacks in misc.h:

  /*
   * we have to be careful, because no indirections are allowed here, and
   * paravirt_ops is a kind of one. As it will only run in baremetal anyway,
   * we just keep it from happening
   */
  #undef CONFIG_PARAVIRT
  #undef CONFIG_KASAN

But these hacks were not updated when CONFIG_PARAVIRT_SPINLOCKS was added,
and eventually (with the introduction of queued paravirt spinlocks in
recent kernels) this created an invalid Kconfig combination and broke
the build.

So add a CONFIG_PARAVIRT_SPINLOCKS #undef line as well.

Also remove the _ASM_X86_DESC_H quirk: that undocumented quirk
was originally added ages ago, in:

  099e1377269a ("x86: use ELF format in compressed images.")

and I went back to that kernel (and fixed up the main Makefile
which didn't build anymore) and checked what failure it
avoided: it avoided an include file dependencies related
build failure related to our old x86-platforms code.

That old code is long gone, the header dependencies got cleaned
up, and the build does not fail anymore with the totality of
asm/desc.h included - so remove the quirk.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: If8a06fe7f8521967b11130e533a5f5e3b3806cbf
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5e471aea29514fac89871bc23eff49d62f0d8adc
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
[SR: trivial context differences]
 Conflicts:
	arch/x86/boot/compressed/misc.h
Reviewed-on: https://chromium-review.googlesource.com/1068459
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/727e4e2b46d1d7783e0b0cf9bfb9dad9de0d10ea/arch/x86/boot/compressed/misc.h

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

commit 1951a2ab01a1291b16eb990626261747dbedd703
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed May 23 16:13:28 2018

UPSTREAM: Fix potential infoleak in older kernels

commit dc1555e670c373bfa4ca2e1e2f839d5fe2b4501a upstream.

Not upstream as it is not needed there.

So a patch something like this might be a safe way to fix the
potential infoleak in older kernels.

THIS IS UNTESTED. It's a very obvious patch, though, so if it compiles
it probably works. It just initializes the output variable with 0 in
the inline asm description, instead of doing it in the exception
handler.

It will generate slightly worse code (a few unnecessary ALU
operations), but it doesn't have any interactions with the exception
handler implementation.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I1a01c68d7e155c185b3091d1a4dc04b712c9bfe3
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit afef4db94424df50555407c7366421f39462f27a
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068460

[modify] https://crrev.com/1951a2ab01a1291b16eb990626261747dbedd703/arch/x86/include/asm/uaccess.h

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

commit 6c7dbf58d94de5317d4c1ad71067aa23d47a6aa1
Author: Wang, Rui Y <rui.y.wang@intel.com>
Date: Wed May 23 16:13:29 2018

UPSTREAM: crypto: ghash-clmulni - Fix load failure

commit 3a020a723c65eb8ffa7c237faca26521a024e582 upstream.

ghash_clmulni_intel fails to load on Linux 4.3+ with the following message:
"modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument"

After 8996eafdc ("crypto: ahash - ensure statesize is non-zero") all ahash
drivers are required to implement import()/export(), and must have a non-
zero statesize.

This patch has been tested with the algif_hash interface. The calculated
digest values, after several rounds of import()s and export()s, match those
calculated by tcrypt.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ia3025b7d91b63e69f6acb7bfe2345ff30b633e7e
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d126a427621bae922bc4c204de947d0f9b924e70
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068461

[modify] https://crrev.com/6c7dbf58d94de5317d4c1ad71067aa23d47a6aa1/arch/x86/crypto/ghash-clmulni-intel_glue.c

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

commit 956eb603e074b0ba76d06dadb53765ee837c7082
Author: Peter Zijlstra <peterz@infradead.org>
Date: Wed May 23 16:13:31 2018

UPSTREAM: perf/x86: Avoid exposing wrong/stale data in intel_pmu_lbr_read_32()

commit f2200ac311302fcdca6556fd0c5127eab6c65a3e upstream.

When the perf_branch_entry::{in_tx,abort,cycles} fields were added,
intel_pmu_lbr_read_32() wasn't updated to initialize them.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I4f5409c9f9be6d5f03f41a142eac15f891c92125
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: 135c5612c460 ("perf/x86/intel: Support Haswell/v4 LBR format")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f9e23df467fef4c19847cb7331d6a3309d5144c3
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068462

[modify] https://crrev.com/956eb603e074b0ba76d06dadb53765ee837c7082/arch/x86/kernel/cpu/perf_event_intel_lbr.c

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

commit 531adc4f312a32f0cc293d5b69469a00985e2927
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed May 23 16:13:32 2018

UPSTREAM: x86/vdso: Plug race between mapping and ELF header setup

commit 6fdc6dd90272ce7e75d744f71535cfbd8d77da81 upstream.

The vsyscall32 sysctl can racy against a concurrent fork when it switches
from disabled to enabled:

    arch_setup_additional_pages()
	if (vdso32_enabled)
           --> No mapping
                                        sysctl.vsysscall32()
                                          --> vdso32_enabled = true
    create_elf_tables()
      ARCH_DLINFO_IA32
        if (vdso32_enabled) {
           --> Add VDSO entry with NULL pointer

Make ARCH_DLINFO_IA32 check whether the VDSO mapping has been set up for
the newly forked process or not.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic2d56d01a8e1dc07a851c1561e251a0c028756ba
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mathias Krause <minipli@googlemail.com>
Link: http://lkml.kernel.org/r/20170410151723.602367196@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3255c1b5ef16098a658a2ddb9194813f0323fc80
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068463

[modify] https://crrev.com/531adc4f312a32f0cc293d5b69469a00985e2927/arch/x86/include/asm/elf.h

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

commit 8ed0da68e20c61062cf887be349d78d71399c77e
Author: Mathias Krause <minipli@googlemail.com>
Date: Wed May 23 16:13:34 2018

UPSTREAM: x86/vdso: Ensure vdso32_enabled gets set to valid values only

commit c06989da39cdb10604d572c8c7ea8c8c97f3c483 upstream.

vdso_enabled can be set to arbitrary integer values via the kernel command
line 'vdso32=' parameter or via 'sysctl abi.vsyscall32'.

load_vdso32() only maps VDSO if vdso_enabled == 1, but ARCH_DLINFO_IA32
merily checks for vdso_enabled != 0. As a consequence the AT_SYSINFO_EHDR
auxiliary vector for the VDSO_ENTRY is emitted with a NULL pointer which
causes a segfault when the application tries to use the VDSO.

Restrict the valid arguments on the command line and the sysctl to 0 and 1.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Iec61428471ff41499c1f483d0fd898de18e35e6f
Fixes: b0b49f2673f0 ("x86, vdso: Remove compat vdso support")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roland McGrath <roland@redhat.com>
Link: http://lkml.kernel.org/r/1491424561-7187-1-git-send-email-minipli@googlemail.com
Link: http://lkml.kernel.org/r/20170410151723.518412863@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ced7ce3d7440482f960f506718cb2e500a35b088
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068464

[modify] https://crrev.com/8ed0da68e20c61062cf887be349d78d71399c77e/arch/x86/vdso/vdso32-setup.c

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

commit f8fc7c4994274ae5e0e0082ac9e95fb0da4e6ff9
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 23:46:44 2018

UPSTREAM: kvm: fix page struct leak in handle_vmon

commit 06ce521af9558814b8606c0476c54497cf83a653 upstream.

handle_vmon gets a reference on VMXON region page,
but does not release it. Release the reference.

Found by syzkaller; based on a patch by Dmitry.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie4c4563323a8fe9539531d7c3704214c2a2511aa
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[bwh: Backported to 3.16: use skip_emulated_instruction()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit aa5b35bad59a2691db0ea739fb79be82aff5cbb8
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068465

[modify] https://crrev.com/f8fc7c4994274ae5e0e0082ac9e95fb0da4e6ff9/arch/x86/kvm/vmx.c

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

commit b4729b6c9df4a3927d4aa69177e57cc559a68d68
Author: Kees Cook <keescook@chromium.org>
Date: Wed May 23 23:46:46 2018

UPSTREAM: mm: Tighten x86 /dev/mem with zeroing reads

commit a4866aa812518ed1a37d8ea0c881dc946409de94 upstream.

Under CONFIG_STRICT_DEVMEM, reading System RAM through /dev/mem is
disallowed. However, on x86, the first 1MB was always allowed for BIOS
and similar things, regardless of it actually being System RAM. It was
possible for heap to end up getting allocated in low 1MB RAM, and then
read by things like x86info or dd, which would trip hardened usercopy:

usercopy: kernel memory exposure attempt detected from ffff880000090000 (dma-kmalloc-256) (4096 bytes)

This changes the x86 exception for the low 1MB by reading back zeros for
System RAM areas instead of blindly allowing them. More work is needed to
extend this to mmap, but currently mmap doesn't go through usercopy, so
hardened usercopy won't Oops the kernel.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5312622d2fa1dcf9a64f4a0489ac24a081da6745
Reported-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Tested-by: Tommi Rantala <tommi.t.rantala@nokia.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Brad Spengler <spender@grsecurity.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit be63d158bba15c468d474808b60e6ac2417a933b
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068466

[modify] https://crrev.com/b4729b6c9df4a3927d4aa69177e57cc559a68d68/drivers/char/mem.c
[modify] https://crrev.com/b4729b6c9df4a3927d4aa69177e57cc559a68d68/arch/x86/mm/init.c

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

commit 2c3f95ff5b81a749270d2a4f684798a6cd72f16e
Author: Yazen Ghannam <yazen.ghannam@amd.com>
Date: Wed May 23 23:46:47 2018

UPSTREAM: x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs

commit 29f72ce3e4d18066ec75c79c857bee0618a3504b upstream.

MCA bank 3 is reserved on systems pre-Fam17h, so it didn't have a name.
However, MCA bank 3 is defined on Fam17h systems and can be accessed
using legacy MSRs. Without a name we get a stack trace on Fam17h systems
when trying to register sysfs files for bank 3 on kernels that don't
recognize Scalable MCA.

Call MCA bank 3 "decode_unit" since this is what it represents on
Fam17h. This will allow kernels without SMCA support to see this bank on
Fam17h+ and prevent the stack trace. This will not affect older systems
since this bank is reserved on them, i.e. it'll be ignored.

Tested on AMD Fam15h and Fam17h systems.

  WARNING: CPU: 26 PID: 1 at lib/kobject.c:210 kobject_add_internal
  kobject: (ffff88085bb256c0): attempted to be registered with empty name!
  ...
  Call Trace:
   kobject_add_internal
   kobject_add
   kobject_create_and_add
   threshold_create_device
   threshold_init_device

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I34a7e4c21c0dfda7770061c88d9d7d2c9a23886f
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: http://lkml.kernel.org/r/1490102285-3659-1-git-send-email-Yazen.Ghannam@amd.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0420e5585687bc1713dbaea4f4a2348c4bb43b60
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068467

[modify] https://crrev.com/2c3f95ff5b81a749270d2a4f684798a6cd72f16e/arch/x86/kernel/cpu/mcheck/mce_amd.c

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

commit 1d5848377ff0047e731611fee27cafc1037fd4b4
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed May 23 23:46:48 2018

UPSTREAM: kconfig: tinyconfig: provide whole choice blocks to avoid warnings

commit 236dec051078a8691950f56949612b4b74107e48 upstream.

Using "make tinyconfig" produces a couple of annoying warnings that show
up for build test machines all the time:

    .config:966:warning: override: NOHIGHMEM changes choice state
    .config:965:warning: override: SLOB changes choice state
    .config:963:warning: override: KERNEL_XZ changes choice state
    .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
    .config:933:warning: override: SLOB changes choice state
    .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
    .config:870:warning: override: SLOB changes choice state
    .config:868:warning: override: KERNEL_XZ changes choice state
    .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state

I've made a previous attempt at fixing them and we discussed a number of
alternatives.

I tried changing the Makefile to use "merge_config.sh -n
$(fragment-list)" but couldn't get that to work properly.

This is yet another approach, based on the observation that we do want
to see a warning for conflicting 'choice' options, and that we can
simply make them non-conflicting by listing all other options as
disabled.  This is a trivial patch that we can apply independent of
plans for other changes.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I2773b41d86c9d94ca7ca5be1faaee02ac5faf224
Link: http://lkml.kernel.org/r/20160829214952.1334674-2-arnd@arndb.de
Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log
https://patchwork.kernel.org/patch/9212749/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 39541d00f20c8f89667d257de3a5464b3f73be49
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068468

[modify] https://crrev.com/1d5848377ff0047e731611fee27cafc1037fd4b4/arch/x86/configs/tiny.config
[modify] https://crrev.com/1d5848377ff0047e731611fee27cafc1037fd4b4/kernel/configs/tiny.config

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

commit 7c713585ac5a2417956ebfb3ad9053748ef8a7c9
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Wed May 23 23:46:50 2018

UPSTREAM: xen/x86: don't lose event interrupts

commit c06b6d70feb32d28f04ba37aa3df17973fd37b6b upstream.

On slow platforms with unreliable TSC, such as QEMU emulated machines,
it is possible for the kernel to request the next event in the past. In
that case, in the current implementation of xen_vcpuop_clockevent, we
simply return -ETIME. To be precise the Xen returns -ETIME and we pass
it on. However the result of this is a missed event, which simply causes
the kernel to hang.

Instead it is better to always ask the hypervisor for a timer event,
even if the timeout is in the past. That way there are no lost
interrupts and the kernel survives. To do that, remove the
VCPU_SSHOTTMR_future flag.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I38ca8c471e57cc68e1b69f87c9a785de936aef97
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Juergen Gross <jgross@suse.com>
Cc: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9e853ef16c510d43de94675bca2f375b0adaf597
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068469

[modify] https://crrev.com/7c713585ac5a2417956ebfb3ad9053748ef8a7c9/arch/x86/xen/time.c

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

commit 45b7a07556c1b95134a62faf75aa2ca5ef0a54b5
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date: Wed May 23 23:46:51 2018

UPSTREAM: ftrace/x86: Fix triple fault with graph tracing and suspend-to-ram

commit 34a477e5297cbaa6ecc6e17c042a866e1cbe80d6 upstream.

On x86-32, with CONFIG_FIRMWARE and multiple CPUs, if you enable function
graph tracing and then suspend to RAM, it will triple fault and reboot when
it resumes.

The first fault happens when booting a secondary CPU:

startup_32_smp()
  load_ucode_ap()
    prepare_ftrace_return()
      ftrace_graph_is_dead()
        (accesses 'kill_ftrace_graph')

The early head_32.S code calls into load_ucode_ap(), which has an an
ftrace hook, so it calls prepare_ftrace_return(), which calls
ftrace_graph_is_dead(), which tries to access the global
'kill_ftrace_graph' variable with a virtual address, causing a fault
because the CPU is still in real mode.

The fix is to add a check in prepare_ftrace_return() to make sure it's
running in protected mode before continuing.  The check makes sure the
stack pointer is a virtual kernel address.  It's a bit of a hack, but
it's not very intrusive and it works well enough.

For reference, here are a few other (more difficult) ways this could
have potentially been fixed:

- Move startup_32_smp()'s call to load_ucode_ap() down to *after* paging
  is enabled.  (No idea what that would break.)

- Track down load_ucode_ap()'s entire callee tree and mark all the
  functions 'notrace'.  (Probably not realistic.)

- Pause graph tracing in ftrace_suspend_notifier_call() or bringup_cpu()
  or __cpu_up(), and ensure that the pause facility can be queried from
  real mode.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I0ba2ecc6797de73d2725f16b64b11aeb045f8e79
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: "Rafael J . Wysocki" <rjw@rjwysocki.net>
Cc: linux-acpi@vger.kernel.org
Cc: Borislav Petkov <bp@alien8.de>
Cc: Len Brown <lenb@kernel.org>
Link: http://lkml.kernel.org/r/5c1272269a580660703ed2eccf44308e790c7a98.1492123841.git.jpoimboe@redhat.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ef6173b2edf33404c218539efe601b489cee1d12
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068470

[modify] https://crrev.com/45b7a07556c1b95134a62faf75aa2ca5ef0a54b5/arch/x86/kernel/ftrace.c

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

commit ed314665e88c761fae04d8ea000072fb026aa04e
Author: Nikola Pajkovsky <npajkovsky@suse.cz>
Date: Wed May 23 23:46:53 2018

UPSTREAM: x86/pci-calgary: Fix iommu_free() comparison of unsigned expression >= 0

commit 68dee8e2f2cacc54d038394e70d22411dee89da2 upstream.

commit 8fd524b355da ("x86: Kill bad_dma_address variable") has killed
bad_dma_address variable and used instead of macro DMA_ERROR_CODE
which is always zero. Since dma_addr is unsigned, the statement

   dma_addr >= DMA_ERROR_CODE

is always true, and not needed.

arch/x86/kernel/pci-calgary_64.c: In function iommu_free:
arch/x86/kernel/pci-calgary_64.c:299:2: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]
  if (unlikely((dma_addr >= DMA_ERROR_CODE) && (dma_addr < badend))) {

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I2250735f543fe9e57829f4c4f092d67d0fd51d13
Fixes: 8fd524b355da ("x86: Kill bad_dma_address variable")
Signed-off-by: Nikola Pajkovsky <npajkovsky@suse.cz>
Cc: iommu@lists.linux-foundation.org
Cc: Jon Mason <jdmason@kudzu.us>
Cc: Muli Ben-Yehuda <mulix@mulix.org>
Link: http://lkml.kernel.org/r/7612c0f9dd7c1290407dbf8e809def922006920b.1479161177.git.npajkovsky@suse.cz
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8c9c9d5acd83f47622424809d782a1c6cd7ce380
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068471

[modify] https://crrev.com/ed314665e88c761fae04d8ea000072fb026aa04e/arch/x86/kernel/pci-calgary_64.c

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

commit 2d6d100cb6ac427c919d57f35ba070968c58cfa7
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed May 23 23:46:54 2018

UPSTREAM: kprobes/x86: Fix kernel panic when certain exception-handling addresses are probed

commit 75013fb16f8484898eaa8d0b08fed942d790f029 upstream.

Fix to the exception table entry check by using probed address
instead of the address of copied instruction.

This bug may cause unexpected kernel panic if user probe an address
where an exception can happen which should be fixup by __ex_table
(e.g. copy_from_user.)

Unless user puts a kprobe on such address, this doesn't
cause any problem.

This bug has been introduced years ago, by commit:

  464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently").

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic355a0ede4cdc9465831b637a66d9290ea8416cd
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 464846888d9a ("x86/kprobes: Fix a bug which can modify kernel code permanently")
Link: http://lkml.kernel.org/r/148829899399.28855.12581062400757221722.stgit@devbox
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a4b3fc13402189a6cb7813ec12cabda87070b293
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068472

[modify] https://crrev.com/2d6d100cb6ac427c919d57f35ba070968c58cfa7/arch/x86/kernel/kprobes/opt.c
[modify] https://crrev.com/2d6d100cb6ac427c919d57f35ba070968c58cfa7/arch/x86/kernel/kprobes/common.h
[modify] https://crrev.com/2d6d100cb6ac427c919d57f35ba070968c58cfa7/arch/x86/kernel/kprobes/core.c

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

commit 7953ba248208a6b794eaab2afadc10475ee9056c
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Wed May 23 23:46:55 2018

UPSTREAM: x86/platform/intel-mid: Correct MSI IRQ line for watchdog device

commit 80354c29025833acd72ddac1ffa21c6cb50128cd upstream.

The interrupt line used for the watchdog is 12, according to the official
Intel Edison BSP code.

And indeed after fixing it we start getting an interrupt and thus the
watchdog starts working again:

  [  191.699951] Kernel panic - not syncing: Kernel Watchdog

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Iba95427ce1066ac2eb8c20833c546980e72e535a
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 78a3bb9e408b ("x86: intel-mid: add watchdog platform code for Merrifield")
Link: http://lkml.kernel.org/r/20170312150744.45493-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4e751f0c66459cb436bacb6c11abcc05582da996
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068473

[modify] https://crrev.com/7953ba248208a6b794eaab2afadc10475ee9056c/arch/x86/platform/intel-mid/device_libs/platform_wdt.c

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

commit 0023e309ef429c0f7afeef6bb982992411e104ad
Author: Jim Mattson <jmattson@google.com>
Date: Wed May 23 23:46:57 2018

UPSTREAM: Revert "KVM: nested VMX: disable perf cpuid reporting"

commit 0b4c208d443ba2af82b4c70f99ca8df31e9a0020 upstream.

This reverts commit bc6134942dbbf31c25e9bd7c876be5da81c9e1ce.

A CPUID instruction executed in VMX non-root mode always causes a
VM-exit, regardless of the leaf being queried.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I72bf3391e2d1df436e935d1531a845f14b9c9bfd
Fixes: bc6134942dbb ("KVM: nested VMX: disable perf cpuid reporting")
Signed-off-by: Jim Mattson <jmattson@google.com>
[The issue solved by bc6134942dbb has been resolved with ff651cb613b4
 ("KVM: nVMX: Add nested msr load/restore algorithm").]
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a44b41cc492da3322f81d0f8ef2a355501fa663d
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068474

[modify] https://crrev.com/0023e309ef429c0f7afeef6bb982992411e104ad/arch/x86/kvm/cpuid.c
[modify] https://crrev.com/0023e309ef429c0f7afeef6bb982992411e104ad/arch/x86/kvm/vmx.c

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

commit d15d925115e993b80027db0d891da8d5841aee1e
Author: Ashish Kalra <ashish@bluestacks.com>
Date: Wed May 23 23:46:58 2018

UPSTREAM: x86/boot: Fix BSS corruption/overwrite bug in early x86 kernel startup

commit d594aa0277e541bb997aef0bc0a55172d8138340 upstream.

The minimum size for a new stack (512 bytes) setup for arch/x86/boot components
when the bootloader does not setup/provide a stack for the early boot components
is not "enough".

The setup code executing as part of early kernel startup code, uses the stack
beyond 512 bytes and accidentally overwrites and corrupts part of the BSS
section. This is exposed mostly in the early video setup code, where
it was corrupting BSS variables like force_x, force_y, which in-turn affected
kernel parameters such as screen_info (screen_info.orig_video_cols) and
later caused an exception/panic in console_init().

Most recent boot loaders setup the stack for early boot components, so this
stack overwriting into BSS section issue has not been exposed.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I7809b8e584f9533d2e37b80e6ce169153b5cd05d
Signed-off-by: Ashish Kalra <ashish@bluestacks.com>
Cc: Andy Lutomirski <luto@kernel.org>
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: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20170419152015.10011-1-ashishkalra@Ashishs-MacBook-Pro.local
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3e576d765dc98ef004bd1706ab27733c50c7b976
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068475

[modify] https://crrev.com/d15d925115e993b80027db0d891da8d5841aee1e/arch/x86/boot/boot.h

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

commit 7fac4f2bce34193565694b73e93d057406d536be
Author: Richard Weinberger <richard@nod.at>
Date: Wed May 23 23:47:00 2018

UPSTREAM: um: Fix PTRACE_POKEUSER on x86_64

commit 9abc74a22d85ab29cef9896a2582a530da7e79bf upstream.

This is broken since ever but sadly nobody noticed.
Recent versions of GDB set DR_CONTROL unconditionally and
UML dies due to a heap corruption. It turns out that
the PTRACE_POKEUSER was copy&pasted from i386 and assumes
that addresses are 4 bytes long.

Fix that by using 8 as address size in the calculation.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I7b6f689b4cd6a0652ea567cad6a161096db426dc
Reported-by: jie cao <cj3054@gmail.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 02ad5d8d9d78d0a506b7fd8ec3abeca9fadb701b
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068476

[modify] https://crrev.com/7fac4f2bce34193565694b73e93d057406d536be/arch/x86/um/ptrace_64.c

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

commit 0eab5de4323023ecb898c90d68f257552f1363ac
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 23:47:01 2018

UPSTREAM: kvm: async_pf: fix rcu_irq_enter() with irqs enabled

commit bbaf0e2b1c1b4f88abd6ef49576f0efb1734eae5 upstream.

native_safe_halt enables interrupts, and you just shouldn't
call rcu_irq_enter() with interrupts enabled.  Reorder the
call with the following local_irq_disable() to respect the
invariant.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I4c9de0d2b730ed55dfe2457e23cfe712d2b3ed65
Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 1173e90e46e4421c6b8d74d9d0fc6ac0f00a68f8
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068477

[modify] https://crrev.com/0eab5de4323023ecb898c90d68f257552f1363ac/arch/x86/kernel/kvm.c

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

commit 3b30b84f082765c3e15bca2ab4556a940b2f890e
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:03 2018

UPSTREAM: KVM: cpuid: Fix read/write out-of-bounds vulnerability in cpuid emulation

commit a3641631d14571242eec0d30c9faa786cbf52d44 upstream.

If "i" is the last element in the vcpu->arch.cpuid_entries[] array, it
potentially can be exploited the vulnerability. this will out-of-bounds
read and write.  Luckily, the effect is small:

	/* when no next entry is found, the current entry[i] is reselected */
	for (j = i + 1; ; j = (j + 1) % nent) {
		struct kvm_cpuid_entry2 *ej = &vcpu->arch.cpuid_entries[j];
		if (ej->function == e->function) {

It reads ej->maxphyaddr, which is user controlled.  However...

			ej->flags |= KVM_CPUID_FLAG_STATE_READ_NEXT;

After cpuid_entries there is

	int maxphyaddr;
	struct x86_emulate_ctxt emulate_ctxt;  /* 16-byte aligned */

So we have:

- cpuid_entries at offset 1B50 (6992)
- maxphyaddr at offset 27D0 (6992 + 3200 = 10192)
- padding at 27D4...27DF
- emulate_ctxt at 27E0

And it writes in the padding.  Pfew, writing the ops field of emulate_ctxt
would have been much worse.

This patch fixes it by modding the index to avoid the out-of-bounds
access. Worst case, i == j and ej->function == e->function,
the loop can bail out.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I39956a98ed9a8035fe290c60df91c3731a7339a0
Reported-by: Moguofang <moguofang@huawei.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Cc: Guofang Mo <moguofang@huawei.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 9cdc5d2e13226b733563a67a028224523902cfa3
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068478

[modify] https://crrev.com/3b30b84f082765c3e15bca2ab4556a940b2f890e/arch/x86/kvm/cpuid.c

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

commit da884f59811185b8cc7d21be91b6a542ce722e5b
Author: Laura Abbott <labbott@redhat.com>
Date: Wed May 23 23:47:04 2018

UPSTREAM: x86/mm/32: Set the '__vmalloc_start_set' flag in initmem_init()

commit 861ce4a3244c21b0af64f880d5bfe5e6e2fb9e4a upstream.

'__vmalloc_start_set' currently only gets set in initmem_init() when
!CONFIG_NEED_MULTIPLE_NODES. This breaks detection of vmalloc address
with virt_addr_valid() with CONFIG_NEED_MULTIPLE_NODES=y, causing
a kernel crash:

  [mm/usercopy] 517e1fbeb6: kernel BUG at arch/x86/mm/physaddr.c:78!

Set '__vmalloc_start_set' appropriately for that case as well.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie542579881122e5ac1055b0997e59e3288ce0cd9
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: dc16ecf7fd1f ("x86-32: use specific __vmalloc_start_set flag in __virt_addr_valid")
Link: http://lkml.kernel.org/r/1494278596-30373-1-git-send-email-labbott@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 305d63f6c69728cc41f2c49996bafeb45366a385
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068479

[modify] https://crrev.com/da884f59811185b8cc7d21be91b6a542ce722e5b/arch/x86/mm/numa_32.c

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

commit 7ceb9d3f7b21c9abe0ad2b4767de4e46d7c0f547
Author: Radim Krčmář <rkrcmar@redhat.com>
Date: Wed May 23 23:47:05 2018

UPSTREAM: KVM: x86: zero base3 of unusable segments

commit f0367ee1d64d27fa08be2407df5c125442e885e3 upstream.

Static checker noticed that base3 could be used uninitialized if the
segment was not present (useable).  Random stack values probably would
not pass VMCS entry checks.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ib852bb8de86fbb8c64c05622426feedbbb61ddb7
Reported-by:  Dan Carpenter <dan.carpenter@oracle.com>
Fixes: 1aa366163b8b ("KVM: x86 emulator: consolidate segment accessors")
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 42ba428e3f103f2c6f3b99a70d7a48f04986e908
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068480

[modify] https://crrev.com/7ceb9d3f7b21c9abe0ad2b4767de4e46d7c0f547/arch/x86/kvm/x86.c

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

commit 778654ac6aab0512426122c55c08a7c2cdc6d056
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:07 2018

UPSTREAM: KVM: nVMX: Fix exception injection

commit d4912215d1031e4fb3d1038d2e1857218dba0d0a upstream.

 WARNING: CPU: 3 PID: 2840 at arch/x86/kvm/vmx.c:10966 nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
 CPU: 3 PID: 2840 Comm: qemu-system-x86 Tainted: G           OE   4.12.0-rc3+ #23
 RIP: 0010:nested_vmx_vmexit+0xdcd/0xde0 [kvm_intel]
 Call Trace:
  ? kvm_check_async_pf_completion+0xef/0x120 [kvm]
  ? rcu_read_lock_sched_held+0x79/0x80
  vmx_queue_exception+0x104/0x160 [kvm_intel]
  ? vmx_queue_exception+0x104/0x160 [kvm_intel]
  kvm_arch_vcpu_ioctl_run+0x1171/0x1ce0 [kvm]
  ? kvm_arch_vcpu_load+0x47/0x240 [kvm]
  ? kvm_arch_vcpu_load+0x62/0x240 [kvm]
  kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
  ? kvm_vcpu_ioctl+0x384/0x7b0 [kvm]
  ? __fget+0xf3/0x210
  do_vfs_ioctl+0xa4/0x700
  ? __fget+0x114/0x210
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x81/0x220
  entry_SYSCALL64_slow_path+0x25/0x25

This is triggered occasionally by running both win7 and win2016 in L2, in
addition, EPT is disabled on both L1 and L2. It can't be reproduced easily.

Commit 0b6ac343fc (KVM: nVMX: Correct handling of exception injection) mentioned
that "KVM wants to inject page-faults which it got to the guest. This function
assumes it is called with the exit reason in vmcs02 being a #PF exception".
Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to
L2) allows to check all exceptions for intercept during delivery to L2. However,
there is no guarantee the exit reason is exception currently, when there is an
external interrupt occurred on host, maybe a time interrupt for host which should
not be injected to guest, and somewhere queues an exception, then the function
nested_vmx_check_exception() will be called and the vmexit emulation codes will
try to emulate the "Acknowledge interrupt on exit" behavior, the warning is
triggered.

Reusing the exit reason from the L2->L0 vmexit is wrong in this case,
the reason must always be EXCEPTION_NMI when injecting an exception into
L1 as a nested vmexit.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I69941f7fb3c2becd445ae76587e32693b6f61161
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Fixes: e011c663b9c7 ("KVM: nVMX: Check all exceptions for intercept during delivery to L2")
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 240b73151497d528da00d3232f1f6dd326fe9b2f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068481

[modify] https://crrev.com/778654ac6aab0512426122c55c08a7c2cdc6d056/arch/x86/kvm/vmx.c

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

commit ff7a6c1abab2be9cc21ae5414bd5b4516743c4f2
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed May 23 23:47:08 2018

UPSTREAM: crypto: sha1-ssse3 - Disable avx2

commit b82ce24426a4071da9529d726057e4e642948667 upstream.

It has been reported that sha1-avx2 can cause page faults by reading
beyond the end of the input.  This patch disables it until it can be
fixed.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I8e597f3bbf6ccde02429a3066dc3179face83a21
Fixes: 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2")
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 17ab2212a52caa1233fc74f07e08a4f6464435bf
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068482

[modify] https://crrev.com/ff7a6c1abab2be9cc21ae5414bd5b4516743c4f2/arch/x86/crypto/sha1_ssse3_glue.c

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

commit fb884988f929c7c983947ee2dafa595c9cb8d409
Author: Colin King <colin.king@canonical.com>
Date: Wed May 23 23:47:10 2018

UPSTREAM: x86/rtc: Remove duplicate const specifier

commit d505ad1d66c9cd31db5ab0d2c7bcb2a47e5bb29e upstream.

Building with clang:

  CC      arch/x86/kernel/rtc.o
arch/x86/kernel/rtc.c:173:29: warning: duplicate 'const' declaration
  specifier [-Wduplicate-decl-specifier]
        static const char * const  const ids[] __initconst =

Remove the duplicate const, it is not needed and causes a warning.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I601ab5375715192b6d4b10ffa5ca49fed0cd0b64
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: http://lkml.kernel.org/r/1421244475-313-1-git-send-email-colin.king@canonical.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c392029da52e98d2d2a7bd70874c135b49b45d63
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068483

[modify] https://crrev.com/fb884988f929c7c983947ee2dafa595c9cb8d409/arch/x86/kernel/rtc.c

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

commit ace3493e4454a4bcc927a584ee2c68f6fa2d2875
Author: Seunghun Han <kkamagui@gmail.com>
Date: Wed May 23 23:47:11 2018

UPSTREAM: x86/acpi: Prevent out of bound access caused by broken ACPI tables

commit dad5ab0db8deac535d03e3fe3d8f2892173fa6a4 upstream.

The bus_irq argument of mp_override_legacy_irq() is used as the index into
the isa_irq_to_gsi[] array. The bus_irq argument originates from
ACPI_MADT_TYPE_IO_APIC and ACPI_MADT_TYPE_INTERRUPT items in the ACPI
tables, but is nowhere sanity checked.

That allows broken or malicious ACPI tables to overwrite memory, which
might cause malfunction, panic or arbitrary code execution.

Add a sanity check and emit a warning when that triggers.

[ tglx: Added warning and rewrote changelog ]

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie12ca598a9b18ae9e050de6dc1d1ca932004b75c
Signed-off-by: Seunghun Han <kkamagui@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: security@kernel.org
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7f377fc4008980278edbfd9d70ef9aa91ffa8448
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068484

[modify] https://crrev.com/ace3493e4454a4bcc927a584ee2c68f6fa2d2875/arch/x86/kernel/acpi/boot.c

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

commit 3f5691f1f62a07d661d73cbcea23dbf4a843cad2
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed May 23 23:47:12 2018

UPSTREAM: x86/mce/AMD: Make the init code more robust

[ Upstream commit 0dad3a3014a0b9e72521ff44f17e0054f43dcdea ]

If mce_device_init() fails then the mce device pointer is NULL and the
AMD mce code happily dereferences it.

Add a sanity check.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I07db7a1af4f58a1a334a27f001398513a6c3ff5a
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 73f7545a039e01842d1b164d1bf985ede2786386
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068485

[modify] https://crrev.com/3f5691f1f62a07d661d73cbcea23dbf4a843cad2/arch/x86/kernel/cpu/mcheck/mce_amd.c

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

commit 907691b4a170f674e248d0aaf690f7fe91e3dfbc
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:14 2018

UPSTREAM: KVM: async_pf: make rcu irq exit if not triggered from idle task

commit 337c017ccdf2653d0040099433fc1a2b1beb5926 upstream.

 WARNING: CPU: 5 PID: 1242 at kernel/rcu/tree_plugin.h:323 rcu_note_context_switch+0x207/0x6b0
 CPU: 5 PID: 1242 Comm: unity-settings- Not tainted 4.13.0-rc2+ #1
 RIP: 0010:rcu_note_context_switch+0x207/0x6b0
 Call Trace:
  __schedule+0xda/0xba0
  ? kvm_async_pf_task_wait+0x1b2/0x270
  schedule+0x40/0x90
  kvm_async_pf_task_wait+0x1cc/0x270
  ? prepare_to_swait+0x22/0x70
  do_async_page_fault+0x77/0xb0
  ? do_async_page_fault+0x77/0xb0
  async_page_fault+0x28/0x30
 RIP: 0010:__d_lookup_rcu+0x90/0x1e0

I encounter this when trying to stress the async page fault in L1 guest w/
L2 guests running.

Commit 9b132fbe5419 (Add rcu user eqs exception hooks for async page
fault) adds rcu_irq_enter/exit() to kvm_async_pf_task_wait() to exit cpu
idle eqs when needed, to protect the code that needs use rcu.  However,
we need to call the pair even if the function calls schedule(), as seen
from the above backtrace.

This patch fixes it by informing the RCU subsystem exit/enter the irq
towards/away from idle for both n.halted and !n.halted.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I2974ae190d9cb2a700c20ed1d3a1797fadfd6a41
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4110ee7ebb2bc8120f7bf767bc6bd29a30b60912
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068486

[modify] https://crrev.com/907691b4a170f674e248d0aaf690f7fe91e3dfbc/arch/x86/kernel/kvm.c

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

commit 8d1dbb3925e7954259c655df076ddb8a9a513160
Author: Nicholas Mc Guire <hofrat@osadl.org>
Date: Wed May 23 23:47:15 2018

UPSTREAM: x86/boot: Add missing declaration of string functions

[ Upstream commit fac69d0efad08fc15e4dbfc116830782acc0dc9a ]

Add the missing declarations of basic string functions to string.h to allow
a clean build.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I128d4cde45210a8d62819854050cb23ca94b4624
Fixes: 5be865661516 ("String-handling functions for the new x86 setup code.")
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Link: http://lkml.kernel.org/r/1483781911-21399-1-git-send-email-hofrat@osadl.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit aff24165ba49f42332012661a6b2c040f2404c60
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068487

[modify] https://crrev.com/8d1dbb3925e7954259c655df076ddb8a9a513160/arch/x86/boot/string.c
[modify] https://crrev.com/8d1dbb3925e7954259c655df076ddb8a9a513160/arch/x86/boot/string.h

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

commit 1154d89393507ea8fe247db67ca365eae1f4b3d8
Author: Arnd Bergmann <arnd@arndb.de>
Date: Wed May 23 23:47:16 2018

UPSTREAM: x86/io: Add "memory" clobber to insb/insw/insl/outsb/outsw/outsl

commit 7206f9bf108eb9513d170c73f151367a1bdf3dbf upstream.

The x86 version of insb/insw/insl uses an inline assembly that does
not have the target buffer listed as an output. This can confuse
the compiler, leading it to think that a subsequent access of the
buffer is uninitialized:

  drivers/net/wireless/wl3501_cs.c: In function wl3501_mgmt_scan_confirm:
  drivers/net/wireless/wl3501_cs.c:665:9: error: sig.status is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/wireless/wl3501_cs.c:668:12: error: sig.cap_info may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c: In function 'sb1000_rx':
  drivers/net/sb1000.c:775:9: error: 'st[0]' is used uninitialized in this function [-Werror=uninitialized]
  drivers/net/sb1000.c:776:10: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
  drivers/net/sb1000.c:784:11: error: 'st[1]' may be used uninitialized in this function [-Werror=maybe-uninitialized]

I tried to mark the exact input buffer as an output here, but couldn't
figure it out. As suggested by Linus, marking all memory as clobbered
however is good enough too. For the outs operations, I also add the
memory clobber, to force the input to be written to local variables.
This is probably already guaranteed by the "asm volatile", but it can't
hurt to do this for symmetry.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5747e67484fee8d44c1e196c352baa6398724962
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Link: http://lkml.kernel.org/r/20170719125310.2487451-5-arnd@arndb.de
Link: https://lkml.org/lkml/2017/7/12/605
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f2888dd24d315db4fc35cc610eb205d387904e69
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068488

[modify] https://crrev.com/1154d89393507ea8fe247db67ca365eae1f4b3d8/arch/x86/include/asm/io.h

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

commit ed38714a2df803c0013bfe809acc179d49696b9c
Author: Jan Beulich <JBeulich@suse.com>
Date: Wed May 23 23:47:18 2018

UPSTREAM: x86-64: Handle PC-relative relocations on per-CPU data

commit 6d24c5f72dfb26e5fa7f02fa9266dfdbae41adba upstream.

This is in preparation of using RIP-relative addressing in many of the
per-CPU accesses.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I7799086a432928b251845daaec47d84d55b3c2ed
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Link: http://lkml.kernel.org/r/5458A15A0200007800044A9A@mail.emea.novell.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit edb9d2d5e647e7a8521b0d35f8452deb02dfd138
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068489

[modify] https://crrev.com/ed38714a2df803c0013bfe809acc179d49696b9c/arch/x86/tools/relocs.c
[modify] https://crrev.com/ed38714a2df803c0013bfe809acc179d49696b9c/arch/x86/boot/compressed/misc.c

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

commit b11bf3079659486c269e9387903cab25cd3decad
Author: Markus Trippelsdorf <markus@trippelsdorf.de>
Date: Wed May 23 23:47:19 2018

UPSTREAM: x86/tools: Fix gcc-7 warning in relocs.c

commit 7ebb916782949621ff6819acf373a06902df7679 upstream.

gcc-7 warns:

In file included from arch/x86/tools/relocs_64.c:17:0:
arch/x86/tools/relocs.c: In function process_64:
arch/x86/tools/relocs.c:953:2: warning: argument 1 null where non-null expected [-Wnonnull]
  qsort(r->offset, r->count, sizeof(r->offset[0]), cmp_relocs);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from arch/x86/tools/relocs.h:6:0,
                 from arch/x86/tools/relocs_64.c:1:
/usr/include/stdlib.h:741:13: note: in a call to function qsort declared here
 extern void qsort

This happens because relocs16 is not used for ELF_BITS == 64,
so there is no point in trying to sort it.

Make the sort_relocs(&relocs16) call 32bit only.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I5799baf2ca87de4ebaf54d43b75a3e050483d1aa
Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Link: http://lkml.kernel.org/r/20161215124513.GA289@x4
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b82e2aa8aaa7642bc5ca01e839b4e5881f067d05
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068490

[modify] https://crrev.com/b11bf3079659486c269e9387903cab25cd3decad/arch/x86/tools/relocs.c

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

commit ae7ec34406eeabb56c2795e73a058f835c9efd5d
Author: Eric Biggers <ebiggers@google.com>
Date: Wed May 23 23:47:21 2018

UPSTREAM: x86/fpu: Don't let userspace set bogus xcomp_bv

commit 814fb7bb7db5433757d76f4c4502c96fc53b0b5e upstream.

[Please apply to 3.18-stable.  Note: the backport includes the
fpu_finit() call in xstateregs_set(), since fix is useless without it.
It was added by commit 91c3dba7dbc1 ("x86/fpu/xstate: Fix PTRACE frames
for XSAVES"), but it doesn't make sense to backport that whole commit.]

On x86, userspace can use the ptrace() or rt_sigreturn() system calls to
set a task's extended state (xstate) or "FPU" registers.  ptrace() can
set them for another task using the PTRACE_SETREGSET request with
NT_X86_XSTATE, while rt_sigreturn() can set them for the current task.
In either case, registers can be set to any value, but the kernel
assumes that the XSAVE area itself remains valid in the sense that the
CPU can restore it.

However, in the case where the kernel is using the uncompacted xstate
format (which it does whenever the XSAVES instruction is unavailable),
it was possible for userspace to set the xcomp_bv field in the
xstate_header to an arbitrary value.  However, all bits in that field
are reserved in the uncompacted case, so when switching to a task with
nonzero xcomp_bv, the XRSTOR instruction failed with a #GP fault.  This
caused the WARN_ON_FPU(err) in copy_kernel_to_xregs() to be hit.  In
addition, since the error is otherwise ignored, the FPU registers from
the task previously executing on the CPU were leaked.

Fix the bug by checking that the user-supplied value of xcomp_bv is 0 in
the uncompacted case, and returning an error otherwise.

The reason for validating xcomp_bv rather than simply overwriting it
with 0 is that we want userspace to see an error if it (incorrectly)
provides an XSAVE area in compacted format rather than in uncompacted
format.

Note that as before, in case of error we clear the task's FPU state.
This is perhaps non-ideal, especially for PTRACE_SETREGSET; it might be
better to return an error before changing anything.  But it seems the
"clear on error" behavior is fine for now, and it's a little tricky to
do otherwise because it would mean we couldn't simply copy the full
userspace state into kernel memory in one __copy_from_user().

This bug was found by syzkaller, which hit the above-mentioned
WARN_ON_FPU():

    WARNING: CPU: 1 PID: 0 at ./arch/x86/include/asm/fpu/internal.h:373 __switch_to+0x5b5/0x5d0
    CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.13.0 #453
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff9ba2bc8e42c0 task.stack: ffffa78cc036c000
    RIP: 0010:__switch_to+0x5b5/0x5d0
    RSP: 0000:ffffa78cc08bbb88 EFLAGS: 00010082
    RAX: 00000000fffffffe RBX: ffff9ba2b8bf2180 RCX: 00000000c0000100
    RDX: 00000000ffffffff RSI: 000000005cb10700 RDI: ffff9ba2b8bf36c0
    RBP: ffffa78cc08bbbd0 R08: 00000000929fdf46 R09: 0000000000000001
    R10: 0000000000000000 R11: 0000000000000000 R12: ffff9ba2bc8e42c0
    R13: 0000000000000000 R14: ffff9ba2b8bf3680 R15: ffff9ba2bf5d7b40
    FS:  00007f7e5cb10700(0000) GS:ffff9ba2bf400000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00000000004005cc CR3: 0000000079fd5000 CR4: 00000000001406e0
    Call Trace:
    Code: 84 00 00 00 00 00 e9 11 fd ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 e7 fa ff ff 0f ff 66 0f 1f 84 00 00 00 00 00 e9 c2 fa ff ff <0f> ff 66 0f 1f 84 00 00 00 00 00 e9 d4 fc ff ff 66 66 2e 0f 1f

Here is a C reproducer.  The expected behavior is that the program spin
forever with no output.  However, on a buggy kernel running on a
processor with the "xsave" feature but without the "xsaves" feature
(e.g. Sandy Bridge through Broadwell for Intel), within a second or two
the program reports that the xmm registers were corrupted, i.e. were not
restored correctly.  With CONFIG_X86_DEBUG_FPU=y it also hits the above
kernel warning.

    #define _GNU_SOURCE
    #include <stdbool.h>
    #include <inttypes.h>
    #include <linux/elf.h>
    #include <stdio.h>
    #include <sys/ptrace.h>
    #include <sys/uio.h>
    #include <sys/wait.h>
    #include <unistd.h>

    int main(void)
    {
        int pid = fork();
        uint64_t xstate[512];
        struct iovec iov = { .iov_base = xstate, .iov_len = sizeof(xstate) };

        if (pid == 0) {
            bool tracee = true;
            for (int i = 0; i < sysconf(_SC_NPROCESSORS_ONLN) && tracee; i++)
                tracee = (fork() != 0);
            uint32_t xmm0[4] = { [0 ... 3] = tracee ? 0x00000000 : 0xDEADBEEF };
            asm volatile("   movdqu %0, %%xmm0\n"
                         "   mov %0, %%rbx\n"
                         "1: movdqu %%xmm0, %0\n"
                         "   mov %0, %%rax\n"
                         "   cmp %%rax, %%rbx\n"
                         "   je 1b\n"
                         : "+m" (xmm0) : : "rax", "rbx", "xmm0");
            printf("BUG: xmm registers corrupted!  tracee=%d, xmm0=%08X%08X%08X%08X\n",
                   tracee, xmm0[0], xmm0[1], xmm0[2], xmm0[3]);
        } else {
            usleep(100000);
            ptrace(PTRACE_ATTACH, pid, 0, 0);
            wait(NULL);
            ptrace(PTRACE_GETREGSET, pid, NT_X86_XSTATE, &iov);
            xstate[65] = -1;
            ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov);
            ptrace(PTRACE_CONT, pid, 0, 0);
            wait(NULL);
        }
        return 1;
    }

Note: the program only tests for the bug using the ptrace() system call.
The bug can also be reproduced using the rt_sigreturn() system call, but
only when called from a 32-bit program, since for 64-bit programs the
kernel restores the FPU state from the signal frame by doing XRSTOR
directly from userspace memory (with proper error checking).

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I061ec2014f81d114aba1c5340bc0018abfc5905d
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Eric Biggers <ebiggers3@gmail.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Kevin Hao <haokexin@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Halcrow <mhalcrow@google.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: Yu-cheng Yu <yu-cheng.yu@intel.com>
Cc: kernel-hardening@lists.openwall.com
Fixes: 0b29643a5843 ("x86/xsaves: Change compacted format xsave area header")
Link: http://lkml.kernel.org/r/20170922174156.16780-2-ebiggers3@gmail.com
Link: http://lkml.kernel.org/r/20170923130016.21448-25-mingo@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit f23ec06d527c9cd90552a68c748bcb5aa942ee87
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068491

[modify] https://crrev.com/ae7ec34406eeabb56c2795e73a058f835c9efd5d/arch/x86/kernel/i387.c
[modify] https://crrev.com/ae7ec34406eeabb56c2795e73a058f835c9efd5d/arch/x86/kernel/xsave.c

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

commit 76e6670ab3cea5600acf8bb79ccbe45aedb2f54c
Author: Haozhong Zhang <haozhong.zhang@intel.com>
Date: Wed May 23 23:47:22 2018

UPSTREAM: KVM: nVMX: fix guest CR4 loading when emulating L2 to L1 exit

commit 8eb3f87d903168bdbd1222776a6b1e281f50513e upstream.

When KVM emulates an exit from L2 to L1, it loads L1 CR4 into the
guest CR4. Before this CR4 loading, the guest CR4 refers to L2
CR4. Because these two CR4's are in different levels of guest, we
should vmx_set_cr4() rather than kvm_set_cr4() here. The latter, which
is used to handle guest writes to its CR4, checks the guest change to
CR4 and may fail if the change is invalid.

The failure may cause trouble. Consider we start
  a L1 guest with non-zero L1 PCID in use,
     (i.e. L1 CR4.PCIDE == 1 && L1 CR3.PCID != 0)
and
  a L2 guest with L2 PCID disabled,
     (i.e. L2 CR4.PCIDE == 0)
and following events may happen:

1. If kvm_set_cr4() is used in load_vmcs12_host_state() to load L1 CR4
   into guest CR4 (in VMCS01) for L2 to L1 exit, it will fail because
   of PCID check. As a result, the guest CR4 recorded in L0 KVM (i.e.
   vcpu->arch.cr4) is left to the value of L2 CR4.

2. Later, if L1 attempts to change its CR4, e.g., clearing VMXE bit,
   kvm_set_cr4() in L0 KVM will think L1 also wants to enable PCID,
   because the wrong L2 CR4 is used by L0 KVM as L1 CR4. As L1
   CR3.PCID != 0, L0 KVM will inject GP to L1 guest.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ie789ec550e7114c3268eb3a42d93773b3e18595d
Fixes: 4704d0befb072 ("KVM: nVMX: Exiting from L2 to L1")
Cc: qemu-stable@nongnu.org
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e4a25d305457fcb7119ceaa94f85c1a82d1e0076
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068492

[modify] https://crrev.com/76e6670ab3cea5600acf8bb79ccbe45aedb2f54c/arch/x86/kvm/vmx.c

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

commit 52adc58b973a8ed3de7b84506293e144d2b6a393
Author: Borislav Petkov <bp@suse.de>
Date: Wed May 23 23:47:23 2018

UPSTREAM: x86/microcode/intel: Disable late loading on model 79

commit 723f2828a98c8ca19842042f418fb30dd8cfc0f7 upstream.

Blacklist Broadwell X model 79 for late loading due to an erratum.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ibaaf8c09263104dabcc63567abebae4f9873fa90
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Tony Luck <tony.luck@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20171018111225.25635-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6c3c4c7373de9d0891e874f710aaee833e937f40
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068493

[modify] https://crrev.com/52adc58b973a8ed3de7b84506293e144d2b6a393/arch/x86/kernel/cpu/microcode/intel.c

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

commit d8781be441fd8a08284ddb30fcc7c2d122ecd40f
Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
Date: Wed May 23 23:47:25 2018

UPSTREAM: crypto: x86/sha1-mb - fix panic due to unaligned access

commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream.

struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc()
and later passed in sha1_mb_flusher_mgr_flush_avx2() function where
instructions vmovdqa used to access the struct. vmovdqa requires
16-bytes aligned argument, but nothing guarantees that struct
sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will
generate GP fault.

Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
requirements.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Iaaef62d00ed6b5a9a95e38f35d49099230f7ad9f
Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cb870a365af45b69b4bcb3323066a681e37ed4aa
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068494

[modify] https://crrev.com/d8781be441fd8a08284ddb30fcc7c2d122ecd40f/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S

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

commit 3596eb55dd13009955230588c3d43468c0033ab2
Author: Borislav Petkov <bp@suse.de>
Date: Wed May 23 23:47:26 2018

UPSTREAM: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context

commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.

The warning below says it all:

  BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1
  caller is __this_cpu_preempt_check
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
  Call Trace:
   dump_stack
   check_preemption_disabled
   ? do_early_param
   __this_cpu_preempt_check
   arch_perfmon_init
   op_nmi_init
   ? alloc_pci_root_info
   oprofile_arch_init
   oprofile_init
   do_one_initcall
   ...

These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic358c794a9ba0239d6c7e3ca8ac2d251cded2464
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Robert Richter <rric@kernel.org>
Cc: x86@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 76bb85f25229bbde79ff64c2ea6d86f18ab99b26
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068495

[modify] https://crrev.com/3596eb55dd13009955230588c3d43468c0033ab2/arch/x86/oprofile/op_model_ppro.c

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

commit e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f
Author: Bilal Amarni <bilal.amarni@gmail.com>
Date: Wed May 23 23:47:27 2018

UPSTREAM: security/keys: add CONFIG_KEYS_COMPAT to Kconfig

commit 47b2c3fff4932e6fc17ce13d51a43c6969714e20 upstream.

CONFIG_KEYS_COMPAT is defined in arch-specific Kconfigs and is missing for
several 64-bit architectures : mips, parisc, tile.

At the moment and for those architectures, calling in 32-bit userspace the
keyctl syscall would return an ENOSYS error.

This patch moves the CONFIG_KEYS_COMPAT option to security/keys/Kconfig, to
make sure the compatibility wrapper is registered by default for any 64-bit
architecture as long as it is configured with CONFIG_COMPAT.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I7adc0fc71d65a68b0f16bf9aa550341c124df4f9
[DH: Modified to remove arm64 compat enablement also as requested by Eric
 Biggers]
Signed-off-by: Bilal Amarni <bilal.amarni@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
cc: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Cc: James Cowgill <james.cowgill@mips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 86fa24082f80e1f3b2641f164bbe5d5834abc581
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068496

[modify] https://crrev.com/e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f/security/keys/Kconfig
[modify] https://crrev.com/e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f/arch/powerpc/Kconfig
[modify] https://crrev.com/e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f/arch/x86/Kconfig
[modify] https://crrev.com/e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f/arch/sparc/Kconfig
[modify] https://crrev.com/e8f7d0f828e0102767f27dfc0c1d9d07d8cb3e5f/arch/s390/Kconfig

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

commit 529ff4d906f4a6e10653f244987e10ec713e858f
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed May 23 23:47:29 2018

UPSTREAM: x86/decoder: Add new TEST instruction pattern

commit 12a78d43de767eaf8fb272facb7a7b6f2dc6a9df upstream.

The kbuild test robot reported this build warning:

  Warning: arch/x86/tools/test_get_len found difference at <jump_table>:ffffffff8103dd2c

  Warning: ffffffff8103dd82: f6 09 d8 testb $0xd8,(%rcx)
  Warning: objdump says 3 bytes, but insn_get_length() says 2
  Warning: decoded and checked 1569014 instructions with 1 warnings

This sequence seems to be a new instruction not in the opcode map in the Intel SDM.

The instruction sequence is "F6 09 d8", means Group3(F6), MOD(00)REG(001)RM(001), and 0xd8.
Intel SDM vol2 A.4 Table A-6 said the table index in the group is "Encoding of Bits 5,4,3 of
the ModR/M Byte (bits 2,1,0 in parenthesis)"

In that table, opcodes listed by the index REG bits as:

  000         001       010 011  100        101        110         111
 TEST Ib/Iz,(undefined),NOT,NEG,MUL AL/rAX,IMUL AL/rAX,DIV AL/rAX,IDIV AL/rAX

So, it seems TEST Ib is assigned to 001.

Add the new pattern.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I68c296a6ad826f9bdf2e372db2150a4d8b3e2411
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a63a5859bc4aba1bb1ebda952aaf26d51f673012
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068497

[modify] https://crrev.com/529ff4d906f4a6e10653f244987e10ec713e858f/arch/x86/lib/x86-opcode-map.txt

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

commit 6451dff793f7365717c307fa0365cb40521dd616
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 23:47:32 2018

UPSTREAM: KVM: SVM: obey guest PAT

commit 15038e14724799b8c205beb5f20f9e54896013c3 upstream.

For many years some users of assigned devices have reported worse
performance on AMD processors with NPT than on AMD without NPT,
Intel or bare metal.

The reason turned out to be that SVM is discarding the guest PAT
setting and uses the default (PA0=PA4=WB, PA1=PA5=WT, PA2=PA6=UC-,
PA3=UC).  The guest might be using a different setting, and
especially might want write combining but isn't getting it
(instead getting slow UC or UC- accesses).

Thanks a lot to geoff@hostfission.com for noticing the relation
to the g_pat setting.  The patch has been tested also by a bunch
of people on VFIO users forums.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic05ae885093db898d0167785b9431fda2b204cdb
Fixes: 709ddebf81cb40e3c36c6109a7892e8b93a09464
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196409
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5f8a3df04772b367a1b18c943b7e1671ad9fd9e9
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068499

[modify] https://crrev.com/6451dff793f7365717c307fa0365cb40521dd616/arch/x86/kvm/svm.c

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

commit 56b398bbee3259aaf0cefec68eac28554974265a
Author: Ladi Prosek <lprosek@redhat.com>
Date: Wed May 23 23:47:30 2018

UPSTREAM: KVM: nVMX: set IDTR and GDTR limits when loading L1 host state

commit 21f2d551183847bc7fbe8d866151d00cdad18752 upstream.

Intel SDM 27.5.2 Loading Host Segment and Descriptor-Table Registers:

"The GDTR and IDTR limits are each set to FFFFH."

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Idb52aae17474bf5acc49b82a37885a07210382fd
Signed-off-by: Ladi Prosek <lprosek@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 27cd63fee6964d5af2004298f69cadaae71708e4
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068498

[modify] https://crrev.com/56b398bbee3259aaf0cefec68eac28554974265a/arch/x86/kvm/vmx.c

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

commit afa0b1784c85b724441b451d7d5676def6062965
Author: Liran Alon <liran.alon@oracle.com>
Date: Wed May 23 23:47:33 2018

UPSTREAM: KVM: x86: Exit to user-mode on #UD intercept when emulator requires

commit 61cb57c9ed631c95b54f8e9090c89d18b3695b3c upstream.

Instruction emulation after trapping a #UD exception can result in an
MMIO access, for example when emulating a MOVBE on a processor that
doesn't support the instruction.  In this case, the #UD vmexit handler
must exit to user mode, but there wasn't any code to do so.  Add it for
both VMX and SVM.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic60eed15b36133603d7ce46f1393f727e9ceca0a
Signed-off-by: Liran Alon <liran.alon@oracle.com>
Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ccabc053d5b8f88573cd6ea7e1d7e4d701b15971
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068500

[modify] https://crrev.com/afa0b1784c85b724441b451d7d5676def6062965/arch/x86/kvm/svm.c
[modify] https://crrev.com/afa0b1784c85b724441b451d7d5676def6062965/arch/x86/kvm/vmx.c

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

commit dfa33c60a4a554da3a5ec6926b9f2827155b09c8
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed May 23 23:47:35 2018

UPSTREAM: KVM: x86: inject exceptions produced by x86_decode_insn

commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 upstream.

Sometimes, a processor might execute an instruction while another
processor is updating the page tables for that instruction's code page,
but before the TLB shootdown completes.  The interesting case happens
if the page is in the TLB.

In general, the processor will succeed in executing the instruction and
nothing bad happens.  However, what if the instruction is an MMIO access?
If *that* happens, KVM invokes the emulator, and the emulator gets the
updated page tables.  If the update side had marked the code page as non
present, the page table walk then will fail and so will x86_decode_insn.

Unfortunately, even though kvm_fetch_guest_virt is correctly returning
X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
a fatal error if the instruction cannot simply be reexecuted (as is the
case for MMIO).  And this in fact happened sometimes when rebooting
Windows 2012r2 guests.  Just checking ctxt->have_exception and injecting
the exception if true is enough to fix the case.

Thanks to Eduardo Habkost for helping in the debugging of this issue.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Id97677ce5d70e965da1ff897366c03dd15a76cb8
Reported-by: Yanan Fu <yfu@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 092b0115002b27fdbea3026bd18a6481fe67a50d
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068501

[modify] https://crrev.com/dfa33c60a4a554da3a5ec6926b9f2827155b09c8/arch/x86/kvm/x86.c

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

commit 79f60486f0d3e958fdc79d124d7fdd6cb2a832bb
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Wed May 23 23:47:36 2018

UPSTREAM: x86/PCI: Make broadcom_postcore_init() check acpi_disabled

commit ddec3bdee05b06f1dda20ded003c3e10e4184cab upstream.

acpi_os_get_root_pointer() may return a valid address even if acpi_disabled
is set, but the host bridge information from the ACPI tables is not going
to be used in that case and the Broadcom host bridge initialization should
not be skipped then, So make broadcom_postcore_init() check acpi_disabled
too to avoid this issue.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ia3ea16a03fbcf631f7e7b2e4d578a3da5bc8d195
Fixes: 6361d72b04d1 (x86/PCI: read Broadcom CNB20LE host bridge info before PCI scan)
Reported-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linux PCI <linux-pci@vger.kernel.org>
Link: https://lkml.kernel.org/r/3186627.pxZj1QbYNg@aspire.rjw.lan
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 346178f1aa5e082f5cfbe94affcbfa1e9d6086df
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068502

[modify] https://crrev.com/79f60486f0d3e958fdc79d124d7fdd6cb2a832bb/arch/x86/pci/broadcom_bus.c

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

commit fd728f25ad610b1586a7903bec61146ff1beab56
Author: Andrew Honig <ahonig@google.com>
Date: Wed May 23 23:47:37 2018

UPSTREAM: KVM: VMX: remove I/O port 0x80 bypass on Intel hosts

commit d59d51f088014f25c2562de59b9abff4f42a7468 upstream.

This fixes CVE-2017-1000407.

KVM allows guests to directly access I/O port 0x80 on Intel hosts.  If
the guest floods this port with writes it generates exceptions and
instability in the host kernel, leading to a crash.  With this change
guest writes to port 0x80 on Intel will behave the same as they
currently behave on AMD systems.

Prevent the flooding by removing the code that sets port 0x80 as a
passthrough port.  This is essentially the same as upstream patch
99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
for AMD chipsets and this patch is for Intel.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I09052eeacf32c82688636270154ac8fd7a650d34
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Fixes: fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs")
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7389171fdc5976066573edd1fcf6c9a81d8df90f
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068503

[modify] https://crrev.com/fd728f25ad610b1586a7903bec61146ff1beab56/arch/x86/kvm/vmx.c

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

commit a7e2e14426103c6a6a89680795ca84a2669ab4be
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:39 2018

UPSTREAM: KVM: nVMX: reset nested_run_pending if the vCPU is going to be reset

[ Upstream commit 2f707d97982286b307ef2a9b034e19aabc1abb56 ]

Reported by syzkaller:

    WARNING: CPU: 1 PID: 27742 at arch/x86/kvm/vmx.c:11029
    nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
    CPU: 1 PID: 27742 Comm: a.out Not tainted 4.10.0+ #229
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    Call Trace:
     __dump_stack lib/dump_stack.c:15 [inline]
     dump_stack+0x2ee/0x3ef lib/dump_stack.c:51
     panic+0x1fb/0x412 kernel/panic.c:179
     __warn+0x1c4/0x1e0 kernel/panic.c:540
     warn_slowpath_null+0x2c/0x40 kernel/panic.c:583
     nested_vmx_vmexit+0x5c35/0x74d0 arch/x86/kvm/vmx.c:11029
     vmx_leave_nested arch/x86/kvm/vmx.c:11136 [inline]
     vmx_set_msr+0x1565/0x1910 arch/x86/kvm/vmx.c:3324
     kvm_set_msr+0xd4/0x170 arch/x86/kvm/x86.c:1099
     do_set_msr+0x11e/0x190 arch/x86/kvm/x86.c:1128
     __msr_io arch/x86/kvm/x86.c:2577 [inline]
     msr_io+0x24b/0x450 arch/x86/kvm/x86.c:2614
     kvm_arch_vcpu_ioctl+0x35b/0x46a0 arch/x86/kvm/x86.c:3497
     kvm_vcpu_ioctl+0x232/0x1120 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2721
     vfs_ioctl fs/ioctl.c:43 [inline]
     do_vfs_ioctl+0x1bf/0x1790 fs/ioctl.c:683
     SYSC_ioctl fs/ioctl.c:698 [inline]
     SyS_ioctl+0x8f/0xc0 fs/ioctl.c:689
     entry_SYSCALL_64_fastpath+0x1f/0xc2

The syzkaller folks reported a nested_run_pending warning during userspace
clear VMX capability which is exposed to L1 before.

The warning gets thrown while doing

(*(uint32_t*)0x20aecfe8 = (uint32_t)0x1);
(*(uint32_t*)0x20aecfec = (uint32_t)0x0);
(*(uint32_t*)0x20aecff0 = (uint32_t)0x3a);
(*(uint32_t*)0x20aecff4 = (uint32_t)0x0);
(*(uint64_t*)0x20aecff8 = (uint64_t)0x0);
r[29] = syscall(__NR_ioctl, r[4], 0x4008ae89ul,
		0x20aecfe8ul, 0, 0, 0, 0, 0, 0);

i.e. KVM_SET_MSR ioctl with

struct kvm_msrs {
	.nmsrs = 1,
		.pad = 0,
		.entries = {
			{.index = MSR_IA32_FEATURE_CONTROL,
			 .reserved = 0,
			 .data = 0}
		}
}

The VMLANCH/VMRESUME emulation should be stopped since the CPU is going to
reset here. This patch resets the nested_run_pending since the CPU is going
to be reset hence there should be nothing pending.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I84d8c6b519846087b0ac0850def3991ca040ce2e
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Suggested-by: Radim Krm <rkrcmar@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: David Hildenbrand <david@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Jim Mattson <jmattson@google.com>
Signed-off-by: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ab8447147ba09ec7d44e6cfe3f2ad7bb5128bf13
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068504

[modify] https://crrev.com/a7e2e14426103c6a6a89680795ca84a2669ab4be/arch/x86/kvm/vmx.c

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

commit 7cecb3a9f10258bf209b368e5d86e43fd88ddb01
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:40 2018

UPSTREAM: KVM: x86: correct async page present tracepoint

[ Upstream commit 24dccf83a121b8a4ad5c2ad383a8184ef6c266ee ]

After async pf setup successfully, there is a broadcast wakeup w/ special
token 0xffffffff which tells vCPU that it should wake up all processes
waiting for APFs though there is no real process waiting at the moment.

The async page present tracepoint print prematurely and fails to catch the
special token setup. This patch fixes it by moving the async page present
tracepoint after the special token setup.

Before patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0x0 gva 0x0

After patch:

qemu-system-x86-8499  [006] ...1  5973.473292: kvm_async_pf_ready: token 0xffffffff gva 0x0

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: I8864e5b80a7f209dc5620aa1bbdd112cb5da9ce9
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 06afa2da5165b854926ea5bf70d88c950ba0128b
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068505

[modify] https://crrev.com/7cecb3a9f10258bf209b368e5d86e43fd88ddb01/arch/x86/kvm/x86.c

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

commit 7b8a3c85d4e17ffe50bbf38c08e4a213b7c14dba
Author: Wanpeng Li <wanpeng.li@hotmail.com>
Date: Wed May 23 23:47:42 2018

UPSTREAM: KVM: X86: Fix load RFLAGS w/o the fixed bit

commit d73235d17ba63b53dc0e1051dbc10a1f1be91b71 upstream.

 *** Guest State ***
 CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
 CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871
 CR3 = 0x00000000fffbc000
 RSP = 0x0000000000000000  RIP = 0x0000000000000000
 RFLAGS=0x00000000         DR7 = 0x0000000000000400
        ^^^^^^^^^^

The failed vmentry is triggered by the following testcase when ept=Y:

    #include <unistd.h>
    #include <sys/syscall.h>
    #include <string.h>
    #include <stdint.h>
    #include <linux/kvm.h>
    #include <fcntl.h>
    #include <sys/ioctl.h>

    long r[5];
    int main()
    {
    	r[2] = open("/dev/kvm", O_RDONLY);
    	r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
    	r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
    	struct kvm_regs regs = {
    		.rflags = 0,
    	};
    	ioctl(r[4], KVM_SET_REGS, &regs);
    	ioctl(r[4], KVM_RUN, 0);
    }

X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1
of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails.
This patch fixes it by oring X86_EFLAGS_FIXED during ioctl.

BUG=chromium:842936
TEST=build/boot on caroline with USE=kvm_host

Change-Id: Ic4096b27e11a025707974af08fdd14bb9b0e106c
Suggested-by: Jim Mattson <jmattson@google.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Quan Xu <quan.xu0@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krm <rkrcmar@redhat.com>
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 02952cd43e16b4be10e5f49a03fc3256fb10de1e
 in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/)
Signed-off-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068506
Reviewed-by: Dylan Reid <dgreid@chromium.org>

[modify] https://crrev.com/7b8a3c85d4e17ffe50bbf38c08e4a213b7c14dba/arch/x86/kvm/x86.c