linux-toradex.git/arch/x86, branch v3.2.74

KVM: svm: unconditionally intercept #DB

2015-11-27T12:48:24+00:00

commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.

This is needed to avoid the possibility that the guest triggers
an infinite stream of #DB exceptions (CVE-2015-8104).

VMX is not affected: because it does not save DR6 in the VMCS,
it already intercepts #DB unconditionally.

Reported-by: Jan Beulich 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.2, with thanks to Paolo:
 - update_db_bp_intercept() was called update_db_intercept()
 - The remaining call is in svm_guest_debug() rather than through svm_x86_ops]
Signed-off-by: Ben Hutchings

x86/cpu: Call verify_cpu() after having entered long mode too

2015-11-27T12:48:23+00:00

commit 04633df0c43d710e5f696b06539c100898678235 upstream.

When we get loaded by a 64-bit bootloader, kernel entry point is
startup_64 in head_64.S. We don't trust any and all bootloaders because
some will fiddle with CPU configuration so we go ahead and massage each
CPU into sanity again.

For example, some dell BIOSes have this XD disable feature which set
IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround
for other OSes but Linux sure doesn't need it.

A similar thing is present in the Surface 3 firmware - see
https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit
only on the BSP:

  # rdmsr -a 0x1a0
  400850089
  850089
  850089
  850089

I know, right?!

There's not even an off switch in there.

So fix all those cases by sanitizing the 64-bit entry point too. For
that, make verify_cpu() callable in 64-bit mode also.

Requested-and-debugged-by: "H. Peter Anvin" 
Reported-and-tested-by: Bastien Nocera 
Signed-off-by: Borislav Petkov 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@alien8.de
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings

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

2015-11-17T15:54:46+00:00

commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.

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).

Signed-off-by: Eric Northup 
Signed-off-by: Paolo Bonzini 
[bwh: Backported to 3.2:
 - Add definition of AC_VECTOR
 - Adjust filename, context]
Signed-off-by: Ben Hutchings

x86/process: Add proper bound checks in 64bit get_wchan()

2015-11-17T15:54:41+00:00

commit eddd3826a1a0190e5235703d1e666affa4d13b96 upstream.

Dmitry Vyukov reported the following using trinity and the memory
error detector AddressSanitizer
(https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel).

[ 124.575597] ERROR: AddressSanitizer: heap-buffer-overflow on
address ffff88002e280000
[ 124.576801] ffff88002e280000 is located 131938492886538 bytes to
the left of 28857600-byte region [ffffffff81282e0a, ffffffff82e0830a)
[ 124.578633] Accessed by thread T10915:
[ 124.579295] inlined in describe_heap_address
./arch/x86/mm/asan/report.c:164
[ 124.579295] #0 ffffffff810dd277 in asan_report_error
./arch/x86/mm/asan/report.c:278
[ 124.580137] #1 ffffffff810dc6a0 in asan_check_region
./arch/x86/mm/asan/asan.c:37
[ 124.581050] #2 ffffffff810dd423 in __tsan_read8 ??:0
[ 124.581893] #3 ffffffff8107c093 in get_wchan
./arch/x86/kernel/process_64.c:444

The address checks in the 64bit implementation of get_wchan() are
wrong in several ways:

 - The lower bound of the stack is not the start of the stack
   page. It's the start of the stack page plus sizeof (struct
   thread_info)

 - The upper bound must be:

       top_of_stack - TOP_OF_KERNEL_STACK_PADDING - 2 * sizeof(unsigned long).

   The 2 * sizeof(unsigned long) is required because the stack pointer
   points at the frame pointer. The layout on the stack is: ... IP FP
   ... IP FP. So we need to make sure that both IP and FP are in the
   bounds.

Fix the bound checks and get rid of the mix of numeric constants, u64
and unsigned long. Making all unsigned long allows us to use the same
function for 32bit as well.

Use READ_ONCE() when accessing the stack. This does not prevent a
concurrent wakeup of the task and the stack changing, but at least it
avoids TOCTOU.

Also check task state at the end of the loop. Again that does not
prevent concurrent changes, but it avoids walking for nothing.

Add proper comments while at it.

Reported-by: Dmitry Vyukov 
Reported-by: Sasha Levin 
Based-on-patch-from: Wolfram Gloger 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Reviewed-by: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Andrey Konovalov 
Cc: Kostya Serebryany 
Cc: Alexander Potapenko 
Cc: kasan-dev 
Cc: Denys Vlasenko 
Cc: Andi Kleen 
Cc: Wolfram Gloger 
Link: http://lkml.kernel.org/r/20150930083302.694788319@linutronix.de
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.2:
 - s/READ_ONCE/ACCESS_ONCE/
 - Remove use of TOP_OF_KERNEL_STACK_PADDING, not defined here and would
   be defined as 0]
Signed-off-by: Ben Hutchings

x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing map

2015-11-17T15:54:40+00:00

commit 64c98e7f49100b637cd20a6c63508caed6bbba7a upstream.

Sanitizing the e820 map may produce extra E820 entries which would result in
the topmost E820 entries being removed. The removed entries would typically
include the top E820 usable RAM region and thus result in the domain having
signicantly less RAM available to it.

