Re: [PATCH v2] KVM: X86: Fix load RFLAGS w/o the fixed bit
From: David Hildenbrand
Date: Wed Dec 06 2017 - 09:41:10 EST
On 06.12.2017 12:59, Wanpeng Li wrote:
> From: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
>
> *** Guest State ***
> CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
> CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871
> CR3 = 0x00000000fffbc000
> RSP = 0x0000000000000000 RIP = 0x0000000000000000
> RFLAGS=0x00000000 DR7 = 0x0000000000000400
> ^^^^^^^^^^
>
> The failed vmentry is triggered by the following testcase when ept=Y:
>
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <linux/kvm.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
>
> long r[5];
> int main()
> {
> r[2] = open("/dev/kvm", O_RDONLY);
> r[3] = ioctl(r[2], KVM_CREATE_VM, 0);
> r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7);
> struct kvm_regs regs = {
> .rflags = 0,
> };
> ioctl(r[4], KVM_SET_REGS, ®s);
> ioctl(r[4], KVM_RUN, 0);
> }
>
> X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1
> of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails.
> This patch fixes it by oring X86_EFLAGS_FIXED during ioctl.
>
> Suggested-by: Jim Mattson <jmattson@xxxxxxxxxx>
> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
> Cc: Radim KrÄmÃÅ <rkrcmar@xxxxxxxxxx>
> Cc: Jim Mattson <jmattson@xxxxxxxxxx>
> Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxx>
> ---
> v1 -> v2:
> * Oring X86_EFLAGS_FIXED
>
> virt/kvm/kvm_main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index b55bad3..0f3f283 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2602,6 +2602,7 @@ static long kvm_vcpu_ioctl(struct file *filp,
> r = PTR_ERR(kvm_regs);
> goto out;
> }
> + kvm_regs->rflags |= X86_EFLAGS_FIXED;
> r = kvm_arch_vcpu_ioctl_set_regs(vcpu, kvm_regs);
> kfree(kvm_regs);
> break;
>
Not sure if failing KVM_SET_REGS would be nicer, but maybe this has
already been discussed. So this should be fine.
Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>
--
Thanks,
David / dhildenb