linux-stable.git/arch, branch v4.14.151

kvm: vmx: Basic APIC virtualization controls have three settings

2019-10-29T08:17:48+00:00

commit 8d860bbeedef97fe981d28fa7b71d77f3b29563f upstream.

Previously, we toggled between SECONDARY_EXEC_VIRTUALIZE_X2APIC_MODE
and SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES, depending on whether or
not the EXTD bit was set in MSR_IA32_APICBASE. However, if the local
APIC is disabled, we should not set either of these APIC
virtualization control bits.

Signed-off-by: Jim Mattson 
Signed-off-by: Krish Sadhukhan 
Signed-off-by: Paolo Bonzini 
Cc: "Jitindar SIngh, Suraj" 
Signed-off-by: Greg Kroah-Hartman

kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use

2019-10-29T08:17:47+00:00

commit a468f2dbf921d02f5107378501693137a812999b upstream.

Currently, KVM flushes the TLB after a change to the APIC access page
address or the APIC mode when EPT mode is enabled. However, even in
shadow paging mode, a TLB flush is needed if VPIDs are being used, as
specified in the Intel SDM Section 29.4.5.

So replace vmx_flush_tlb_ept_only() with vmx_flush_tlb(), which will
flush if either EPT or VPIDs are in use.

Signed-off-by: Junaid Shahid 
Reviewed-by: Jim Mattson 
Signed-off-by: Radim Krčmář 
Cc: "Jitindar SIngh, Suraj" 
Signed-off-by: Greg Kroah-Hartman

kvm: vmx: Introduce lapic_mode enumeration

2019-10-29T08:17:46+00:00

commit 588716494258899389206fa50426e78cc9df89b9 upstream.

The local APIC can be in one of three modes: disabled, xAPIC or
x2APIC. (A fourth mode, "invalid," is included for completeness.)

Using the new enumeration can make some of the APIC mode logic easier
to read. In kvm_set_apic_base, for instance, it is clear that one
cannot transition directly from x2APIC mode to xAPIC mode or directly
from APIC disabled to x2APIC mode.

Signed-off-by: Jim Mattson 
Signed-off-by: Krish Sadhukhan 
[Check invalid bits even if msr_info->host_initiated.  Reported by
 Wanpeng Li. - Paolo]
Signed-off-by: Paolo Bonzini 
Cc: "Jitindar SIngh, Suraj" 
Signed-off-by: Greg Kroah-Hartman

KVM: X86: introduce invalidate_gpa argument to tlb flush

2019-10-29T08:17:46+00:00

commit c2ba05ccfde2f069a66c0462e5b5ef8a517dcc9c upstream.

Introduce a new bool invalidate_gpa argument to kvm_x86_ops->tlb_flush,
it will be used by later patches to just flush guest tlb.

For VMX, this will use INVVPID instead of INVEPT, which will invalidate
combined mappings while keeping guest-physical mappings.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Peter Zijlstra 
Cc: "Jitindar SIngh, Suraj" 
Signed-off-by: Wanpeng Li 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Radim Krčmář 
Signed-off-by: Greg Kroah-Hartman

x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area

2019-10-29T08:17:41+00:00

commit 2aa85f246c181b1fa89f27e8e20c5636426be624 upstream.

Our hardware (UV aka Superdome Flex) has address ranges marked
reserved by the BIOS. Access to these ranges is caught as an error,
causing the BIOS to halt the system.

Initial page tables mapped a large range of physical addresses that
were not checked against the list of BIOS reserved addresses, and
sometimes included reserved addresses in part of the mapped range.
Including the reserved range in the map allowed processor speculative
accesses to the reserved range, triggering a BIOS halt.

Used early in booting, the page table level2_kernel_pgt addresses 1
GiB divided into 2 MiB pages, and it was set up to linearly map a full
 1 GiB of physical addresses that included the physical address range
of the kernel image, as chosen by KASLR.  But this also included a
large range of unused addresses on either side of the kernel image.
And unlike the kernel image's physical address range, this extra
mapped space was not checked against the BIOS tables of usable RAM
addresses.  So there were times when the addresses chosen by KASLR
would result in processor accessible mappings of BIOS reserved
physical addresses.

The kernel code did not directly access any of this extra mapped
space, but having it mapped allowed the processor to issue speculative
accesses into reserved memory, causing system halts.

This was encountered somewhat rarely on a normal system boot, and much
more often when starting the crash kernel if "crashkernel=512M,high"
was specified on the command line (this heavily restricts the physical
address of the crash kernel, in our case usually within 1 GiB of
reserved space).

The solution is to invalidate the pages of this table outside the kernel
image's space before the page table is activated. It fixes this problem
on our hardware.

 [ bp: Touchups. ]

Signed-off-by: Steve Wahl 
Signed-off-by: Borislav Petkov 
Acked-by: Dave Hansen 
Acked-by: Kirill A. Shutemov 
Cc: Baoquan He 
Cc: Brijesh Singh 
Cc: dimitri.sivanich@hpe.com
Cc: Feng Tang 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jordan Borgner 
Cc: Juergen Gross 
Cc: mike.travis@hpe.com
Cc: russ.anderson@hpe.com
Cc: stable@vger.kernel.org
Cc: Thomas Gleixner 
Cc: x86-ml 
Cc: Zhenzhong Duan 
Link: https://lkml.kernel.org/r/9c011ee51b081534a7a15065b1681d200298b530.1569358539.git.steve.wahl@hpe.com
Signed-off-by: Greg Kroah-Hartman