Fix by allowing sanitize_e820_map to use the full size of the allocated E820
array.

Signed-off-by: Malcolm Crossley 
Reviewed-by: Boris Ostrovsky 
Signed-off-by: David Vrabel 
[bwh: Backported to 3.2:
 s/xen_e820_map_entries/memmap.nr_entries/; s/xen_e820_map/map/g]
Signed-off-by: Ben Hutchings

Revert "KVM: MMU: fix validation of mmio page fault"

2015-11-17T15:54:40+00:00

This reverts commit 41e3025eacd6daafc40c3e7850fbcabc8b847805, which
was commit 6f691251c0350ac52a007c54bf3ef62e9d8cdc5e upstream.

The fix is only needed after commit f8f559422b6c ("KVM: MMU: fast
invalidate all mmio sptes"), included in Linux 3.11.

Signed-off-by: Ben Hutchings

x86/paravirt: Replace the paravirt nop with a bona fide empty function

2015-10-13T02:46:11+00:00

commit fc57a7c68020dcf954428869eafd934c0ab1536f upstream.

PARAVIRT_ADJUST_EXCEPTION_FRAME generates this code (using nmi as an
example, trimmed for readability):

    ff 15 00 00 00 00       callq  *0x0(%rip)        # 2796 
              2792: R_X86_64_PC32     pv_irq_ops+0x2c

That's a call through a function pointer to regular C function that
does nothing on native boots, but that function isn't protected
against kprobes, isn't marked notrace, and is certainly not
guaranteed to preserve any registers if the compiler is feeling
perverse.  This is bad news for a CLBR_NONE operation.

Of course, if everything works correctly, once paravirt ops are
patched, it gets nopped out, but what if we hit this code before
paravirt ops are patched in?  This can potentially cause breakage
that is very difficult to debug.

A more subtle failure is possible here, too: if _paravirt_nop uses
the stack at all (even just to push RBP), it will overwrite the "NMI
executing" variable if it's called in the NMI prologue.

The Xen case, perhaps surprisingly, is fine, because it's already
written in asm.

Fix all of the cases that default to paravirt_nop (including
adjust_exception_frame) with a big hammer: replace paravirt_nop with
an asm function that is just a ret instruction.

The Xen case may have other problems, so document them.

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

Reported-and-tested-by: Sasha Levin 
Signed-off-by: Andy Lutomirski 
Link: http://lkml.kernel.org/r/8f5d2ba295f9d73751c33d97fda03e0495d9ade0.1442791737.git.luto@kernel.org
Signed-off-by: Thomas Gleixner 
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings

KVM: x86: trap AMD MSRs for the TSeg base and mask

2015-10-13T02:46:10+00:00

commit 3afb1121800128aae9f5722e50097fcf1a9d4d88 upstream.

These have roughly the same purpose as the SMRR, which we do not need
to implement in KVM.  However, Linux accesses MSR_K8_TSEG_ADDR at
boot, which causes problems when running a Xen dom0 under KVM.
Just return 0, meaning that processor protection of SMRAM is not
in effect.

Reported-by: M A Young 
Acked-by: Borislav Petkov 
Signed-off-by: Paolo Bonzini 
Signed-off-by: Ben Hutchings

x86/platform: Fix Geode LX timekeeping in the generic x86 build

2015-10-13T02:46:10+00:00

commit 03da3ff1cfcd7774c8780d2547ba0d995f7dc03d upstream.

In 2007, commit 07190a08eef36 ("Mark TSC on GeodeLX reliable")
bypassed verification of the TSC on Geode LX. However, this code
(now in the check_system_tsc_reliable() function in
arch/x86/kernel/tsc.c) was only present if CONFIG_MGEODE_LX was
set.

OpenWRT has recently started building its generic Geode target
for Geode GX, not LX, to include support for additional
platforms. This broke the timekeeping on LX-based devices,
because the TSC wasn't marked as reliable:
https://dev.openwrt.org/ticket/20531

By adding a runtime check on is_geode_lx(), we can also include
the fix if CONFIG_MGEODEGX1 or CONFIG_X86_GENERIC are set, thus
fixing the problem.

Signed-off-by: David Woodhouse 
Cc: Andres Salomon 
Cc: Linus Torvalds 
Cc: Marcelo Tosatti 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1442409003.131189.87.camel@infradead.org
Signed-off-by: Ingo Molnar 
Signed-off-by: Ben Hutchings

crypto: ghash-clmulni: specify context size for ghash async algorithm

2015-10-13T02:46:08+00:00

commit 71c6da846be478a61556717ef1ee1cea91f5d6a8 upstream.

Currently context size (cra_ctxsize) doesn't specified for
ghash_async_alg. Which means it's zero. Thus crypto_create_tfm()
doesn't allocate needed space for ghash_async_ctx, so any
read/write to ctx (e.g. in ghash_async_init_tfm()) is not valid.

Signed-off-by: Andrey Ryabinin 
Signed-off-by: Herbert Xu 
Signed-off-by: Ben Hutchings