From: Krish Sadhukhan <krish.sadhukhan@oracle.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH 2/3 v4] KVM: nSVM: Check that MBZ bits in CR3 and CR4 are not set on vmrun of nested guests
Date: Wed, 8 Jul 2020 15:51:38 -0700 [thread overview]
Message-ID: <ed07cbc2-991f-1f9e-9a4d-ef9b4294b373@oracle.com> (raw)
In-Reply-To: <699b4ea4-d8df-e098-8f5c-3abe8e4c138c@redhat.com>
On 7/8/20 3:03 AM, Paolo Bonzini wrote:
> On 08/07/20 02:39, Krish Sadhukhan wrote:
>> +extern int kvm_valid_cr4(struct kvm_vcpu *vcpu, unsigned long cr4);
>> +
> This should be added in x86.h, not here.
>
>> +static bool nested_vmcb_checks(struct vcpu_svm *svm, struct vmcb *vmcb)
>> {
>> if ((vmcb->save.efer & EFER_SVME) == 0)
>> return false;
>> @@ -231,6 +233,22 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
>> (vmcb->save.cr0 & X86_CR0_NW))
>> return false;
>>
>> + if (!is_long_mode(&(svm->vcpu))) {
>> + if (vmcb->save.cr4 & X86_CR4_PAE) {
>> + if (vmcb->save.cr3 & MSR_CR3_LEGACY_PAE_RESERVED_MASK)
>> + return false;
>> + } else {
>> + if (vmcb->save.cr3 & MSR_CR3_LEGACY_RESERVED_MASK)
>> + return false;
>> + }
>> + } else {
>> + if ((vmcb->save.cr4 & X86_CR4_PAE) &&
>> + (vmcb->save.cr3 & MSR_CR3_LONG_RESERVED_MASK))
>> + return false;
>> + }
> is_long_mode here is wrong, as it refers to the host.
>
> You need to do something like this:
>
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index 385461496cf5..cbbab83f19cc 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -222,8 +222,9 @@ static bool nested_vmcb_check_controls(struct vmcb_control_area *control)
> return true;
> }
>
> -static bool nested_vmcb_checks(struct vmcb *vmcb)
> +static bool nested_vmcb_checks(struct vcpu_svm *svm, struct vmcb *vmcb)
> {
> + bool nested_vmcb_lma;
> if ((vmcb->save.efer & EFER_SVME) == 0)
> return false;
>
> @@ -234,6 +237,27 @@ static bool nested_vmcb_checks(struct vmcb *vmcb)
> if (!kvm_dr6_valid(vmcb->save.dr6) || !kvm_dr7_valid(vmcb->save.dr7))
> return false;
>
> + nested_vmcb_lma =
> + (vmcb->save.efer & EFER_LME) &&
Just curious about using LME instead of LMA. According to APM,
" The processor behaves as a 32-bit x86 processor in all respects
until long mode is activated, even if long mode is enabled. None of the
new 64-bit data sizes, addressing, or system aspects available in long
mode can be used until EFER.LMA=1."
Is it possible that L1 sets LME, but not LMA, in L2's VMCS and this
code will execute even if the processor is not in long-mode ?
> + (vmcb->save.cr0 & X86_CR0_PG);
> +
> + if (!nested_vmcb_lma) {
> + if (vmcb->save.cr4 & X86_CR4_PAE) {
> + if (vmcb->save.cr3 & MSR_CR3_LEGACY_PAE_RESERVED_MASK)
> + return false;
> + } else {
> + if (vmcb->save.cr3 & MSR_CR3_LEGACY_RESERVED_MASK)
> + return false;
> + }
> + } else {
> + if (!(vmcb->save.cr4 & X86_CR4_PAE) ||
> + !(vmcb->save.cr0 & X86_CR0_PE) ||
> + (vmcb->save.cr3 & MSR_CR3_LONG_RESERVED_MASK))
> + return false;
> + }
> + if (kvm_valid_cr4(&(svm->vcpu), vmcb->save.cr4))
> + return false;
> +
> return nested_vmcb_check_controls(&vmcb->control);
> }
>
> which also takes care of other CR0/CR4 checks in the APM.
>
> I'll test this a bit more and queue it. Are you also going to add
> more checks in svm_set_nested_state?
>
> Paolo
>
next prev parent reply other threads:[~2020-07-08 22:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-08 0:39 [PATCH 0/3 v4] KVM: nSVM: Check MBZ bits in CR3 and CR4 on vmrun of nested guests Krish Sadhukhan
2020-07-08 0:39 ` [PATCH 1/3 v4] KVM: x86: Create mask for guest CR4 reserved bits in kvm_update_cpuid() Krish Sadhukhan
2020-07-08 9:48 ` Paolo Bonzini
2020-07-08 0:39 ` [PATCH 2/3 v4] KVM: nSVM: Check that MBZ bits in CR3 and CR4 are not set on vmrun of nested guests Krish Sadhukhan
2020-07-08 10:03 ` Paolo Bonzini
2020-07-08 21:36 ` Krish Sadhukhan
2020-07-08 22:51 ` Krish Sadhukhan [this message]
2020-07-08 23:07 ` Jim Mattson
2020-07-09 9:36 ` Paolo Bonzini
2020-07-08 0:39 ` [PATCH 3/3 v4] kvm-unit-tests: nSVM: Test " Krish Sadhukhan
2020-07-08 11:07 ` Paolo Bonzini
2020-07-09 0:01 ` Krish Sadhukhan
2020-07-11 16:12 ` Nadav Amit
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=ed07cbc2-991f-1f9e-9a4d-ef9b4294b373@oracle.com \
--to=krish.sadhukhan@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.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;
as well as URLs for NNTP newsgroup(s).