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

KVM: x86: work around leak of uninitialized stack contents

2019-11-22T15:57:30+00:00

commit 541ab2aeb28251bf7135c7961f3a6080eebcc705 upstream.

Emulation of VMPTRST can incorrectly inject a page fault
when passed an operand that points to an MMIO address.
The page fault will use uninitialized kernel stack memory
as the CR2 and error code.

The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR
exit to userspace; however, it is not an easy fix, so for now just ensure
that the error code and CR2 are zero.

Signed-off-by: Fuqian Huang 
[add comment]
Signed-off-by: Paolo Bonzini 
Signed-off-by: Ben Hutchings

KVM: nVMX: handle page fault in vmread

2019-11-22T15:57:29+00:00

commit f7eea636c3d505fe6f1d1066234f1aaf7171b681 upstream.

The implementation of vmread to memory is still incomplete, as it
lacks the ability to do vmread to I/O memory just like vmptrst.

Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

x86/apic/32: Avoid bogus LDR warnings

2019-11-22T15:57:22+00:00

commit fe6f85ca121e9c74e7490fe66b0c5aae38e332c3 upstream.

The removal of the LDR initialization in the bigsmp_32 APIC code unearthed
a problem in setup_local_APIC().

The code checks unconditionally for a mismatch of the logical APIC id by
comparing the early APIC id which was initialized in get_smp_config() with
the actual LDR value in the APIC.

Due to the removal of the bogus LDR initialization the check now can
trigger on bigsmp_32 APIC systems emitting a warning for every booting
CPU. This is of course a false positive because the APIC is not using
logical destination mode.

Restrict the check and the possibly resulting fixup to systems which are
actually using the APIC in logical destination mode.

[ tglx: Massaged changelog and added Cc stable ]

Fixes: bae3a8d3308 ("x86/apic: Do not initialize LDR and DFR for bigsmp")
Signed-off-by: Jan Beulich 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/666d8f91-b5a8-1afd-7add-821e72a35f03@suse.com
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

x86/apic: Drop logical_smp_processor_id() inline

2019-11-22T15:57:22+00:00

commit 8f1561680f42a5491b371b513f1ab8197f31fd62 upstream.

The logical_smp_processor_id() inline which is only called in
setup_local_APIC() on x86_32 systems has no real value.

Drop it and directly use GET_APIC_LOGICAL_ID() at the call site and use a
more suitable variable name for readability

Signed-off-by: Dou Liyang 
Signed-off-by: Thomas Gleixner 
Cc: andy.shevchenko@gmail.com
Cc: bhe@redhat.com
Cc: ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20180301055930.2396-4-douly.fnst@cn.fujitsu.com
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

x86/apic: Do not initialize LDR and DFR for bigsmp

2019-11-22T15:57:21+00:00

commit bae3a8d3308ee69a7dbdf145911b18dfda8ade0d upstream.

Legacy apic init uses bigsmp for smp systems with 8 and more CPUs. The
bigsmp APIC implementation uses physical destination mode, but it
nevertheless initializes LDR and DFR. The LDR even ends up incorrectly with
multiple bit being set.

This does not cause a functional problem because LDR and DFR are ignored
when physical destination mode is active, but it triggered a problem on a
32-bit KVM guest which jumps into a kdump kernel.

The multiple bits set unearthed a bug in the KVM APIC implementation. The
code which creates the logical destination map for VCPUs ignores the
disabled state of the APIC and ends up overwriting an existing valid entry
and as a result, APIC calibration hangs in the guest during kdump
initialization.

Remove the bogus LDR/DFR initialization.

This is not intended to work around the KVM APIC bug. The LDR/DFR
ininitalization is wrong on its own.

The issue goes back into the pre git history. The fixes tag is the commit
in the bitkeeper import which introduced bigsmp support in 2003.

  git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git

Fixes: db7b9e9f26b8 ("[PATCH] Clustered APIC setup for >8 CPU systems")
Suggested-by: Thomas Gleixner 
Signed-off-by: Bandan Das 
Signed-off-by: Thomas Gleixner 
Link: https://lkml.kernel.org/r/20190826101513.5080-2-bsd@redhat.com
Signed-off-by: Ben Hutchings

