- 05 Feb, 2018 40 commits
-
-
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 <dwmw@amazon.co.uk> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Arjan van de Ven <arjan@linux.intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> 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-8-git-send-email-dwmw@amazon.co.ukSigned-off-by:
Razvan Ghitulete <rga@amazon.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f190ccc7f1fdd5eea12cdffc10332d8c715b7919) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
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:
-
Andrey Ryabinin authored
CVE-2017-5715 (Spectre v2 retpoline) commit 196bd485 upstream. Currently we use current_stack_pointer() function to get the value of the stack pointer register. Since commit: f5caf621 ("x86/asm: Fix inline asm call constraints for Clang") ... we have a stack register variable declared. It can be used instead of current_stack_pointer() function which allows to optimize away some excessive "mov %rsp, %<dst>" instructions: -mov %rsp,%rdx -sub %rdx,%rax -cmp $0x3fff,%rax -ja ffffffff810722fd <ist_begin_non_atomic+0x2d> +sub %rsp,%rax +cmp $0x3fff,%rax +ja ffffffff810722fa <ist_begin_non_atomic+0x2a> Remove current_stack_pointer(), rename __asm_call_sp to current_stack_pointer and use it instead of the removed function. Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Reviewed-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> 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/20170929141537.29167-1-aryabinin@virtuozzo.comSigned-off-by:
David Woodhouse <dwmw@amazon.co.ku> Signed-off-by:
-
Andy Lutomirski authored
CVE-2017-5715 (Spectre v2 retpoline) commit b8b7abae upstream. Otherwise we might have the PCID feature bit set during cpu_init(). This is just for robustness. I haven't seen any actual bugs here. Signed-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) commit b9e705ef upstream. Where an ALTERNATIVE is used in the middle of an inline asm block, this would otherwise lead to the following instruction being appended directly to the trailing ".popsection", and a failed compile. Fixes: 9cebed42 ("x86, alternative: Use .pushsection/.popsection") Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) commit 61dc0f55 upstream. Implement the CPU vulnerabilty show functions for meltdown, spectre_v1 and spectre_v2. Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Will Deacon <will.deacon@arm.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Borislav Petkov <bp@alien8.de> Cc: David Woodhouse <dwmw@amazon.co.uk> Link: https://lkml.kernel.org/r/20180107214913.177414879@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) commit 87590ce6 upstream. As the meltdown/spectre problem affects several CPU architectures, it makes sense to have common way to express whether a system is affected by a particular vulnerability or not. If affected the way to express the mitigation should be common as well. Create /sys/devices/system/cpu/vulnerabilities folder and files for meltdown, spectre_v1 and spectre_v2. Allow architectures to override the show function. Signed-off-by:
-
Borislav Petkov authored
CVE-2017-5715 (Spectre v2 retpoline) commit 62a67e12 upstream. Should be easier when following boot paths. It probably is a left over from the x86 unification eons ago. No functionality change. Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: Andy Lutomirski <luto@kernel.org> 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: Josh Poimboeuf <jpoimboe@redhat.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/20161024173844.23038-3-bp@alien8.deSigned-off-by:
-
David Woodhouse authored
CVE-2017-5715 (Spectre v2 retpoline) Add the bug bits for spectre v1/2 and force them unconditionally for all cpus. Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) Use the name associated with the particular attack which needs page table isolation for mitigation. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 retpoline) AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) Many x86 CPUs leak information to user space due to missing isolation of user space and kernel space page tables. There are many well documented ways to exploit that. The upcoming software migitation of isolating the user and kernel space page tables needs a misfeature flag so code can be made runtime conditional. Add the BUG bits which indicates that the CPU is affected and add a feature bit which indicates that the software migitation is enabled. Assume for now that _ALL_ x86 CPUs are affected by this. Exceptions can be made later. Signed-off-by:
-
Thomas Gleixner authored
CVE-2017-5715 (Spectre v2 retpoline) commit 6cbd2171 upstream. There is currently no way to force CPU bug bits like CPU feature bits. That makes it impossible to set a bug bit once at boot and have it stick for all upcoming CPUs. Extend the force set/clear arrays to handle bug bits as well. Signed-off-by:
-
Andy Lutomirski authored
CVE-2017-5715 (Spectre v2 retpoline) commit 8bf1ebca upstream. There are multiple call sites that apply forced CPU caps. Factor them into a helper. Signed-off-by:
-
He Chen authored
CVE-2017-5715 (Spectre v2 retpoline) Sparse populated CPUID leafs are collected in a software provided leaf to avoid bloat of the x86_capability array, but there is no way to rebuild the real leafs (e.g. for KVM CPUID enumeration) other than rereading the CPUID leaf from the CPU. While this is possible it is problematic as it does not take software disabled features into account. If a feature is disabled on the host it should not be exposed to a guest either. Add get_scattered_cpuid_leaf() which rebuilds the leaf from the scattered cpuid table information and the active CPU features. [ tglx: Rewrote changelog ] Signed-off-by:
He Chen <he.chen@linux.intel.com> Reviewed-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit ac92d827. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 87f0ff16. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit ffafbf6a. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 5f922fcb. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit fa24f391. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 1c050491. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 9c852c53. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 904c6712. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 905b2bac. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 021a73b4. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit eccbd5ac. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 6d289c83. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 7de295e2. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit f011884a. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 0e2f6c3e. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit e231ae74. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 92e0b0d6. Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5753 (revert embargoed) CVE-2017-5715 (revert embargoed) This reverts commit 49bb7a3c. Signed-off-by:
-
