- 09 Feb, 2018 2 commits
-
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
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 36 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:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) With the switch to using LFENCE_RDTSC on AMD platforms there is no longer a need for the MFENCE_RDTSC feature. Remove its usage and definition. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 (Spectre v1 Intel) In order to reduce the impact of using MFENCE, make the execution of the LFENCE instruction serialized. 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 serialized. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 retpoline) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 retpoline) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 retpoline) Signed-off-by:
-
Andi Kleen authored
CVE-2017-5715 (Spectre v2 retpoline) commit 3f7d8755 upstream. The generated assembler for the C fill RSB inline asm operations has several issues: - The C code sets up the loop register, which is then immediately overwritten in __FILL_RETURN_BUFFER with the same value again. - The C code also passes in the iteration count in another register, which is not used at all. Remove these two unnecessary operations. Just rely on the single constant passed to the macro for the iterations. Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
David Woodhouse <dwmw@amazon.co.uk> Cc: dave.hansen@intel.com Cc: gregkh@linuxfoundation.org Cc: torvalds@linux-foundation.org Cc: arjan@linux.intel.com Link: https://lkml.kernel.org/r/20180117225328.15414-1-andi@firstfloor.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 838eee60741a910019fe55d8f1f5f7d4471d62fe) Signed-off-by:
-
Masami Hiramatsu authored
CVE-2017-5715 (Spectre v2 retpoline) commit c86a32c0 upstream. Since indirect jump instructions will be replaced by jump to __x86_indirect_thunk_*, those jmp instruction must be treated as an indirect jump. Since optprobe prohibits to optimize probes in the function which uses an indirect jump, it also needs to find out the function which jump to __x86_indirect_thunk_* and disable optimization. Add a check that the jump target address is between the __indirect_thunk_start/end when optimizing kprobe. Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
-
Masami Hiramatsu authored
CVE-2017-5715 (Spectre v2 retpoline) commit c1804a23 upstream. Mark __x86_indirect_thunk_* functions as blacklist for kprobes because those functions can be called from anywhere in the kernel including blacklist functions of kprobes. Signed-off-by:
-
Masami Hiramatsu authored
CVE-2017-5715 (Spectre v2 retpoline) commit 736e80a4 upstream. Introduce start/end markers of __x86_indirect_thunk_* functions. To make it easy, consolidate .text.__x86.indirect_thunk.* sections to one .text.__x86.indirect_thunk section and put it in the end of kernel text section and adds __indirect_thunk_start/end so that other subsystem (e.g. kprobes) can identify it. Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) commit 6f41c34d upstream. The machine check idtentry uses an indirect branch directly from the low level code. This evades the speculation protection. Replace it by a direct call into C code and issue the indirect call there so the compiler can apply the proper speculation protection. Signed-off-by:
Borislav Petkov <bp@alien8.de> Reviewed-by:
Peter Zijlstra <peterz@infradead.org> Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801181626290.1847@nanosSigned-off-by:
-
Andi Kleen authored
CVE-2017-5715 (Spectre v2 retpoline) commit 6cfb521a upstream. Add a marker for retpoline to the module VERMAGIC. This catches the case when a non RETPOLINE compiled module gets loaded into a retpoline kernel, making it insecure. It doesn't handle the case when retpoline has been runtime disabled. Even in this case the match of the retcompile status will be enforced. This implies that even with retpoline run time disabled all modules loaded need to be recompiled. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 retpoline) commit 28d437d5 upstream. The PAUSE instruction is currently used in the retpoline and RSB filling macros as a speculation trap. The use of PAUSE was originally suggested because it showed a very, very small difference in the amount of cycles/time used to execute the retpoline as compared to LFENCE. On AMD, the PAUSE instruction is not a serializing instruction, so the pause/jmp loop will use excess power as it is speculated over waiting for return to mispredict to the correct target. The RSB filling macro is applicable to AMD, and, if software is unable to verify that LFENCE is serializing on AMD (possible when running under a hypervisor), the generic retpoline support will be used and, so, is also applicable to AMD. Keep the current usage of PAUSE for Intel, but add an LFENCE instruction to the speculation trap for AMD. The same sequence has been adopted by GCC for the GCC generated retpolines. Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) commit b8b9ce4b upstream. Remove the compile time warning when CONFIG_RETPOLINE=y and the compiler does not have retpoline support. Linus rationale for this is: It's wrong because it will just make people turn off RETPOLINE, and the asm updates - and return stack clearing - that are independent of the compiler are likely the most important parts because they are likely the ones easiest to target. And it's annoying because most people won't be able to do anything about it. The number of people building their own compiler? Very small. So if their distro hasn't got a compiler yet (and pretty much nobody does), the warning is just annoying crap. It is already properly reported as part of the sysfs interface. The compile-time warning only encourages bad things. Fixes: 76b04384 ("x86/retpoline: Add initial retpoline support") Requested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit 117cc7a9 upstream. In accordance with the Intel and AMD documentation, we need to overwrite all entries in the RSB on exiting a guest, to prevent malicious branch target predictions from affecting the host kernel. This is needed both for retpoline and for IBRS. [ak: numbers again for the RSB stuffing labels] Signed-off-by:
Razvan Ghitulete <rga@amazon.de> Signed-off-by:
-
Andi Kleen authored
CVE-2017-5715 (Spectre v2 retpoline) commit 7614e913 upstream. Convert all indirect jumps in 32bit irq inline asm code to use non speculative sequences. Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515707194-20531-12-git-send-email-dwmw@amazon.co.ukSigned-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit 5096732f upstream. Convert all indirect jumps in 32bit checksum assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit ea08816d upstream. Convert indirect call in Xen hypercall to use non-speculative sequence, when CONFIG_RETPOLINE is enabled. Signed-off-by:
Juergen Gross <jgross@suse.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515707194-20531-10-git-send-email-dwmw@amazon.co.ukSigned-off-by:
-
