mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nadav Amit <nadav.amit@gmail.com>
To: Wanpeng Li <kernellwp@gmail.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	kvm <kvm@vger.kernel.org>, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Wanpeng Li" <wanpeng.li@hotmail.com>
Subject: Re: [PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation
Date: Wed, 19 Jul 2017 15:53:16 -0700	[thread overview]
Message-ID: <539DB8ED-1315-41DA-8F61-1036D44E5E48@gmail.com> (raw)
In-Reply-To: <CANRm+Cz53ZifZ_G_qQsXWTysyDvNwTDY_YYceL_WZEhpMJae0w@mail.gmail.com>

Wanpeng Li <kernellwp@gmail.com> wrote:

> 2017-07-20 0:25 GMT+08:00 Nadav Amit <nadav.amit@gmail.com>:
>> Radim Krčmář <rkrcmar@redhat.com> wrote:
>> 
>>> 2017-07-19 08:14-0700, Nadav Amit:
>>>> Radim Krčmář <rkrcmar@redhat.com> wrote:
>>>>> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
>>>>> 
>>>>> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
>>>>> {
>>>>> +   unsigned long old_rflags = to_vmx(vcpu)->rflags;
>>>> 
>>>> It assumes rflags was decached from the VMCS before. Probably it is true, but…
>>> 
>>> Right, it's better to use accessors everywhere, thanks.
>>> The line should read:
>>> 
>>> +     unsigned long old_rflags = vmx_get_rflags(vcpu);
>>> 
>>> ---8<---
>>> This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y
>>> or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it
>>> tries to emulate invalid guest state task-switch:
>>> 
>>> kvm_exit: reason TASK_SWITCH rip 0x0 info 40000058 0
>>> kvm_emulate_insn: 42000:0:0f 0b (0x2)
>>> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
>>> kvm_inj_exception: #UD (0x0)
>>> kvm_entry: vcpu 0
>>> kvm_exit: reason TASK_SWITCH rip 0x0 info 40000058 0
>>> kvm_emulate_insn: 42000:0:0f 0b (0x2)
>>> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
>>> kvm_inj_exception: #UD (0x0)
>>> 
>>> It appears that the task-switch emulation updates rflags (and vm86 flag)
>>> only after the segments are loaded, causing vmx->emulation_required to
>>> be set, when in fact invalid guest state emulation is not needed.
>>> 
>>> This patch fixes it by updating vmx->emulation_required after the rflags
>>> (and vm86 flag) is updated.
>>> 
>>> Suggested-by: Nadav Amit <nadav.amit@gmail.com>
>>> Signed-off-by: Wanpeng Li <wanpeng.li@hotmail.com>
>>> [Wanpeng wrote the commit message with initial patch and Radim moved the
>>> update to vmx_set_rflags and added Paolo's suggestion for the check.]
>>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>>> ---
>>> arch/x86/kvm/vmx.c | 15 ++++++++++-----
>>> 1 file changed, 10 insertions(+), 5 deletions(-)
>>> 
>>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>>> index 84e62acf2dd8..a776aea0043a 100644
>>> --- a/arch/x86/kvm/vmx.c
>>> +++ b/arch/x86/kvm/vmx.c
>>> @@ -2326,6 +2326,11 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
>>>      __vmx_load_host_state(to_vmx(vcpu));
>>> }
>>> 
>>> +static bool emulation_required(struct kvm_vcpu *vcpu)
>>> +{
>>> +     return emulate_invalid_guest_state && !guest_state_valid(vcpu);
>>> +}
>>> +
>>> static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
>>> 
>>> /*
>>> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
>>> 
>>> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
>>> {
>>> +     unsigned long old_rflags = vmx_get_rflags(vcpu);
>>> +
>>>      __set_bit(VCPU_EXREG_RFLAGS, (ulong *)&vcpu->arch.regs_avail);
>>>      to_vmx(vcpu)->rflags = rflags;
>>>      if (to_vmx(vcpu)->rmode.vm86_active) {
>>> @@ -2370,6 +2377,9 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
>>>              rflags |= X86_EFLAGS_IOPL | X86_EFLAGS_VM;
>>>      }
>>>      vmcs_writel(GUEST_RFLAGS, rflags);
>>> +
>>> +     if ((old_rflags ^ rflags) & X86_EFLAGS_VM)
>>> +             to_vmx(vcpu)->emulation_required = emulation_required(vcpu);
>> 
>> Sorry for not pointing it before, but here you compare the old_rflags with
>> the new rflags but after you already “massaged” it. So the value you compare
>> with is not what the guest “sees”.
> 
> So you mean we should use unsigned long old_rflags =
> vmcs_readl(GUEST_RFLAGS); right?

No. The problem is not with old_rflags now, but with rflags. If vm86_active,
then rflags is changed and you don’t compare the guest-visible rflags
anymore.

  reply	other threads:[~2017-07-19 22:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-11  7:13 [PATCH] " Wanpeng Li
2017-07-11 15:54 ` Radim Krčmář
2017-07-11 16:09   ` Paolo Bonzini
2017-07-12 13:50     ` Wanpeng Li
2017-07-19  5:34 ` Wanpeng Li
2017-07-19 11:29   ` Radim Krčmář
2017-07-19 15:14     ` Nadav Amit
2017-07-19 16:19       ` [PATCH v2] " Radim Krčmář
2017-07-19 16:25         ` Nadav Amit
2017-07-19 22:48           ` Wanpeng Li
2017-07-19 22:53             ` Nadav Amit [this message]
2017-07-19 23:01               ` Wanpeng Li
2017-07-19 23:06                 ` Nadav Amit
2017-07-19 23:09                   ` Wanpeng Li
2017-07-19 23:40 Wanpeng Li
2017-07-20  7:57 ` Radim Krčmář
2017-07-20  8:04   ` Wanpeng Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539DB8ED-1315-41DA-8F61-1036D44E5E48@gmail.com \
    --to=nadav.amit@gmail.com \
    --cc=kernellwp@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=wanpeng.li@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®