linux-kernel - Re: VMs freezing when host is running 4.14

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Nov 2017 18:18:07 +0200
From:   Liran Alon <LIRAN.ALON@...CLE.COM>
To:     Radim Krčmář <rkrcmar@...hat.com>,
        Marc Haber <mh+linux-kernel@...schlus.de>
CC:     LKML <linux-kernel@...r.kernel.org>,
        "KVM-ML (kvm@...r.kernel.org)" <kvm@...r.kernel.org>,
        Wanpeng Li <kernellwp@...il.com>
Subject: Re: VMs freezing when host is running 4.14



On 23/11/17 17:59, Radim Krčmář wrote:
> 2017-11-23 16:20+0100, Marc Haber:
>> On Wed, Nov 22, 2017 at 05:43:13PM +0100, Radim Krčmář wrote:
>>> 2017-11-22 16:52+0100, Marc Haber:
>>>> On Wed, Nov 22, 2017 at 04:04:42PM +0100, 王金浦 wrote:
>>>>> So all guest kernels are 4.14, or also other older kernel?
>>>>
>>>> Guest kernels are also 4.14, but the issue disappears when the host is
>>>> downgraded to an older kernel. I therefore reckoned that the guest
>>>> kernel doesn't matter, but that was before I saw the trace in the log.
>>>
>>> The two most suspicious patches since 4.13 (which I assume works) are
>>>
>>>    664f8e26b00c ("KVM: X86: Fix loss of exception which has not yet been
>>>    injected")
>>
>> That one does not revert cleanly, the line in questions seems to have
>> been removed a bit later.
>>
>> Reject is:
>> 141 [24/5001]mh@fan:~/linux/git/linux ((v4.14.1) %) $ cat arch/x86/kvm/vmx.c.rej--- arch/x86/kvm/vmx.c
>> +++ arch/x86/kvm/vmx.c
>> @@ -2516,7 +2516,7 @@ static void vmx_queue_exception(struct kvm_vcpu *vcpu)
>>          struct vcpu_vmx *vmx = to_vmx(vcpu);
>>          unsigned nr = vcpu->arch.exception.nr;
>>          bool has_error_code = vcpu->arch.exception.has_error_code;
>> -       bool reinject = vcpu->arch.exception.injected;
>> +       bool reinject = vcpu->arch.exception.reinject;
>>          u32 error_code = vcpu->arch.exception.error_code;
>>          u32 intr_info = nr | INTR_INFO_VALID_MASK;
>
> This line one can be deleted as reinject isn't used in the function.
>
> Btw. there have been already many fixes from Liran Alon for that patch
> and your case could be the one adressed in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.spinics.net_lists_kvm_msg159158.html&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=206jU1rQdk3xs1DYWbQPz1gR7Iim02XOjwn458rwgIo&s=fz1JeZiSQBwqYpkmeX8OJukyC4M8BeXSuIOKwuVaeHg&e=
>
> The patch is incorrect, but you might be able to see only its benefits.

Actually I would first attempt to check this patch of mine:
https://www.spinics.net/lists/kvm/msg159062.html
It fixes a bug of a L2 exception accidentally being delivered into L1.

Regards,
-Liran
>
>>> and
>>>
>>>    9a6e7c39810e ("KVM: async_pf: Fix #DF due to inject "Page not Present"
>>>    and "Page Ready" exceptions simultaneously")
>>>
>>> please try reverting them to see if it helps,
>>
>> That one reverted cleanly. I am now running the new kernel on the
>> affected machine, and I think that a second machine has joined the
>> market of being affected.
>
> That one had much lower chances of being the culprit.
>
>> Would this matter on the host only or on the guests as well?
>
> Only on the host.
>
> Thanks.
>