forked from torvalds/linux
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge branch 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linu…
…x/kernel/git/tip/tip Pull spectre/meltdown updates from Thomas Gleixner: "The next round of updates related to melted spectrum: - The initial set of spectre V1 mitigations: - Array index speculation blocker and its usage for syscall, fdtable and the n180211 driver. - Speculation barrier and its usage in user access functions - Make indirect calls in KVM speculation safe - Blacklisting of known to be broken microcodes so IPBP/IBSR are not touched. - The initial IBPB support and its usage in context switch - The exposure of the new speculation MSRs to KVM guests. - A fix for a regression in x86/32 related to the cpu entry area - Proper whitelisting for known to be safe CPUs from the mitigations. - objtool fixes to deal proper with retpolines and alternatives - Exclude __init functions from retpolines which speeds up the boot process. - Removal of the syscall64 fast path and related cleanups and simplifications - Removal of the unpatched paravirt mode which is yet another source of indirect unproteced calls. - A new and undisputed version of the module mismatch warning - A couple of cleanup and correctness fixes all over the place Yet another step towards full mitigation. There are a few things still missing like the RBS underflow mitigation for Skylake and other small details, but that's being worked on. That said, I'm taking a belated christmas vacation for a week and hope that everything is magically solved when I'm back on Feb 12th" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (37 commits) KVM/SVM: Allow direct access to MSR_IA32_SPEC_CTRL KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL KVM/VMX: Emulate MSR_IA32_ARCH_CAPABILITIES KVM/x86: Add IBPB support KVM/x86: Update the reverse_cpuid list to include CPUID_7_EDX x86/speculation: Fix typo IBRS_ATT, which should be IBRS_ALL x86/pti: Mark constant arrays as __initconst x86/spectre: Simplify spectre_v2 command line parsing x86/retpoline: Avoid retpolines for built-in __init functions x86/kvm: Update spectre-v1 mitigation KVM: VMX: make MSR bitmaps per-VCPU x86/paravirt: Remove 'noreplace-paravirt' cmdline option x86/speculation: Use Indirect Branch Prediction Barrier in context switch x86/cpuid: Fix up "virtual" IBRS/IBPB/STIBP feature bits on Intel x86/spectre: Fix spelling mistake: "vunerable"-> "vulnerable" x86/spectre: Report get_user mitigation for spectre_v1 nl80211: Sanitize array index in parse_txq_params vfs, fdtable: Prevent bounds-check bypass via speculative execution x86/syscall: Sanitize syscall table de-references under speculation x86/get_user: Use pointer masking to limit speculation ...
- Loading branch information
Showing
38 changed files
with
977 additions
and
554 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,90 @@ | ||
This document explains potential effects of speculation, and how undesirable | ||
effects can be mitigated portably using common APIs. | ||
|
||
=========== | ||
Speculation | ||
=========== | ||
|
||
To improve performance and minimize average latencies, many contemporary CPUs | ||
employ speculative execution techniques such as branch prediction, performing | ||
work which may be discarded at a later stage. | ||
|
||
Typically speculative execution cannot be observed from architectural state, | ||
such as the contents of registers. However, in some cases it is possible to | ||
observe its impact on microarchitectural state, such as the presence or | ||
absence of data in caches. Such state may form side-channels which can be | ||
observed to extract secret information. | ||
|
||
For example, in the presence of branch prediction, it is possible for bounds | ||
checks to be ignored by code which is speculatively executed. Consider the | ||
following code: | ||
|
||
int load_array(int *array, unsigned int index) | ||
{ | ||
if (index >= MAX_ARRAY_ELEMS) | ||
return 0; | ||
else | ||
return array[index]; | ||
} | ||
|
||
Which, on arm64, may be compiled to an assembly sequence such as: | ||
|
||
CMP <index>, #MAX_ARRAY_ELEMS | ||
B.LT less | ||
MOV <returnval>, #0 | ||
RET | ||
less: | ||
LDR <returnval>, [<array>, <index>] | ||
RET | ||
|
||
It is possible that a CPU mis-predicts the conditional branch, and | ||
speculatively loads array[index], even if index >= MAX_ARRAY_ELEMS. This | ||
value will subsequently be discarded, but the speculated load may affect | ||
microarchitectural state which can be subsequently measured. | ||
|
||
More complex sequences involving multiple dependent memory accesses may | ||
result in sensitive information being leaked. Consider the following | ||
code, building on the prior example: | ||
|
||
int load_dependent_arrays(int *arr1, int *arr2, int index) | ||
{ | ||
int val1, val2, | ||
|
||
val1 = load_array(arr1, index); | ||
val2 = load_array(arr2, val1); | ||
|
||
return val2; | ||
} | ||
|
||
Under speculation, the first call to load_array() may return the value | ||
of an out-of-bounds address, while the second call will influence | ||
microarchitectural state dependent on this value. This may provide an | ||
arbitrary read primitive. | ||
|
||
==================================== | ||
Mitigating speculation side-channels | ||
==================================== | ||
|
||
The kernel provides a generic API to ensure that bounds checks are | ||
respected even under speculation. Architectures which are affected by | ||
speculation-based side-channels are expected to implement these | ||
primitives. | ||
|
||
The array_index_nospec() helper in <linux/nospec.h> can be used to | ||
prevent information from being leaked via side-channels. | ||
|
||
A call to array_index_nospec(index, size) returns a sanitized index | ||
value that is bounded to [0, size) even under cpu speculation | ||
conditions. | ||
|
||
This can be used to protect the earlier load_array() example: | ||
|
||
int load_array(int *array, unsigned int index) | ||
{ | ||
if (index >= MAX_ARRAY_ELEMS) | ||
return 0; | ||
else { | ||
index = array_index_nospec(index, MAX_ARRAY_ELEMS); | ||
return array[index]; | ||
} | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.