- 12 Jan, 2018 34 commits
-
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
Andy Whitcroft <apw@canonical.com> (backported from commit 33e16ee8bd43aa4f065e17abbe9ed66457327b84) Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 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-5753 CVE-2017-5715 Add code to pad the local CPU's RSB entries to protect from previous less privilege mode. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 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-5753 CVE-2017-5715 Set IBPB (Indirect branch prediction barrier) when switching VM. Signed-off-by:
-
Wei Wang authored
CVE-2017-5753 CVE-2017-5715 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-5753 CVE-2017-5715 Stuff RSB to prevent RSB underflow on non-SMEP platform. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 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-5753 CVE-2017-5715 Set IBPB on context switch with changing of page table. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Clear IBRS when cpu is offlined and set it when brining it back online. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Clear IBRS on idle entry and set it on idle exit into kernel on mwait. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Set IBRS upon kernel entrance via syscall and interrupts. Clear it upon exit. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Setup macros to control IBRS and IBPB Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 Report presence of IBPB and IBRS. Signed-off-by:
-
Tim Chen authored
CVE-2017-5753 CVE-2017-5715 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:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
Elena Reshetova <elena.reshetova@intel.com> Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 Real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 real commit text tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 When constant blinding is enabled (bpf_jit_harden = 1), this adds a generic memory barrier (lfence for intel, mfence for AMD) 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. For more details, please see this Google Project Zero report: tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 This adds a generic memory 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. For more details, please see this Google Project Zero report: tbd Signed-off-by:
-
Elena Reshetova authored
CVE-2017-5753 CVE-2017-5715 In constrast to existing mb() and rmb() barriers, gmb() barrier is arch-independent and can be used to implement any type of memory barrier. In x86 case, it is either lfence or mfence, based on processor type. ARM and others can define it according to their needs. Suggested-by:
Arjan van de Ven <arjan@linux.intel.com> Signed-off-by:
-
Daniel Borkmann authored
CVE-2017-5753 CVE-2017-5715 This work adds a generic facility for use from eBPF JIT compilers that allows for further hardening of JIT generated images through blinding constants. In response to the original work on BPF JIT spraying published by Keegan McAllister [1], most BPF JITs were changed to make images read-only and start at a randomized offset in the page, where the rest was filled with trap instructions. We have this nowadays in x86, arm, arm64 and s390 JIT compilers. Additionally, later work also made eBPF interpreter images read only for kernels supporting DEBUG_SET_MODULE_RONX, that is, x86, arm, arm64 and s390 archs as well currently. This is done by default for mentioned JITs when JITing is enabled. Furthermore, we had a generic and configurable constant blinding facility on our todo for quite some time now to further make spraying harder, and first implementation since around netconf 2016. We found that for systems where untrusted users can load cBPF/eBPF code where JIT is enabled, start offset randomization helps a bit to make jumps into crafted payload harder, but in case where larger programs that cross page boundary are injected, we again have some part of the program opcodes at a page start offset. With improved guessing and more reliable payload injection, chances can increase to jump into such payload. Elena Reshetova recently wrote a test case for it [2, 3]. Moreover, eBPF comes with 64 bit constants, which can leave some more room for payloads. Note that for all this, additional bugs in the kernel are still required to make the jump (and of course to guess right, to not jump into a trap) and naturally the JIT must be enabled, which is disabled by default. For helping mitigation, the general idea is to provide an option bpf_jit_harden that admins can tweak along with bpf_jit_enable, so that for cases where JIT should be enabled for performance reasons, the generated image can be further hardened with blinding constants for unpriviledged users (bpf_jit_harden == 1), with trading off performance for these, but not for privileged ones. We also added the option of blinding for all users (bpf_jit_harden == 2), which is quite helpful for testing f.e. with test_bpf.ko. There are no further e.g. hardening levels of bpf_jit_harden switch intended, rationale is to have it dead simple to use as on/off. Since this functionality would need to be duplicated over and over for JIT compilers to use, which are already complex enough, we provide a generic eBPF byte-code level based blinding implementation, which is then just transparently JITed. JIT compilers need to make only a few changes to integrate this facility and can be migrated one by one. This option is for eBPF JITs and will be used in x86, arm64, s390 without too much effort, and soon ppc64 JITs, thus that native eBPF can be blinded as well as cBPF to eBPF migrations, so that both can be covered with a single implementation. The rule for JITs is that bpf_jit_blind_constants() must be called from bpf_int_jit_compile(), and in case blinding is disabled, we follow normally with JITing the passed program. In case blinding is enabled and we fail during the process of blinding itself, we must return with the interpreter. Similarly, in case the JITing process after the blinding failed, we return normally to the interpreter with the non-blinded code. Meaning, interpreter doesn't change in any way and operates on eBPF code as usual. For doing this pre-JIT blinding step, we need to make use of a helper/auxiliary register, here BPF_REG_AX. This is strictly internal to the JIT and not in any way part of the eBPF architecture. Just like in the same way as JITs internally make use of some helper registers when emitting code, only that here the helper register is one abstraction level higher in eBPF bytecode, but nevertheless in JIT phase. That helper register is needed since f.e. manually written program can issue loads to all registers of eBPF architecture. The core concept with the additional register is: blind out all 32 and 64 bit constants by converting BPF_K based instructions into a small sequence from K_VAL into ((RND ^ K_VAL) ^ RND). Therefore, this is transformed into: BPF_REG_AX := (RND ^ K_VAL), BPF_REG_AX ^= RND, and REG <OP> BPF_REG_AX, so actual operation on the target register is translated from BPF_K into BPF_X one that is operating on BPF_REG_AX's content. During rewriting phase when blinding, RND is newly generated via prandom_u32() for each processed instruction. 64 bit loads are split into two 32 bit loads to make translation and patching not too complex. Only basic thing required by JITs is to call the helper bpf_jit_blind_constants()/bpf_jit_prog_release_other() pair, and to map BPF_REG_AX into an unused register. Small bpf_jit_disasm extract from [2] when applied to x86 JIT: echo 0 > /proc/sys/net/core/bpf_jit_harden ffffffffa034f5e9 + <x>: [...] 39: mov $0xa8909090,%eax 3e: mov $0xa8909090,%eax 43: mov $0xa8ff3148,%eax 48: mov $0xa89081b4,%eax 4d: mov $0xa8900bb0,%eax 52: mov $0xa810e0c1,%eax 57: mov $0xa8908eb4,%eax 5c: mov $0xa89020b0,%eax [...] echo 1 > /proc/sys/net/core/bpf_jit_harden ffffffffa034f1e5 + <x>: [...] 39: mov $0xe1192563,%r10d 3f: xor $0x4989b5f3,%r10d 46: mov %r10d,%eax 49: mov $0xb8296d93,%r10d 4f: xor $0x10b9fd03,%r10d 56: mov %r10d,%eax 59: mov $0x8c381146,%r10d 5f: xor $0x24c7200e,%r10d 66: mov %r10d,%eax 69: mov $0xeb2a830e,%r10d 6f: xor $0x43ba02ba,%r10d 76: mov %r10d,%eax 79: mov $0xd9730af,%r10d 7f: xor $0xa5073b1f,%r10d 86: mov %r10d,%eax 89: mov $0x9a45662b,%r10d 8f: xor $0x325586ea,%r10d 96: mov %r10d,%eax [...] As can be seen, original constants that carry payload are hidden when enabled, actual operations are transformed from constant-based to register-based ones, making jumps into constants ineffective. Above extract/example uses single BPF load instruction over and over, but of course all instructions with constants are blinded. Performance wise, JIT with blinding performs a bit slower than just JIT and faster than interpreter case. This is expected, since we still get all the performance benefits from JITing and in normal use-cases not every single instruction needs to be blinded. Summing up all 296 test cases averaged over multiple runs from test_bpf.ko suite, interpreter was 55% slower than JIT only and JIT with blinding was 8% slower than JIT only. Since there are also some extremes in the test suite, I expect for ordinary workloads that the performance for the JIT with blinding case is even closer to JIT only case, f.e. nmap test case from suite has averaged timings in ns 29 (JIT), 35 (+ blinding), and 151 (interpreter). BPF test suite, seccomp test suite, eBPF sample code and various bigger networking eBPF programs have been tested with this and were running fine. For testing purposes, I also adapted interpreter and redirected blinded eBPF image to interpreter and also here all tests pass. [1] http://mainisusuallyafunction.blogspot.com/2012/11/attacking-hardened-linux-systems-with.html [2] https://github.com/01org/jit-spray-poc-for-ksp/ [3] http://www.openwall.com/lists/kernel-hardening/2016/05/03/5Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (backported from commit 4f3446bb) Signed-off-by:
-
Daniel Borkmann authored
CVE-2017-5753 CVE-2017-5715 Since the blinding is strictly only called from inside eBPF JITs, we need to change signatures for bpf_int_jit_compile() and bpf_prog_select_runtime() first in order to prepare that the eBPF program we're dealing with can change underneath. Hence, for call sites, we need to return the latest prog. No functional change in this patch. Signed-off-by:
-
Daniel Borkmann authored
CVE-2017-5753 CVE-2017-5715 Move the functionality to patch instructions out of the verifier code and into the core as the new bpf_patch_insn_single() helper will be needed later on for blinding as well. No changes in functionality. Signed-off-by:
-
Borislav Petkov authored
CVE-2017-5754 This needs to happen early in kaiser_pagetable_walk(), before the hierarchy is established so that _PAGE_USER permission can be really set. A proper fix would be to teach kaiser_pagetable_walk() to update those permissions but the vsyscall page is the only exception here so ... Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 6dcf5491) Signed-off-by:
-
Thomas Gleixner authored
commit 1e547681 upstream. CVE-2017-5754 The recent changes for PTI touch cpu_tlbstate from various tlb_flush inlines. cpu_tlbstate is exported as GPL symbol, so this causes a regression when building out of tree drivers for certain graphics cards. Aside of that the export was wrong since it was introduced as it should have been EXPORT_PER_CPU_SYMBOL_GPL(). Use the correct PER_CPU export and drop the _GPL to restore the previous state which allows users to utilize the cards they payed for. As always I'm really thrilled to make this kind of change to support the sauce graphics corp. Fixes: 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4") Fixes: 6fd166aa ("x86/mm: Use/Fix PCID to optimize user/kernel switches") Reported-by:
Kees Cook <keescook@google.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Thomas Backlund <tmb@mageia.org> Signed-off-by:
-
Tom Lendacky authored
commit f4e9b7af upstream. CVE-2017-5753 CVE-2017-5715 The size for the Microcode Patch Block (MPB) for an AMD family 17h processor is 3200 bytes. Add a #define for fam17h so that it does not default to 2048 bytes and fail a microcode load/update. Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Borislav Petkov <bp@alien8.de> Link: https://lkml.kernel.org/r/20171130224640.15391.40247.stgit@tlendack-t1.amdoffice.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Alice Ferrazzi <alicef@gentoo.org> Signed-off-by:
-
Marcelo Henrique Cerri authored
Ignore: yes Signed-off-by:Marcelo Henrique Cerri <marcelo.cerri@canonical.com>
-
- 09 Jan, 2018 3 commits
-
-
Marcelo Henrique Cerri authored
Signed-off-by: -
Joseph Salisbury authored
BugLink: http://bugs.launchpad.net/bugs/1741934 There was a back port of upstream 4.4 stable commit 20cbe9a3 to Xenial which failed remove a kfree() from release_ds_buffer(). This commit does only that. It removes this extra kfree(). This left over kfree was causing a kernel trace on many systems as reported in the bug. This commit removes the kfree() like it should have been in the original commit. Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by: Brad Figg brad.figg@canonical.com Acked-by:
-
Marcelo Henrique Cerri authored
Ignore: yes Signed-off-by:
-
- 07 Jan, 2018 3 commits
-
-
Marcelo Henrique Cerri authored
Signed-off-by: -
Andy Lutomirski authored
CVE-2017-5754 commit cba4671a upstream. 32-bit kernels on new hardware will see PCID in CPUID, but PCID can only be used in 64-bit mode. Rather than making all PCID code conditional, just disable the feature on 32-bit builds. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Reviewed-by:
Nadav Amit <nadav.amit@gmail.com> Reviewed-by:
-
Marcelo Henrique Cerri authored
Ignore: yes Signed-off-by:
-
