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

KVM: s390: reject invalid modes for runtime instrumentation

2016-10-28T07:45:30+00:00

commit a5efb6b6c99a3a6dc4330f51d8066f638bdea0ac upstream.

Usually a validity intercept is a programming error of the host
because of invalid entries in the state description.
We can get a validity intercept if the mode of the runtime
instrumentation control block is wrong. As the host does not know
which modes are valid, this can be used by userspace to trigger
a WARN.
Instead of printing a WARN let's return an error to userspace as
this can only happen if userspace provides a malformed initial
value (e.g. on migration). The kernel should never warn on bogus
input. Instead let's log it into the s390 debug feature.

While at it, let's return -EINVAL for all validity intercepts as
this will trigger an error in QEMU like

error: kvm run failed Invalid argument
PSW=mask 0404c00180000000 addr 000000000063c226 cc 00
R00=000000000000004f R01=0000000000000004 R02=0000000000760005 R03=000000007fe0a000
R04=000000000064ba2a R05=000000049db73dd0 R06=000000000082c4b0 R07=0000000000000041
R08=0000000000000002 R09=000003e0804042a8 R10=0000000496152c42 R11=000000007fe0afb0
[...]

This will avoid an endless loop of validity intercepts.

Fixes: c6e5f166373a ("KVM: s390: implement the RI support of guest")
Acked-by: Fan Zhang 
Reviewed-by: Pierre Morel 
Signed-off-by: Christian Borntraeger 
Signed-off-by: Greg Kroah-Hartman

powerpc/mm: Prevent unlikely crash in copro_calculate_slb()

2016-10-28T07:45:29+00:00

commit d2cf909cda5f8c5609cb7ed6cda816c3e15528c7 upstream.

If a cxl adapter faults on an invalid address for a kernel context, we
may enter copro_calculate_slb() with a NULL mm pointer (kernel
context) and an effective address which looks like a user
address. Which will cause a crash when dereferencing mm. It is clearly
an AFU bug, but there's no reason to crash either. So return an error,
so that cxl can ack the interrupt with an address error.

Fixes: 73d16a6e0e51 ("powerpc/cell: Move data segment faulting code out of cell platform")
Signed-off-by: Frederic Barrat 
Acked-by: Ian Munsie 
Signed-off-by: Michael Ellerman 
Signed-off-by: Greg Kroah-Hartman

arm64: KVM: Take S1 walks into account when determining S2 write faults

2016-10-28T07:45:29+00:00

commit 60e21a0ef54cd836b9eb22c7cb396989b5b11648 upstream.

The WnR bit in the HSR/ESR_EL2 indicates whether a data abort was
generated by a read or a write instruction. For stage 2 data aborts
generated by a stage 1 translation table walk (i.e. the actual page
table access faults at EL2), the WnR bit therefore reports whether the
instruction generating the walk was a load or a store, *not* whether the
page table walker was reading or writing the entry.

For page tables marked as read-only at stage 2 (e.g. due to KSM merging
them with the tables from another guest), this could result in livelock,
where a page table walk generated by a load instruction attempts to
set the access flag in the stage 1 descriptor, but fails to trigger
CoW in the host since only a read fault is reported.

This patch modifies the arm64 kvm_vcpu_dabt_iswrite function to
take into account stage 2 faults in stage 1 walks. Since DBM cannot be
disabled at EL2 for CPUs that implement it, we assume that these faults
are always causes by writes, avoiding the livelock situation at the
expense of occasional, spurious CoWs.

We could, in theory, do a bit better by checking the guest TCR
configuration and inspecting the page table to see why the PTE faulted.
However, I doubt this is measurable in practice, and the threat of
livelock is real.

Cc: Julien Grall 
Reviewed-by: Marc Zyngier 
Reviewed-by: Christoffer Dall 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: Cortex-A53 errata workaround: check for kernel addresses

2016-10-28T07:45:29+00:00

commit 87261d19046aeaeed8eb3d2793fde850ae1b5c9e upstream.

Commit 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on
errata-affected core") adds code to execute cache maintenance instructions
in the kernel on behalf of userland on CPUs with certain ARM CPU errata.
It turns out that the address hasn't been checked to be a valid user
space address, allowing userland to clean cache lines in kernel space.
Fix this by introducing an address check before executing the
instructions on behalf of userland.

Since the address doesn't come via a syscall parameter, we can't just
reject tagged pointers and instead have to remove the tag when checking
against the user address limit.

Fixes: 7dd01aef0557 ("arm64: trap userspace "dc cvau" cache operation on errata-affected core")
Reported-by: Kristina Martsenko 
Signed-off-by: Andre Przywara 
[will: rework commit message + replace access_ok with max_user_addr()]
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: kernel: Init MDCR_EL2 even in the absence of a PMU

2016-10-28T07:45:29+00:00

commit 850540351bb1a4fa5f192e5ce55b89928cc57f42 upstream.

