linux-stable.git/arch/x86/include, branch linux-4.1.y

kvm/x86: fix icebp instruction handling

2018-05-23T01:33:53+00:00

[ Upstream commit 32d43cd391bacb5f0814c2624399a5dad3501d09 ]

The undocumented 'icebp' instruction (aka 'int1') works pretty much like
'int3' in the absense of in-circuit probing equipment (except,
obviously, that it raises #DB instead of raising #BP), and is used by
some validation test-suites as such.

But Andy Lutomirski noticed that his test suite acted differently in kvm
than on bare hardware.

The reason is that kvm used an inexact test for the icebp instruction:
it just assumed that an all-zero VM exit qualification value meant that
the VM exit was due to icebp.

That is not unlike the guess that do_debug() does for the actual
exception handling case, but it's purely a heuristic, not an absolute
rule.  do_debug() does it because it wants to ascribe _some_ reasons to
the #DB that happened, and an empty %dr6 value means that 'icebp' is the
most likely casue and we have no better information.

But kvm can just do it right, because unlike the do_debug() case, kvm
actually sees the real reason for the #DB in the VM-exit interruption
information field.

So instead of relying on an inexact heuristic, just use the actual VM
exit information that says "it was 'icebp'".

Right now the 'icebp' instruction isn't technically documented by Intel,
but that will hopefully change.  The special "privileged software
exception" information _is_ actually mentioned in the Intel SDM, even
though the cause of it isn't enumerated.

Reported-by: Andy Lutomirski 
Tested-by: Paolo Bonzini 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

x86/cpu/AMD: Use LFENCE_RDTSC in preference to MFENCE_RDTSC

2018-05-20T03:15:41+00:00

[ Upstream commit 9c6a73c75864ad9fa49e5fa6513e4c4071c0e29f ]

With LFENCE now a serializing instruction, use LFENCE_RDTSC in preference
to MFENCE_RDTSC.  However, since the kernel could be running under a
hypervisor that does not support writing that MSR, read the MSR back and
verify that the bit has been set successfully.  If the MSR can be read
and the bit is set, then set the LFENCE_RDTSC feature, otherwise set the
MFENCE_RDTSC feature.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Reviewed-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Tim Chen 
Cc: Dave Hansen 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: David Woodhouse 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/20180108220932.12580.52458.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Sasha Levin

x86/cpu/AMD: Make LFENCE a serializing instruction

2018-05-20T03:15:41+00:00

[ Upstream commit e4d0e84e490790798691aaa0f2e598637f1867ec ]

To aid in speculation control, make LFENCE a serializing instruction
since it has less overhead than MFENCE.  This is done by setting bit 1
of MSR 0xc0011029 (DE_CFG).  Some families that support LFENCE do not
have this MSR.  For these families, the LFENCE instruction is already
serializing.

Signed-off-by: Tom Lendacky 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Reviewed-by: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Tim Chen 
Cc: Dave Hansen 
Cc: Borislav Petkov 
Cc: Dan Williams 
Cc: Linus Torvalds 
Cc: Greg Kroah-Hartman 
Cc: David Woodhouse 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/20180108220921.12580.71694.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Sasha Levin

Revert "x86/retpoline/xen: Convert Xen hypercall indirect jumps"

2018-03-21T03:49:54+00:00

This reverts commit 4cc996c64b97219945b28b9faa056c009d09c04d.

Signed-off-by: Sasha Levin

x86/retpoline/xen: Convert Xen hypercall indirect jumps

2018-03-21T03:49:44+00:00

[ Upstream commit ea08816d5b185ab3d09e95e393f265af54560350 ]

Convert indirect call in Xen hypercall to use non-speculative sequence,
when CONFIG_RETPOLINE is enabled.

Signed-off-by: David Woodhouse 
Signed-off-by: Thomas Gleixner 
Acked-by: Arjan van de Ven 
Acked-by: Ingo Molnar 
Reviewed-by: Juergen Gross 
Cc: gnomes@lxorguk.ukuu.org.uk
Cc: Rik van Riel 
Cc: Andi Kleen 
Cc: Josh Poimboeuf 
Cc: thomas.lendacky@amd.com
Cc: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Jiri Kosina 
Cc: Andy Lutomirski 
Cc: Dave Hansen 
Cc: Kees Cook 
Cc: Tim Chen 
Cc: Greg Kroah-Hartman 
Cc: Paul Turner 
Link: https://lkml.kernel.org/r/1515707194-20531-10-git-send-email-dwmw@amazon.co.uk
Signed-off-by: Sasha Levin

x86/mm: Disable preemption during CR3 read+write

2018-03-04T15:28:35+00:00

[ Upstream commit 5cf0791da5c162ebc14b01eb01631cfa7ed4fa6e ]

There's a subtle preemption race on UP kernels:

Usually current->mm (and therefore mm->pgd) stays the same during the
lifetime of a task so it does not matter if a task gets preempted during
the read and write of the CR3.

But then, there is this scenario on x86-UP:

TaskA is in do_exit() and exit_mm() sets current->mm = NULL followed by:

 -> mmput()
 -> exit_mmap()
 -> tlb_finish_mmu()
 -> tlb_flush_mmu()
 -> tlb_flush_mmu_tlbonly()
 -> tlb_flush()
 -> flush_tlb_mm_range()
 -> __flush_tlb_up()
 -> __flush_tlb()
 ->  __native_flush_tlb()

At this point current->mm is NULL but current->active_mm still points to
the "old" mm.

Let's preempt taskA _after_ native_read_cr3() by taskB. TaskB has its
own mm so CR3 has changed.

Now preempt back to taskA. TaskA has no ->mm set so it borrows taskB's
mm and so CR3 remains unchanged. Once taskA gets active it continues
where it was interrupted and that means it writes its old CR3 value
back. Everything is fine because userland won't need its memory
anymore.

Now the fun part:

Let's preempt taskA one more time and get back to taskB. This
time switch_mm() won't do a thing because oldmm (->active_mm)
is the same as mm (as per context_switch()). So we remain
with a bad CR3 / PGD and return to userland.

The next thing that happens is handle_mm_fault() with an address for
the execution of its code in userland. handle_mm_fault() realizes that
it has a PTE with proper rights so it returns doing nothing. But the
CPU looks at the wrong PGD and insists that something is wrong and
faults again. And again. And one more time…

This pagefault circle continues until the scheduler gets tired of it and
puts another task on the CPU. It gets little difficult if the task is a
RT task with a high priority. The system will either freeze or it gets
fixed by the software watchdog thread which usually runs at RT-max prio.
But waiting for the watchdog will increase the latency of the RT task
which is no good.

Fix this by disabling preemption across the critical code section.

Signed-off-by: Sebastian Andrzej Siewior 
Acked-by: Peter Zijlstra (Intel) 
Acked-by: Rik van Riel 
Acked-by: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Mel Gorman 
Cc: Peter Zijlstra 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-mm@kvack.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1470404259-26290-1-git-send-email-bigeasy@linutronix.de
[ Prettified the changelog. ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86: Implement array_index_mask_nospec

2018-03-04T15:28:33+00:00

[ Upstream commit babdde2698d482b6c0de1eab4f697cf5856c5859 ]

array_index_nospec() uses a mask to sanitize user controllable array
indexes, i.e. generate a 0 mask if 'index' >= 'size', and a ~0 mask
otherwise. While the default array_index_mask_nospec() handles the
carry-bit from the (index - size) result in software.

The x86 array_index_mask_nospec() does the same, but the carry-bit is
handled in the processor CF flag without conditional instructions in the
control flow.

Suggested-by: Linus Torvalds 
Signed-off-by: Dan Williams 
Signed-off-by: Thomas Gleixner 
Cc: linux-arch@vger.kernel.org
Cc: kernel-hardening@lists.openwall.com
Cc: gregkh@linuxfoundation.org
Cc: alan@linux.intel.com
Link: https://lkml.kernel.org/r/151727414808.33451.1873237130672785331.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Sasha Levin

KVM: x86: Don't re-execute instruction when not passing CR2 value

2018-03-01T03:09:45+00:00

[ Upstream commit 9b8ae63798cb97e785a667ff27e43fa6220cb734 ]

In case of instruction-decode failure or emulation failure,
x86_emulate_instruction() will call reexecute_instruction() which will
attempt to use the cr2 value passed to x86_emulate_instruction().
However, when x86_emulate_instruction() is called from
emulate_instruction(), cr2 is not passed (passed as 0) and therefore
it doesn't make sense to execute reexecute_instruction() logic at all.

Fixes: 51d8b66199e9 ("KVM: cleanup emulate_instruction")

Signed-off-by: Liran Alon 
Reviewed-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Signed-off-by: Konrad Rzeszutek Wilk 
Reviewed-by: Wanpeng Li 
Signed-off-by: Radim Krčmář 
Signed-off-by: Sasha Levin

x86/cpu/intel: Introduce macros for Intel family numbers

2018-03-01T03:09:40+00:00

[ Upstream commit 970442c599b22ccd644ebfe94d1d303bf6f87c05 ]

Problem:

We have a boatload of open-coded family-6 model numbers.  Half of
them have these model numbers in hex and the other half in
decimal.  This makes grepping for them tons of fun, if you were
to try.

Solution:

Consolidate all the magic numbers.  Put all the definitions in
one header.

The names here are closely derived from the comments describing
the models from arch/x86/events/intel/core.c.  We could easily
make them shorter by doing things like s/SANDYBRIDGE/SNB/, but
they seemed fine even with the longer versions to me.

Do not take any of these names too literally, like "DESKTOP"
or "MOBILE".  These are all colloquial names and not precise
descriptions of everywhere a given model will show up.

Signed-off-by: Dave Hansen 
Cc: Adrian Hunter 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Darren Hart 
Cc: Dave Hansen 
Cc: Denys Vlasenko 
Cc: Doug Thompson 
Cc: Eduardo Valentin 
Cc: H. Peter Anvin 
Cc: Jacob Pan 
Cc: Kan Liang 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Mauro Carvalho Chehab 
Cc: Peter Zijlstra 
Cc: Rafael J. Wysocki 
Cc: Rajneesh Bhardwaj 
Cc: Souvik Kumar Chakravarty 
Cc: Srinivas Pandruvada 
Cc: Stephane Eranian 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: Ulf Hansson 
Cc: Viresh Kumar 
Cc: Vishwanath Somayaji 
Cc: Zhang Rui 
Cc: jacob.jun.pan@intel.com
Cc: linux-acpi@vger.kernel.org
Cc: linux-edac@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: platform-driver-x86@vger.kernel.org
Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels

2018-03-01T03:09:40+00:00

[ Upstream commit 1c52d859cb2d417e7216d3e56bb7fea88444cec9 ]

We support various non-Intel CPUs that don't have the CPUID
instruction, so the M486 test was wrong.  For now, fix it with a big
hammer: handle missing CPUID on all 32-bit CPUs.

Reported-by: One Thousand Gnomes 
Signed-off-by: Andy Lutomirski 
Cc: Juergen Gross 
Cc: Peter Zijlstra 
Cc: Brian Gerst 
Cc: Matthew Whitehead 
Cc: Borislav Petkov 
Cc: Henrique de Moraes Holschuh 
Cc: Andrew Cooper 
Cc: Boris Ostrovsky 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/685bd083a7c036f7769510b6846315b17d6ba71f.1481307769.git.luto@kernel.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin