- 09 Feb, 2018 19 commits
-
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Allow guest access to the speculative control MSRs without being intercepted. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Andy Whitcroft <apw@canonical.com> (cherry picked from commit 68c2587c0680813d57af0a4073fa22a95a15e980) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Add an IBPB feature check to the speculative control update check after a microcode reload. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Add speculative control support for AMD processors. For AMD, speculative control is indicated as follows: CPUID EAX=0x00000007, ECX=0x00 return EDX[26] indicates support for both IBRS and IBPB. CPUID EAX=0x80000008, ECX=0x00 return EBX[12] indicates support for just IBPB. On AMD family 0x10, 0x12 and 0x16 processors where either of the above features are not supported, IBPB can be achieved by disabling indirect branch predictor support in MSR 0xc0011021[14] at boot. Signed-off-by:
-
Borislav Petkov authored
CVE-2017-5715 (Spectre v2 Intel) The kernel accesses IC_CFG MSR (0xc0011021) on AMD because it checks whether the way access filter is enabled on some F15h models, and, if so, disables it. kvm doesn't handle that MSR access and complains about it, which can get really noisy in dmesg when one starts kvm guests all the time for testing. And it is useless anyway - guest kernel shouldn't be doing such changes anyway so tell it that that filter is disabled. Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit ae8b7875) Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) There are 2 ways to control IBPB and IBRS 1. At boot time noibrs kernel boot parameter will disable IBRS usage noibpb kernel boot parameter will disable IBPB usage Otherwise if the above parameters are not specified, the system will enable ibrs and ibpb usage if the cpu supports it. 2. At run time echo 0 > /proc/sys/kernel/ibrs_enabled will turn off IBRS echo 1 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in kernel echo 2 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in both userspace and kernel Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Restore guest IBRS on VM entry and set it to 1 on VM exit back to kernel. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB (Indirect branch prediction barrier) when switching VM. Signed-off-by:
-
Wei Wang authored
CVE-2017-5715 (Spectre v2 Intel) Add field to access guest MSR_IA332_SPEC_CTRL and MSR_IA32_PRED_CMD state. Signed-off-by:
Wei Wang <wei.w.wang@intel.com> Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) To reduce overhead of setting IBPB, we only do that when the new thread cannot ptrace the current one. If the new thread has ptrace capability on current thread, it is safe. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB on context switch with changing of page table. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Clear IBRS when cpu is offlined and set it when brining it back online. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Clear IBRS on idle entry and set it on idle exit into kernel on mwait. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Set IBRS upon kernel entrance via syscall and interrupts. Clear it upon exit. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Setup macros to control IBRS and IBPB Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Report presence of IBPB and IBRS. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) cpuid ax=0x7, return rdx bit 26 to indicate presence of this feature IA32_SPEC_CTRL (0x48) and IA32_PRED_CMD (0x49) IA32_SPEC_CTRL, bit0 – Indirect Branch Restricted Speculation (IBRS) IA32_PRED_CMD, bit0 – Indirect Branch Prediction Barrier (IBPB) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
- 07 Feb, 2018 1 commit
-
-
Khalid Elmously authored
Signed-off-by:
-
- 06 Feb, 2018 1 commit
-
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1743638Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
- 05 Feb, 2018 19 commits
-
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
Martin Schwidefsky authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the pos value in function m_start() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve map->extent, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the eahd->appAttrLocation value in function udf_add_extendedattr() seems to be controllable by userspace and later on conditionally (upon bound check) used in following memmove, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the index value in function mpls_route_input_rcu() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve platform_label, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the fd value in function __fcheck_files() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve fdt->fd, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the offset value in function raw6_getfrag() seems to be controllable by userspace and later on conditionally (upon bound check) used in the following memcpy, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the offset value in function raw_getfrag() seems to be controllable by userspace and later on conditionally (upon bound check) used in the following memcpy, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the trip value in function int340x_thermal_get_trip_temp() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve d->aux_trips, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the handle value in functions qlafx00_status_entry() and qlafx00_multistatus_entry() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve req->outstanding_cmds, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) Since the queue value in function carl9170_op_conf_tx() seems to be controllable by userspace and later on conditionally (upon bound check) used to resolve ar9170_qmap and following ar->edcf, insert an observable speculation barrier before its usage. This should prevent observable speculation on that branch and avoid kernel memory leak. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) When constant blinding is enabled (bpf_jit_harden = 1), this adds an observable speculation barrier before emitting x86 jitted code for the BPF_ALU(64)_OR_X and BPF_ALU_LHS_X (for BPF_REG_AX register) eBPF instructions. This is needed in order to prevent speculative execution on out of bounds BPF_MAP array indexes when JIT is enabled. This way an arbitary kernel memory is not exposed through side-channel attacks. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) This adds an observable speculation barrier before LD_IMM_DW and LDX_MEM_B/H/W/DW eBPF instructions during eBPF program execution in order to prevent speculative execution on out of bound BFP_MAP array indexes. This way an arbitary kernel memory is not exposed through side channel attacks. Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) The new observable speculation barrier, osb(), ensures that any user observable speculation doesn't cross the boundary. Any user observable speculative activity on this CPU thread before this point either completes, reaches a state it can no longer cause an observable activity, or is aborted before instructions after the barrier execute. In x86 case, osb() resolves in lfence if X86_FEATURE_LFENCE_RDTSC is present. Other architectures can define their variants. Suggested-by:
Arjan van de Ven <arjan@linux.intel.com> Suggested-by:
Alan Cox <alan.cox@intel.com> Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (Spectre v1 Intel) Signed-off-by:
-
