linux-stable.git/arch, branch v3.16.83

KVM: nVMX: Don't emulate instructions in guest mode

2020-04-28T18:03:40+00:00

commit 07721feee46b4b248402133228235318199b05ec upstream.

vmx_check_intercept is not yet fully implemented. To avoid emulating
instructions disallowed by the L1 hypervisor, refuse to emulate
instructions by default.

[Made commit, added commit msg - Oliver]
Signed-off-by: Oliver Upton 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

x86/efistub: Disable paging at mixed mode entry

2020-04-28T18:03:09+00:00

commit 4911ee401b7ceff8f38e0ac597cbf503d71e690c upstream.

The EFI mixed mode entry code goes through the ordinary startup_32()
routine before jumping into the kernel's EFI boot code in 64-bit
mode. The 32-bit startup code must be entered with paging disabled,
but this is not documented as a requirement for the EFI handover
protocol, and so we should disable paging explicitly when entering
the kernel from 32-bit EFI firmware.

Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Hans de Goede 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224132909.102540-4-ardb@kernel.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBD

2020-04-28T18:03:06+00:00

commit 396d2e878f92ec108e4293f1c77ea3bc90b414ff upstream.

The host reports support for the synthetic feature X86_FEATURE_SSBD
when any of the three following hardware features are set:
  CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31]
  CPUID.80000008H:EBX.AMD_SSBD[bit 24]
  CPUID.80000008H:EBX.VIRT_SSBD[bit 25]

Either of the first two hardware features implies the existence of the
IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does
not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be
set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or
CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host.

Fixes: 0c54914d0c52a ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code")
Signed-off-by: Jim Mattson 
Reviewed-by: Jacob Xu 
Reviewed-by: Peter Shier 
Cc: Paolo Bonzini 
Reported-by: Eric Biggers 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.16: adjust indentation]
Signed-off-by: Ben Hutchings

powerpc/irq: fix stack overflow verification

2020-04-28T18:03:03+00:00

commit 099bc4812f09155da77eeb960a983470249c9ce1 upstream.

Before commit 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of
the irq stack"), check_stack_overflow() was called by do_IRQ(), before
switching to the irq stack.
In that commit, do_IRQ() was renamed __do_irq(), and is now executing
on the irq stack, so check_stack_overflow() has just become almost
useless.

Move check_stack_overflow() call in do_IRQ() to do the check while
still on the current stack.

Fixes: 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of the irq stack")
Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/e033aa8116ab12b7ca9a9c75189ad0741e3b9b5f.1575872340.git.christophe.leroy@c-s.fr
Signed-off-by: Ben Hutchings

x86/pti/efi: broken conversion from efi to kernel page table

2020-04-28T18:02:37+00:00

In entry_64.S we have code like this:

    /* Unconditionally use kernel CR3 for do_nmi() */
    /* %rax is saved above, so OK to clobber here */
    ALTERNATIVE "jmp 2f", "movq %cr3, %rax", X86_FEATURE_KAISER
    /* If PCID enabled, NOFLUSH now and NOFLUSH on return */
    ALTERNATIVE "", "bts $63, %rax", X86_FEATURE_PCID
    pushq   %rax
    /* mask off "user" bit of pgd address and 12 PCID bits: */
    andq    $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax
    movq    %rax, %cr3
2:

    /* paranoidentry do_nmi, 0; without TRACE_IRQS_OFF */
    call    do_nmi

With this instruction:
    andq    $(~(X86_CR3_PCID_ASID_MASK | KAISER_SHADOW_PGD_OFFSET)), %rax

We unconditionally switch from whatever our CR3 was to kernel page table.
But, in arch/x86/platform/efi/efi_64.c We temporarily set a different page
table, that does not have the kernel page table with 0x1000 offset from it.

Look in efi_thunk() and efi_thunk_set_virtual_address_map().

So, while CR3 points to the other page table, we get an NMI interrupt,
and clear 0x1000 from CR3, resulting in a bogus CR3 if the 0x1000 bit was
set.

The efi page table comes from realmode/rm/trampoline_64.S:

arch/x86/realmode/rm/trampoline_64.S

141 .bss
142 .balign PAGE_SIZE
143 GLOBAL(trampoline_pgd) .space PAGE_SIZE

Notice: alignment is PAGE_SIZE, so after applying KAISER_SHADOW_PGD_OFFSET
which equal to PAGE_SIZE, we can get a different page table.

But, even if we fix alignment, here the trampoline binary is later copied
into dynamically allocated memory in reserve_real_mode(), so we need to
fix that place as well.

Fixes: f9a1666f97b3 ("KAISER: Kernel Address Isolation")
Signed-off-by: Pavel Tatashin 
Reviewed-by: Steven Sistare 
Signed-off-by: Greg Kroah-Hartman 
[bwh: Adjust the Fixes field for 3.16]
Signed-off-by: Ben Hutchings

x86/microcode/AMD: Add support for fam17h microcode loading

2020-04-28T18:02:18+00:00