parisc: Fix vmap memory leak in ioremap()/iounmap()

2019-10-29T08:17:40+00:00

commit 513f7f747e1cba81f28a436911fba0b485878ebd upstream.

Sven noticed that calling ioremap() and iounmap() multiple times leads
to a vmap memory leak:
	vmap allocation for size 4198400 failed:
	use vmalloc= to increase size

It seems we missed calling vunmap() in iounmap().

Signed-off-by: Helge Deller 
Noticed-by: Sven Schnelle 
Cc:  # v3.16+
Signed-off-by: Greg Kroah-Hartman

xtensa: drop EXPORT_SYMBOL for outs/ins

2019-10-29T08:17:40+00:00

commit 8b39da985194aac2998dd9e3a22d00b596cebf1e upstream.

Custom outs*/ins* implementations are long gone from the xtensa port,
remove matching EXPORT_SYMBOLs.
This fixes the following build warnings issued by modpost since commit
15bfc2348d54 ("modpost: check for static EXPORT_SYMBOL* functions"):

  WARNING: "insb" [vmlinux] is a static EXPORT_SYMBOL
  WARNING: "insw" [vmlinux] is a static EXPORT_SYMBOL
  WARNING: "insl" [vmlinux] is a static EXPORT_SYMBOL
  WARNING: "outsb" [vmlinux] is a static EXPORT_SYMBOL
  WARNING: "outsw" [vmlinux] is a static EXPORT_SYMBOL
  WARNING: "outsl" [vmlinux] is a static EXPORT_SYMBOL

Cc: stable@vger.kernel.org
Fixes: d38efc1f150f ("xtensa: adopt generic io routines")
Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

MIPS: tlbex: Fix build_restore_pagemask KScratch restore

2019-10-29T08:17:30+00:00

commit b42aa3fd5957e4daf4b69129e5ce752a2a53e7d6 upstream.

build_restore_pagemask() will restore the value of register $1/$at when
its restore_scratch argument is non-zero, and aims to do so by filling a
branch delay slot. Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0
-> mfc0 sequence.") added an EHB instruction (Execution Hazard Barrier)
prior to restoring $1 from a KScratch register, in order to resolve a
hazard that can result in stale values of the KScratch register being
observed. In particular, P-class CPUs from MIPS with out of order
execution pipelines such as the P5600 & P6600 are affected.

Unfortunately this EHB instruction was inserted in the branch delay slot
causing the MFC0 instruction which performs the restoration to no longer
execute along with the branch. The result is that the $1 register isn't
actually restored, ie. the TLB refill exception handler clobbers it -
which is exactly the problem the EHB is meant to avoid for the P-class
CPUs.

Similarly build_get_pgd_vmalloc() will restore the value of $1/$at when
its mode argument equals refill_scratch, and suffers from the same
problem.

Fix this by in both cases moving the EHB earlier in the emitted code.
There's no reason it needs to immediately precede the MFC0 - it simply
needs to be between the MTC0 & MFC0.

This bug only affects Cavium Octeon systems which use
build_fast_tlb_refill_handler().

Signed-off-by: Paul Burton 
Fixes: 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -> mfc0 sequence.")
Cc: Dmitry Korotin 
Cc: stable@vger.kernel.org # v3.15+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

arm64/speculation: Support 'mitigations=' cmdline option

2019-10-29T08:17:30+00:00

[ Upstream commit a111b7c0f20e13b54df2fa959b3dc0bdf1925ae6 ]

Configure arm64 runtime CPU speculation bug mitigations in accordance
with the 'mitigations=' cmdline option.  This affects Meltdown, Spectre
v2, and Speculative Store Bypass.

The default behavior is unchanged.

Signed-off-by: Josh Poimboeuf 
[will: reorder checks so KASLR implies KPTI and SSBS is affected by cmdline]
Signed-off-by: Will Deacon 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

arm64: Use firmware to detect CPUs that are not affected by Spectre-v2

2019-10-29T08:17:30+00:00

[ Upstream commit 517953c2c47f9c00a002f588ac856a5bc70cede3 ]

The SMCCC ARCH_WORKAROUND_1 service can indicate that although the
firmware knows about the Spectre-v2 mitigation, this particular
CPU is not vulnerable, and it is thus not necessary to call
the firmware on this CPU.

Let's use this information to our benefit.

Signed-off-by: Marc Zyngier 
Signed-off-by: Jeremy Linton 
Reviewed-by: Andre Przywara 
Reviewed-by: Catalin Marinas 
Tested-by: Stefan Wahren 
Signed-off-by: Will Deacon 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

linux-stable.git/arch, branch v4.14.151

kvm: vmx: Basic APIC virtualization controls have three settings

kvm: apic: Flush TLB after APIC mode/address change if VPIDs are in use

kvm: vmx: Introduce lapic_mode enumeration

KVM: X86: introduce invalidate_gpa argument to tlb flush

x86/boot/64: Make level2_kernel_pgt pages invalid outside kernel area

parisc: Fix vmap memory leak in ioremap()/iounmap()

xtensa: drop EXPORT_SYMBOL for outs*/ins*

MIPS: tlbex: Fix build_restore_pagemask KScratch restore

arm64/speculation: Support 'mitigations=' cmdline option

arm64: Use firmware to detect CPUs that are not affected by Spectre-v2

xtensa: drop EXPORT_SYMBOL for outs/ins