uprobes/x86: Fix detection of 32-bit user mode

2019-11-22T15:57:21+00:00

commit 9212ec7d8357ea630031e89d0d399c761421c83b upstream.

32-bit processes running on a 64-bit kernel are not always detected
correctly, causing the process to crash when uretprobes are installed.

The reason for the crash is that in_ia32_syscall() is used to determine the
process's mode, which only works correctly when called from a syscall.

In the case of uretprobes, however, the function is called from a exception
and always returns 'false' on a 64-bit kernel. In consequence this leads to
corruption of the process's return address.

Fix this by using user_64bit_mode() instead of in_ia32_syscall(), which
is correct in any situation.

[ tglx: Add a comment and the following historical info ]

This should have been detected by the rename which happened in commit

  abfb9498ee13 ("x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()")

which states in the changelog:

    The is_ia32_task()/is_x32_task() function names are a big misnomer: they
    suggests that the compat-ness of a system call is a task property, which
    is not true, the compatness of a system call purely depends on how it
    was invoked through the system call layer.
    .....

and then it went and blindly renamed every call site.

Sadly enough this was already mentioned here:

   8faaed1b9f50 ("uprobes/x86: Introduce sizeof_long(), cleanup adjust_ret_addr() and
arch_uretprobe_hijack_return_addr()")

where the changelog says:

    TODO: is_ia32_task() is not what we actually want, TS_COMPAT does
    not necessarily mean 32bit. Fortunately syscall-like insns can't be
    probed so it actually works, but it would be better to rename and
    use is_ia32_frame().

and goes all the way back to:

    0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")

Oh well. 7+ years until someone actually tried a uretprobe on a 32bit
process on a 64bit kernel....

Fixes: 0326f5a94dde ("uprobes/core: Handle breakpoint and singlestep exceptions")
Signed-off-by: Sebastian Mayr 
Signed-off-by: Thomas Gleixner 
Cc: Masami Hiramatsu 
Cc: Dmitry Safonov 
Cc: Oleg Nesterov 
Cc: Srikar Dronamraju 
Link: https://lkml.kernel.org/r/20190728152617.7308-1-me@sam.st
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

ptrace,x86: Make user_64bit_mode() available to 32-bit builds

2019-11-22T15:57:20+00:00

commit e27c310af5c05cf876d9cad006928076c27f54d4 upstream.

In its current form, user_64bit_mode() can only be used when CONFIG_X86_64
is selected. This implies that code built with CONFIG_X86_64=n cannot use
it. If a piece of code needs to be built for both CONFIG_X86_64=y and
CONFIG_X86_64=n and wants to use this function, it needs to wrap it in
an #ifdef/#endif; potentially, in multiple places.

This can be easily avoided with a single #ifdef/#endif pair within
user_64bit_mode() itself.

Suggested-by: Borislav Petkov 
Signed-off-by: Ricardo Neri 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Cc: "Michael S. Tsirkin" 
Cc: Peter Zijlstra 
Cc: Dave Hansen 
Cc: ricardo.neri@intel.com
Cc: Adrian Hunter 
Cc: Paul Gortmaker 
Cc: Huang Rui 
Cc: Qiaowei Ren 
Cc: Shuah Khan 
Cc: Kees Cook 
Cc: Jonathan Corbet 
Cc: Jiri Slaby 
Cc: Dmitry Vyukov 
Cc: "Ravi V. Shankar" 
Cc: Chris Metcalf 
Cc: Brian Gerst 
Cc: Arnaldo Carvalho de Melo 
Cc: Andy Lutomirski 
Cc: Colin Ian King 
Cc: Chen Yucong 
Cc: Adam Buchbinder 
Cc: Vlastimil Babka 
Cc: Lorenzo Stoakes 
Cc: Masami Hiramatsu 
Cc: Paolo Bonzini 
Cc: Andrew Morton 
Cc: Thomas Garnier 
Link: https://lkml.kernel.org/r/1509135945-13762-4-git-send-email-ricardo.neri-calderon@linux.intel.com
[bwh: Backported to 3.16 as dependency of "uprobes/x86: Fix detection of
 32-bit user mode":
 - Adjust context]
Signed-off-by: Ben Hutchings

x86/retpoline: Don't clobber RFLAGS during CALL_NOSPEC on i386

2019-11-22T15:57:19+00:00

commit b63f20a778c88b6a04458ed6ffc69da953d3a109 upstream.

Use 'lea' instead of 'add' when adjusting %rsp in CALL_NOSPEC so as to
avoid clobbering flags.

KVM's emulator makes indirect calls into a jump table of sorts, where
the destination of the CALL_NOSPEC is a small blob of code that performs
fast emulation by executing the target instruction with fixed operands.

  adcb_al_dl:
     0x000339f8 <+0>:   adc    %dl,%al
     0x000339fa <+2>:   ret

A major motiviation for doing fast emulation is to leverage the CPU to
handle consumption and manipulation of arithmetic flags, i.e. RFLAGS is
both an input and output to the target of CALL_NOSPEC.  Clobbering flags
results in all sorts of incorrect emulation, e.g. Jcc instructions often
take the wrong path.  Sans the nops...

  asm("push %[flags]; popf; " CALL_NOSPEC " ; pushf; pop %[flags]\n"
     0x0003595a <+58>:  mov    0xc0(%ebx),%eax
     0x00035960 <+64>:  mov    0x60(%ebx),%edx
     0x00035963 <+67>:  mov    0x90(%ebx),%ecx
     0x00035969 <+73>:  push   %edi
     0x0003596a <+74>:  popf
     0x0003596b <+75>:  call   *%esi
     0x000359a0 <+128>: pushf
     0x000359a1 <+129>: pop    %edi
     0x000359a2 <+130>: mov    %eax,0xc0(%ebx)
     0x000359b1 <+145>: mov    %edx,0x60(%ebx)

  ctxt->eflags = (ctxt->eflags & ~EFLAGS_MASK) | (flags & EFLAGS_MASK);
     0x000359a8 <+136>: mov    -0x10(%ebp),%eax
     0x000359ab <+139>: and    $0x8d5,%edi
     0x000359b4 <+148>: and    $0xfffff72a,%eax
     0x000359b9 <+153>: or     %eax,%edi
     0x000359bd <+157>: mov    %edi,0x4(%ebx)

For the most part this has gone unnoticed as emulation of guest code
that can trigger fast emulation is effectively limited to MMIO when
running on modern hardware, and MMIO is rarely, if ever, accessed by
instructions that affect or consume flags.

Breakage is almost instantaneous when running with unrestricted guest
disabled, in which case KVM must emulate all instructions when the guest
has invalid state, e.g. when the guest is in Big Real Mode during early
BIOS.

Fixes: 776b043848fd2 ("x86/retpoline: Add initial retpoline support")
Fixes: 1a29b5b7f347a ("KVM: x86: Make indirect calls in emulator speculation safe")
Signed-off-by: Sean Christopherson 
Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20190822211122.27579-1-sean.j.christopherson@intel.com
Signed-off-by: Ben Hutchings

sh: kernel: hw_breakpoint: Fix missing break in switch statement

2019-11-22T15:57:14+00:00

commit 1ee1119d184bb06af921b48c3021d921bbd85bac upstream.

Add missing break statement in order to prevent the code from falling
through to case SH_BREAKPOINT_WRITE.

Fixes: 09a072947791 ("sh: hw-breakpoints: Add preliminary support for SH-4A UBC.")
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Ben Hutchings

arm64: compat: Allow single-byte watchpoints on all addresses

2019-11-22T15:57:08+00:00

commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream.

Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte
watchpoints on all addresses") changed the validation requirements for
hardware watchpoints on arch/arm/. Update our compat layer to implement
the same relaxation.

Signed-off-by: Will Deacon 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings