linux-kernel - Re: [PATCH] KVM: nVMX: Fix exception injection

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, 20 Jul 2017 10:31:26 +0800
From:   Wanpeng Li <kernellwp@...il.com>
To:     Jim Mattson <jmattson@...gle.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kvm <kvm@...r.kernel.org>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Wanpeng Li <wanpeng.li@...mail.com>
Subject: Re: [PATCH] KVM: nVMX: Fix exception injection

Hi Jim,
2017-07-19 2:47 GMT+08:00 Jim Mattson <jmattson@...gle.com>:
> Why do we expect the VM_EXIT_INTR_INFO and EXIT_QUALIFICATION fields
> of the VMCS to have the correct values for the injected exception?

Good point, I think we should synthesize VM_EXIT_INTR_INFO and
EXIT_QUALIFICATION manually, I will post a patch for it. Btw, how
about setting EXIT_QULIFICATION to vcpu->arch.cr2 for the page fault
exception and 0 for other exceptions?

Regards,
Wanpeng Li

>
> On Mon, Jun 5, 2017 at 5:19 AM, Wanpeng Li <kernellwp@...il.com> wrote:
>> 2017-06-05 20:07 GMT+08:00 Paolo Bonzini <pbonzini@...hat.com>:
>>>
>>>
>>> On 03/06/2017 05:21, Wanpeng Li wrote:
>>>> Commit 0b6ac343fc (KVM: nVMX: Correct handling of exception injection) mentioned
>>>> that "KVM wants to inject page-faults which it got to the guest. This function
>>>> assumes it is called with the exit reason in vmcs02 being a #PF exception".
>>>> Commit e011c663 (KVM: nVMX: Check all exceptions for intercept during delivery to
>>>> L2) allows to check all exceptions for intercept during delivery to L2. However,
>>>> there is no guarantee the exit reason is exception currently, when there is an
>>>> external interrupt occurred on host, maybe a time interrupt for host which should
>>>> not be injected to guest, and somewhere queues an exception, then the function
>>>> nested_vmx_check_exception() will be called and the vmexit emulation codes will
>>>> try to emulate the "Acknowledge interrupt on exit" behavior, the warning is
>>>> triggered.
>>>>
>>>> This patch fixes it by confirming to inject exception to the guest when the exit
>>>> reason in vmcs02 is exception.
>>>
>>> I am confused.  On one hand, the comment originally "this is the only
>>> case in which KVM injects a #PF when L2 is running", but I'm not sure
>>> it's true.  For example, KVM could emulate a movs while running L2.  If
>>> the source is MMIO and the destination is a missing page, the original
>>> failure could be an EPT misconfig, but the access to the destination
>>> would cause a #PF in the guest (could be a nice testcase for
>>> kvm-unit-tests, BTW :)).
>>>
>>> On the other hand, why would you reuse to_vmx(vcpu)->exit_reason in
>>> nested_vmx_check_exception?  Would the following fix the bug:
>>>
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index 9b4b5d6dcd34..ca5d2b93385c 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -2425,7 +2425,7 @@ static int nested_vmx_check_exception(struct
>>> kvm_vcpu *vcpu, unsigned nr)
>>>         if (!(vmcs12->exception_bitmap & (1u << nr)))
>>>                 return 0;
>>>
>>> -       nested_vmx_vmexit(vcpu, to_vmx(vcpu)->exit_reason,
>>> +       nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
>>>                           vmcs_read32(VM_EXIT_INTR_INFO),
>>>                           vmcs_readl(EXIT_QUALIFICATION));
>>>         return 1;
>>>
>>
>> You are right.
>>
>> Regards,
>> Wanpeng Li