[CentOS] Panic / EL6 / KVM / kernel-2.6.32-754.2.1.el6.x86_64

Stephen John Smoogen smooge at gmail.com
Wed Aug 29 22:34:56 UTC 2018


On Wed, 29 Aug 2018 at 18:16, Leon Fauster via CentOS <centos at centos.org>
wrote:

> Am 29.08.2018 um 23:46 schrieb Stephen John Smoogen <smooge at gmail.com>:
> >
> > On Wed, 29 Aug 2018 at 17:41, Leon Fauster via CentOS <centos at centos.org>
> wrote:
> >> Since the update from kernel-2.6.32-754.2.1.el6.x86_64
> >> to kernel-2.6.32-754.3.5.el6.x86_64 I can not boot my
> >> KVM guests anymore!? The workstation panics immediately!
> >>
> >> I would not have expected this behavior now (last phase of OS).
> >> It was very robust until now (Optiplex Workstation). I see some KVM
> >> related lines in the changelog.diff. Before swimming upstream:
> >>
> >> Does some one have problems related to KVM with
> kernel-2.6.32-754.3.5.el6.x86_64 ??
> >>
> >
> > Not that I know of.
> > * Does the problem go away if you back off to 2.1 ?
>
> Yes
>
>
> > * And what type of panic does it say?
>
> I will try to grep some lines at the console tomorrow.
>
>
> > * What kind of Optiplex Workstation with memory/cpu type/cores?
>
> # virsh sysinfo
> <sysinfo type='smbios'>
>  <bios>
>    <entry name='vendor'>Dell Inc.</entry>
>    <entry name='version'>A19</entry>
>    <entry name='date'>05/31/2011</entry>
>    <entry name='release'>18.0</entry>
>  </bios>
>


So looking at the kernel changelog, there are a lot of KVM changes which
look related to the Spectre and related CVE items. All of them seem to have
landed in a non-released kernel.. I am going to guess you are tickling one
of them so hopefully the oops will help figure it out. The only other item
I would wonder is if there is a BIOS update need again due to Spectre but
that would be a last thing to try.

* Tue Jul 31 2018 Phillip Lougher <plougher at redhat.com> [2.6.32-754.3.2.el6]
- [kvm] VMX: Fix host GDT.LIMIT corruption (CVE-2018-10301) (Paolo Bonzini)
[1601851] {CVE-2018-10901}
..
- [x86] KVM/VMX: Initialize the vmx_l1d_flush_pages' content (Waiman Long)
[1593376] {CVE-2018-3620}
- [x86] kvm: Don't flush L1D cache if VMENTER_L1D_FLUSH_NEVER (Waiman Long)
[1593376] {CVE-2018-3620}
- [x86] kvm: Take out the unused nosmt module parameter (Waiman Long)
[1593376] {CVE-2018-3620}
...
- [x86] bugs, kvm: Introduce boot-time control of L1TF mitigations (Waiman
Long) [1593376] {CVE-2018-3620}
...
- [x86] kvm: Allow runtime control of L1D flush (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] kvm: Serialize L1D flush parameter setter (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] kvm: Move l1tf setup function (Waiman Long) [1593376]
{CVE-2018-3620}
...
- [x86] kvm: Drop L1TF MSR list approach (Waiman Long) [1593376]
{CVE-2018-3620}
...
- [x86] KVM/VMX: Use MSR save list for IA32_FLUSH_CMD if required (Waiman
Long) [1593376] {CVE-2018-3620}
- [x86] KVM/VMX: Extend add_atomic_switch_msr() to allow VMENTER only MSRs
(Waiman Long) [1593376] {CVE-2018-3620}
- [x86] KVM/VMX: Separate the VMX AUTOLOAD guest/host number accounting
(Waiman Long) [1593376] {CVE-2018-3620}
- [x86] KVM/VMX: Add find_msr() helper function (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] KVM/VMX: Split the VMX MSR LOAD structures to have an host/guest
numbers (Waiman Long) [1593376] {CVE-2018-3620}
- [x86] KVM/VMX: Add L1D flush logic (Waiman Long) [1593376] {CVE-2018-3620}
- [kvm] VMX: Make indirect call speculation safe (Waiman Long) [1593376]
{CVE-2018-3620}
- [kvm] VMX: Enable acknowledge interupt on vmexit (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] KVM/VMX: Add L1D MSR based flush (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] KVM/VMX: Add L1D flush algorithm (Waiman Long) [1593376]
{CVE-2018-3620}
- [x86] KVM/VMX: Add module argument for L1TF mitigation (Waiman Long)
[1593376] {CVE-2018-3620}
- [x86] KVM: Warn user if KVM is loaded SMT and L1TF CPU bug being present
(Waiman Long) [1593376] {CVE-2018-3620}
- [kvm] x86: Introducing kvm_x86_ops VM init/destroy hooks (Waiman Long)
[1593376] {CVE-2018-3620}
...
it keeps going and going. rpm -q kernel-2.6.32-754.3.5 --changelog will
give you the gory details.


-- 
Stephen J Smoogen.



More information about the CentOS mailing list