- 05 Feb, 2018 40 commits
-
-
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 <elena.reshetova@intel.com> Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
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:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit e70e5892 upstream. Convert all indirect jumps in hyperv inline asm code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit 9351803b upstream. Convert all indirect jumps in ftrace 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 2641f08b upstream. Convert indirect jumps in core 32/64bit entry assembler code to use non-speculative sequences when CONFIG_RETPOLINE is enabled. Don't use CALL_NOSPEC in entry_SYSCALL_64_fastpath because the return address after the 'call' instruction must be *precisely* at the .Lentry_SYSCALL_64_after_fastpath label for stub_ptregs_64 to work, and the use of alternatives will mess that up unless we play horrid games to prepend with NOPs and make the variants the same length. It's not worth it; in the case where we ALTERNATIVE out the retpoline, the first instruction at __x86.indirect_thunk.rax is going to be a bare jmp *%rax anyway. Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit 9697fa39 upstream. Convert all indirect jumps in crypto 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 da285121 upstream. Add a spectre_v2= option to select the mitigation used for the indirect branch speculation vulnerability. Currently, the only option available is retpoline, in its various forms. This will be expanded to cover the new IBRS/IBPB microcode features. The RETPOLINE_AMD feature relies on a serializing LFENCE for speculation control. For AMD hardware, only set RETPOLINE_AMD if LFENCE is a serializing instruction, which is indicated by the LFENCE_RDTSC feature. [ tglx: Folded back the LFENCE/AMD fixes and reworked it so IBRS integration becomes simple ] Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit 76b04384 upstream. Enable the use of -mindirect-branch=thunk-extern in newer GCC, and provide the corresponding thunks. Provide assembler macros for invoking the thunks in the same way that GCC does, from native and inline assembler. This adds X86_FEATURE_RETPOLINE and sets it by default on all CPUs. In some circumstances, IBRS microcode features may be used instead, and the retpoline can be disabled. On AMD CPUs if lfence is serialising, the retpoline can be dramatically simplified to a simple "lfence; jmp *\reg". A future patch, after it has been verified that lfence really is serialising in all circumstances, can enable this by setting the X86_FEATURE_RETPOLINE_AMD feature bit in addition to X86_FEATURE_RETPOLINE. Do not align the retpoline in the altinstr section, because there is no guarantee that it stays aligned when it's copied over the oldinstr during alternative patching. [ Andi Kleen: Rename the macros, add CONFIG_RETPOLINE option, export thunks] [ tglx: Put actual function CALL/JMP in front of the macros, convert to symbolic labels ] [ dwmw2: Convert back to numeric labels, merge objtool fixes ] Signed-off-by:
-
Masahiro Yamada authored
CVE-2017-5715 (Spectre v2 retpoline) commit 4f920843 upstream. The macro MODULE is not a config option, it is a per-file build option. So, config_enabled(MODULE) is not sensible. (There is another case in include/linux/export.h, where config_enabled() is used against a non-config option.) This commit renames some macros in include/linux/kconfig.h for the use for non-config macros and replaces config_enabled(MODULE) with __is_defined(MODULE). I am keeping config_enabled() because it is still referenced from some places, but I expect it would be deprecated in the future. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Al Viro authored
CVE-2017-5715 (Spectre v2 retpoline) commit 22823ab4 upstream. Add asm-usable variants of EXPORT_SYMBOL/EXPORT_SYMBOL_GPL. This commit just adds the default implementation; most of the architectures can simply add export.h to asm/Kbuild and start using <asm/export.h> from assembler. The rest needs to have their <asm/export.h> define everal macros and then explicitly include <asm-generic/export.h> One area where the things might diverge from default is the alignment; normally it's 8 bytes on 64bit targets and 4 on 32bit ones, both for unsigned long and for struct kernel_symbol. Unfortunately, amd64 and m68k are unusual - m68k aligns to 2 bytes (for both) and amd64 aligns struct kernel_symbol to 16 bytes. For those we'll need asm/export.h to override the constants used by generic version - KSYM_ALIGN and KCRC_ALIGN for kernel_symbol and unsigned long resp. And no, __alignof__ would not do the trick - on amd64 __alignof__ of struct kernel_symbol is 8, not 16. More serious source of unpleasantness is treatment of function descriptors on architectures that have those. Things like ppc64, parisc, ia64, etc. need more than the address of the first insn to call an arbitrary function. As the result, their representation of pointers to functions is not the typical "address of the entry point" - it's an address of a small static structure containing all the required information (including the entry point, of course). Sadly, the asm-side conventions differ in what the function name refers to - entry point or the function descriptor. On ppc64 we do the latter; bar: .quad foo is what void (*bar)(void) = foo; turns into and the rare places where we need to explicitly work with the label of entry point are dealt with as DOTSYM(foo). For our purposes it's ideal - generic macros are usable. However, parisc would have foo and P%foo used for label of entry point and address of the function descriptor and bar: .long P%foo woudl be used instead. ia64 goes similar to parisc in that respect, except that there it's @fptr(foo) rather than P%foo. Such architectures need to define KSYM_FUNC that would turn a function name into whatever is needed to refer to function descriptor. What's more, on such architectures we need to know whether we are exporting a function or an object - in assembler we have to tell that explicitly, to decide whether we want EXPORT_SYMBOL(foo) produce e.g. __ksymtab_foo: .quad foo or __ksymtab_foo: .quad @fptr(foo) For that reason we introduce EXPORT_DATA_SYMBOL{,_GPL}(), to be used for exports of data objects. On normal architectures it's the same thing as EXPORT_SYMBOL{,_GPL}(), but on parisc-like ones they differ and the right one needs to be used. Most of the exports are functions, so we keep EXPORT_SYMBOL for those... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Andy Lutomirski authored
CVE-2017-5715 (Spectre v2 retpoline) commit f005f5d8 upstream. asm/alternative.h isn't directly useful from assembly, but it shouldn't break the build. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/e5b693fcef99fe6e80341c9e97a002fb23871e91.1461698311.git.luto@kernel.orgSigned-off-by:
-
Adam Borowski authored
CVE-2017-5715 (Spectre v2 retpoline) commit 334bb773 upstream. Commit 4efca4ed ("kbuild: modversions for EXPORT_SYMBOL() for asm") adds modversion support for symbols exported from asm files. Architectures must include C-style declarations for those symbols in asm/asm-prototypes.h in order for them to be versioned. Add these declarations for x86, and an architecture-independent file that can be used for common symbols. With f27c2f69 reverting 8ab2ae65 ("default exported asm symbols to zero") we produce a scary warning on x86, this commit fixes that. Signed-off-by:
Adam Borowski <kilobyte@angband.pl> Tested-by:
Kalle Valo <kvalo@codeaurora.org> Acked-by:
Nicholas Piggin <npiggin@gmail.com> Tested-by:
Peter Wu <peter@lekensteyn.nl> Tested-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
