- 09 Feb, 2018 28 commits
-
-
Rafael David Tinoco authored
BugLink: https://bugs.launchpad.net/bugs/1569925 If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by:
Rafael David Tinoco <rafael.tinoco@canonical.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry-picked from commit d7549412 next-20180117) Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
-
Xinyu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1743053 LITEON EP1 has the same timeout issues as CX1 series devices. Revert max_sectors to the value of 1024. 'e0edc8c5 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")' Signed-off-by:
Xinyu Lin <xinyu0123@gmail.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org (cherry picked from commit db5ff909) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Kleber Souza <kleber.souza@canonical.com> Signed-off-by:
-
Alexander Yarygin authored
BugLink: http://bugs.launchpad.net/bugs/1747090 Some facility bits are in a range that is defined to be "ok for guests without any necessary hypervisor changes". Enable those bits. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> (cherry picked from commit ed8dda0b) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Christian Borntraeger authored
BugLink: http://bugs.launchpad.net/bugs/1747090 The new firmware interfaces for branch prediction behaviour changes are transparently available for the guest. Nevertheless, there is new state attached that should be migrated and properly resetted. Provide a mechanism for handling reset and migration. Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> (back ported from commit 35b3fde6) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) When we have full retpoline enabled then we do not actually require IBPB flushes when entering the kernel. Add a new use_ibpb bit to represent when we have retpoline enabled. Further split the enable bit into two 0x1 representing whether entry IBPB is enabled and 0x10 representing whether kernel flushes for userspace/VMs etc are applied. 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:
-
Stefan Bader authored
CVE-2017-5715 (Spectre v2 Intel) Initial change was missing code to correctly mask EDX bits of cpuid level 7.0. Fixes: 8339cae2 ("KVM: x86: Add speculative control CPUID support for guests") Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Provide the guest with the speculative control CPUID related values. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is going to run a VCPU different from what was previously run. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Set/restore the guests IBRS value on VM entry. On VM exit back to the kernel save the guest IBRS value and then set IBRS to 1. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Allow guest access to the speculative control MSRs without being intercepted. Signed-off-by:
-
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:
-
- 05 Feb, 2018 10 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:
-