commit f4e9b7af0cd58dd039a0fb2cd67d57cea4889abf upstream.

The size for the Microcode Patch Block (MPB) for an AMD family 17h
processor is 3200 bytes.  Add a #define for fam17h so that it does
not default to 2048 bytes and fail a microcode load/update.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

s390: Fix unmatched preempt_disable() on exit

2020-02-11T20:03:58+00:00

exit_thread_runtime_instr() may return with preemption disabled,
leading to the following lockdep splat:

BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586
in_atomic(): 1, irqs_disabled(): 0, pid: 565, name: kworker/u2:0
no locks held by kworker/u2:0/565.
CPU: 0 PID: 565 Comm: kworker/u2:0 Not tainted 3.16.81-00145-gafe1c874fa44 #1
       00000000025dbbd8 00000000025dbbe8 0000000000000002 0000000000000000 
       00000000025dbc78 00000000025dbbf0 00000000025dbbf0 000000000098c55c 
       0000000000000000 00000000025d05b8 00000000025d1590 0000000000000000 
       0000000000000000 000000000000000c 00000000025dbbd8 0000000000000070 
       00000000009b7220 000000000098c55c 00000000025dbbd8 00000000025dbc20 
Call Trace:
([<000000000098c4ce>] show_trace+0xb6/0xd8)
 [<000000000098c592>] show_stack+0xa2/0xd8
 [<0000000000992c04>] dump_stack+0xc4/0x118
 [<0000000000191e20>] __might_sleep+0x230/0x238
 [<000000000099fbb0>] mutex_lock_nested+0x48/0x3d8
 [<000000000025e33e>] perf_event_exit_task+0x36/0x398
 [<0000000000158536>] do_exit+0x3ae/0xca0
 [<0000000000175826>] ____call_usermodehelper+0x136/0x148
 [<00000000009a550a>] kernel_thread_starter+0x6/0xc
 [<00000000009a5504>] kernel_thread_starter+0x0/0xc

This was fixed by commit 8d9047f8b967 "s390/runtime instrumentation:
simplify task exit handling" upstream, but that won't apply here.

Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Christian Borntraeger 
Signed-off-by: Ben Hutchings

powerpc: Fix vDSO clock_getres()

2020-02-11T20:03:55+00:00

commit 552263456215ada7ee8700ce022d12b0cffe4802 upstream.

clock_getres in the vDSO library has to preserve the same behaviour
of posix_get_hrtimer_res().

In particular, posix_get_hrtimer_res() does:
    sec = 0;
    ns = hrtimer_resolution;
and hrtimer_resolution depends on the enablement of the high
resolution timers that can happen either at compile or at run time.

Fix the powerpc vdso implementation of clock_getres keeping a copy of
hrtimer_resolution in vdso data and using that directly.

Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
Signed-off-by: Vincenzo Frascino 
Reviewed-by: Christophe Leroy 
Acked-by: Shuah Khan 
[chleroy: changed CLOCK_REALTIME_RES to CLOCK_HRTIMER_RES]
Signed-off-by: Christophe Leroy 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/a55eca3a5e85233838c2349783bcb5164dae1d09.1575273217.git.christophe.leroy@c-s.fr
[bwh: Backported to 3.16:
 - In asm-offsets.c, use DEFINE() instead of OFFSET()
 - Adjust context]
Signed-off-by: Ben Hutchings

xtensa: fix TLB sanity checker

2020-02-11T20:03:50+00:00

commit 36de10c4788efc6efe6ff9aa10d38cb7eea4c818 upstream.

Virtual and translated addresses retrieved by the xtensa TLB sanity
checker must be consistent, i.e. correspond to the same state of the
checked TLB entry. KASAN shadow memory is mapped dynamically using
auto-refill TLB entries and thus may change TLB state between the
virtual and translated address retrieval, resulting in false TLB
insanity report.
Move read_xtlb_translation close to read_xtlb_virtual to make sure that
read values are consistent.

Fixes: a99e07ee5e88 ("xtensa: check TLB sanity on return to userspace")
Signed-off-by: Max Filippov 
Signed-off-by: Ben Hutchings

x86/PCI: Avoid AMD FCH XHCI USB PME# from D0 defect

2020-02-11T20:03:47+00:00

commit 7e8ce0e2b036dbc6617184317983aea4f2c52099 upstream.

The AMD FCH USB XHCI Controller advertises support for generating PME#
while in D0.  When in D0, it does signal PME# for USB 3.0 connect events,
but not for USB 2.0 or USB 1.1 connect events, which means the controller
doesn't wake correctly for those events.

  00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH USB XHCI Controller [1022:7914] (rev 20) (prog-if 30 [XHCI])
        Subsystem: Dell FCH USB XHCI Controller [1028:087e]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)

Clear PCI_PM_CAP_PME_D0 in dev->pme_support to indicate the device will not
assert PME# from D0 so we don't rely on it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203673
Link: https://lore.kernel.org/r/20190902145252.32111-1-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Ben Hutchings