Commit f436b2ac90a0 ("arm64: kernel: fix architected PMU registers
unconditional access") made sure we wouldn't access unimplemented
PMU registers, but also left MDCR_EL2 uninitialized in that case,
leading to trap bits being potentially left set.

Make sure we always write something in that register.

Fixes: f436b2ac90a0 ("arm64: kernel: fix architected PMU registers unconditional access")
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Signed-off-by: Marc Zyngier 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: percpu: rewrite ll/sc loops in assembly

2016-10-28T07:45:29+00:00

commit 1e6e57d9b34a9075d5f9e2048ea7b09756590d11 upstream.

Writing the outer loop of an LL/SC sequence using do {...} while
constructs potentially allows the compiler to hoist memory accesses
between the STXR and the branch back to the LDXR. On CPUs that do not
guarantee forward progress of LL/SC loops when faced with memory
accesses to the same ERG (up to 2k) between the failed STXR and the
branch back, we may end up livelocking.

This patch avoids this issue in our percpu atomics by rewriting the
outer loop as part of the LL/SC inline assembly block.

Fixes: f97fc810798c ("arm64: percpu: Implement this_cpu operations")
Reviewed-by: Mark Rutland 
Tested-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y

2016-10-28T07:45:29+00:00

commit 9c0e83c371cf4696926c95f9c8c77cd6ea803426 upstream.

As it turns out, the KASLR code breaks CONFIG_MODVERSIONS, since the
kcrctab has an absolute address field that is relocated at runtime
when the kernel offset is randomized.

This has been fixed already for PowerPC in the past, so simply wire up
the existing code dealing with this issue.

Fixes: f80fb3a3d508 ("arm64: add support for kernel ASLR")
Tested-by: Timur Tabi 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

arm64: swp emulation: bound LL/SC retries before rescheduling

2016-10-28T07:45:29+00:00

commit 1c5b51dfb7b4564008e0cadec5381a69e88b0d21 upstream.

If a CPU does not implement a global monitor for certain memory types,
then userspace can attempt a kernel DoS by issuing SWP instructions
targetting the problematic memory (for example, a framebuffer mapped
with non-cacheable attributes).

The SWP emulation code protects against these sorts of attacks by
checking for pending signals and potentially rescheduling when the STXR
instruction fails during the emulation. Whilst this is good for avoiding
livelock, it harms emulation of legitimate SWP instructions on CPUs
where forward progress is not guaranteed if there are memory accesses to
the same reservation granule (up to 2k) between the failing STXR and
the retry of the LDXR.

This patch solves the problem by retrying the STXR a bounded number of
times (4) before breaking out of the LL/SC loop and looking for
something else to do.

Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Reviewed-by: Mark Rutland 
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

x86/boot/smp: Don't try to poke disabled/non-existent APIC

2016-10-28T07:45:28+00:00

commit ff8560512b8d4b7ca3ef4fd69166634ac30b2525 upstream.

Apparently trying to poke a disabled or non-existent APIC
leads to a box that doesn't even boot. Let's not do that.

No real clue if this is the right fix, but at least my
P3 machine boots again.

Signed-off-by: Ville Syrjälä 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Eric Biederman 
Cc: H. Peter Anvin 
Cc: Jiri Olsa 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Prarit Bhargava 
Cc: Thomas Gleixner 
Cc: Yinghai Lu 
Cc: dyoung@redhat.com
Cc: kexec@lists.infradead.org
Fixes: 2a51fe083eba ("arch/x86: Handle non enumerated CPU after physical hotplug")
Link: http://lkml.kernel.org/r/1477102684-5092-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates

2016-10-28T07:45:28+00:00

commit caef78b6cdeddf4ad364f95910bba6b43b8eb9bf upstream.

Some time ago, we brought our UV BIOS callback code up to speed with the
new EFI memory mapping scheme, in commit:

    d1be84a232e3 ("x86/uv: Update uv_bios_call() to use efi_call_virt_pointer()")

By leveraging some changes that I made to a few of the EFI runtime
callback mechanisms, in commit:

    80e75596079f ("efi: Convert efi_call_virt() to efi_call_virt_pointer()")

This got everything running smoothly on UV, with the new EFI mapping
code.  However, this left one, small loose end, in that EFI_OLD_MEMMAP
(a.k.a. efi=old_map) will no longer work on UV, on kernels that include
the aforementioned changes.

At the time this was not a major issue (in fact, it still really isn't),
but there's no reason that EFI_OLD_MEMMAP *shouldn't* work on our
systems.  This commit adds a check into uv_bios_call(), to see if we have
the EFI_OLD_MEMMAP bit set in efi.flags.  If it is set, we fall back to
using our old callback method, which uses efi_call() directly on the __va()
of our function pointer.

Signed-off-by: Alex Thorlton 
Acked-by: Matt Fleming 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Dimitri Sivanich 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Masahiro Yamada 
Cc: Mike Travis 
Cc: Peter Zijlstra 
Cc: Russ Anderson 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/1476928131-170101-1-git-send-email-athorlton@sgi.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman