From: Paolo Bonzini <pbonzini@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>, Nadav Amit <namit@cs.technion.ac.il>
Cc: gleb@kernel.org, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/6] KVM: x86: check DR6/7 high-bits are clear only on long-mode
Date: Mon, 16 Jun 2014 13:09:56 +0200 [thread overview]
Message-ID: <539ED084.2000906@redhat.com> (raw)
In-Reply-To: <539EC7F7.2000208@gmail.com>
Il 16/06/2014 12:33, Nadav Amit ha scritto:
>>
>> Do you get this if the input register has bit 31 set?
> No. To be frank, the scenario may be considered a bit synthetic: the
> guest assigns a value to a general-purpose register in 64-bit mode,
> setting the high 32-bits to some non-zero value. Then, later, in 32-bit
> mode, the guest performs MOV DR instruction. In between the two
> assignments, the general purpose register is unmodified, so the high
> 32-bits of the general purpose registers are still set.
>
> Note that this scenario does not occur when MOV DR is emulated, but when
> handle_dr() is called. In this case, the entire 64-bits of the general
> purpose register used for MOV DR are read, regardless to the execution
> mode of the guest.
I wonder if the same bug happens elsewhere. For example,
kvm_emulate_hypercall doesn't look at CS.L/CS.DB, which is really a
corner case but arguably also a bug. kvm_hv_hypercall instead does it
right.
Perhaps we need a variant of kvm_register_read that (on 64-bit hosts)
checks EFER/CS.L/CS.DB and masks the returned value accordingly. You
could call it kvm_register_readl.
Paolo
next prev parent reply other threads:[~2014-06-16 11:10 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-15 13:12 [PATCH 0/6] KVM: x86: More emulator bugs Nadav Amit
2014-06-15 13:12 ` [PATCH 1/6] KVM: x86: bit-ops emulation ignores offset on 64-bit Nadav Amit
2014-06-15 13:12 ` [PATCH 2/6] KVM: x86: Wrong emulation on 'xadd X, X' Nadav Amit
2014-06-16 17:38 ` Bandan Das
2014-06-17 5:16 ` Paolo Bonzini
2014-06-17 15:35 ` Bandan Das
2014-06-17 16:49 ` Paolo Bonzini
2014-06-15 13:12 ` [PATCH 3/6] KVM: x86: Inter privilage level ret emulation is not implemeneted Nadav Amit
2014-06-15 13:13 ` [PATCH 4/6] KVM: x86: emulation of dword cmov on long-mode should clear [63:32] Nadav Amit
2014-06-15 13:13 ` [PATCH 5/6] KVM: x86: NOP emulation clears (incorrectly) the high 32-bits of RAX Nadav Amit
2014-06-15 13:13 ` [PATCH 6/6] KVM: x86: check DR6/7 high-bits are clear only on long-mode Nadav Amit
2014-06-16 10:17 ` Paolo Bonzini
2014-06-16 10:33 ` Nadav Amit
2014-06-16 11:09 ` Paolo Bonzini [this message]
2014-06-16 11:53 ` Nadav Amit
2014-06-16 14:56 ` Paolo Bonzini
2014-06-16 17:07 ` Nadav Amit
2014-06-18 14:19 ` [PATCH v2 0/9] KVM: x86: More emulator bugs Nadav Amit
2014-06-18 14:19 ` [PATCH v2 1/9] KVM: x86: bit-ops emulation ignores offset on 64-bit Nadav Amit
2014-06-18 14:19 ` [PATCH v2 2/9] KVM: x86: Wrong emulation on 'xadd X, X' Nadav Amit
2014-06-18 14:19 ` [PATCH v2 3/9] KVM: x86: Inter privilage level ret emulation is not implemeneted Nadav Amit
2014-06-18 14:19 ` [PATCH v2 4/9] KVM: x86: emulation of dword cmov on long-mode should clear [63:32] Nadav Amit
2014-06-18 14:19 ` [PATCH v2 5/9] KVM: x86: NOP emulation clears (incorrectly) the high 32-bits of RAX Nadav Amit
2014-06-18 14:19 ` [PATCH v2 6/9] KVM: x86: check DR6/7 high-bits are clear only on long-mode Nadav Amit
2014-06-18 14:19 ` [PATCH v2 7/9] KVM: x86: Hypercall handling does not considers opsize correctly Nadav Amit
2014-06-18 14:19 ` [PATCH v2 8/9] KVM: vmx: handle_cr ignores 32/64-bit mode Nadav Amit
2014-06-18 14:19 ` [PATCH v2 9/9] KVM: vmx: vmx instructions handling does not consider cs.l Nadav Amit
2014-06-18 15:41 ` Paolo Bonzini
2014-06-18 16:01 ` Nadav Amit
2014-06-18 16:06 ` Paolo Bonzini
2014-06-18 17:51 ` Nadav Amit
2014-06-19 9:45 ` Paolo Bonzini
2014-06-18 15:45 ` [PATCH v2 0/9] KVM: x86: More emulator bugs Paolo Bonzini
2014-06-16 10:18 ` [PATCH 0/6] " Paolo Bonzini
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=539ED084.2000906@redhat.com \
--to=pbonzini@redhat.com \
--cc=gleb@kernel.org \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=namit@cs.technion.ac.il \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.