public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <graf@amazon.com>
To: Aaron Lewis <aaronlewis@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Jonathan Corbet <corbet@lwn.net>,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	KarimAllah Raslan <karahmed@amazon.de>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	kvm list <kvm@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 5/7] KVM: x86: VMX: Prevent MSR passthrough when MSR access is denied
Date: Wed, 16 Sep 2020 21:44:03 +0200	[thread overview]
Message-ID: <c90a705d-8768-efd1-e744-b56cd6ab3c0f@amazon.com> (raw)
In-Reply-To: <CAAAPnDH2D6fANhZzy3fAL2XKO4ROrvbOoqPme2Ww6q5XcVJfog@mail.gmail.com>



On 04.09.20 04:18, Aaron Lewis wrote:
> 
>> +/*
>> + * List of MSRs that can be directly passed to the guest.
>> + * In addition to these x2apic and PT MSRs are handled specially.
>> + */
>> +static u32 vmx_possible_passthrough_msrs[MAX_POSSIBLE_PASSGHROUGH_MSRS] = {
> 
> MAX_POSSIBLE_PASSGHROUGH_MSRS should be MAX_POSSIBLE_PASSTHROUGH_MSRS

Ouch. Thanks :).

> 
>> +       MSR_IA32_SPEC_CTRL,
>> +       MSR_IA32_PRED_CMD,
>> +       MSR_IA32_TSC,
>> +       MSR_FS_BASE,
>> +       MSR_GS_BASE,
>> +       MSR_KERNEL_GS_BASE,
>> +       MSR_IA32_SYSENTER_CS,
>> +       MSR_IA32_SYSENTER_ESP,
>> +       MSR_IA32_SYSENTER_EIP,
>> +       MSR_CORE_C1_RES,
>> +       MSR_CORE_C3_RESIDENCY,
>> +       MSR_CORE_C6_RESIDENCY,
>> +       MSR_CORE_C7_RESIDENCY,
>> +};
> 
> Is there any reason not to construct this list on the fly?  That could
> help prevent the list from becoming stale over time if this is missed
> when calls to vmx_disable_intercept_for_msr() are added.

The problem is that we have an upper bound of elements that we can store 
in the bitmap. We can either make that number arbitrary and then have 
really awkward failure modes or be incredibly picky instead.

I went for incredibly picky. If anything goes out of sync, like when 
someone adds an MSR to the list without changing 
MAX_POSSIBLE_PASSTHROUGH_MSRS, a call to 
vmx_{en,dis}able_intercept_for_msr() is done on an MSR that is not part 
of the list, we will abort early and in the former case already through 
the compiler.

If you can think of a good way to construct the list dynamically and 
still have a working bitmap of "desired" passthrough states, I'm all 
ears :).

> 
>> +
>>   /*
>>    * These 2 parameters are used to config the controls for Pause-Loop Exiting:
>>    * ple_gap:    upper bound on the amount of time between two successive
>> @@ -622,6 +642,41 @@ static inline bool report_flexpriority(void)
>>          return flexpriority_enabled;
>>   }
> 
> One thing that seems to be missing is removing MSRs from the
> permission bitmap or resetting the permission bitmap to its original
> state before adding changes on top of it.  This would be needed on
> subsequent calls to kvm_vm_ioctl_set_msr_filter().  When that happens
> the original changes made by KVM_REQ_MSR_FILTER_CHANGED need to be
> backed out before applying the new set.

I'm not sure I follow. Subsequent calls to set_msr_filter() will invoke 
the "please reset the whole MSR passthrough bitmap to a consistent 
state" which will then reapply the in-kvm desired state through the 
bitmap and filter state on top on each of those.


Alex




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



  reply	other threads:[~2020-09-16 19:46 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 12:59 [PATCH v6 0/7] Allow user space to restrict and augment MSR emulation Alexander Graf
2020-09-02 12:59 ` [PATCH v6 1/7] KVM: x86: Deflect unknown MSR accesses to user space Alexander Graf
2020-09-03 19:27   ` Aaron Lewis
2020-09-16  9:31     ` Alexander Graf
2020-09-16 17:08       ` Sean Christopherson
2020-09-16 19:15         ` Alexander Graf
2020-09-17 19:38       ` Aaron Lewis
2020-09-02 12:59 ` [PATCH v6 2/7] KVM: x86: Add infrastructure for MSR filtering Alexander Graf
2020-09-02 12:59 ` [PATCH v6 3/7] KVM: x86: Prepare MSR bitmaps for userspace tracked MSRs Alexander Graf
2020-09-02 12:59 ` [PATCH v6 4/7] KVM: x86: SVM: Prevent MSR passthrough when MSR access is denied Alexander Graf
2020-09-02 12:59 ` [PATCH v6 5/7] KVM: x86: VMX: " Alexander Graf
2020-09-04  2:18   ` Aaron Lewis
2020-09-16 19:44     ` Alexander Graf [this message]
2020-09-16 20:13       ` Aaron Lewis
2020-09-16 20:36         ` Alexander Graf
2020-09-02 12:59 ` [PATCH v6 6/7] KVM: x86: Introduce MSR filtering Alexander Graf
2020-09-02 12:59 ` [PATCH v6 7/7] KVM: selftests: Add test for user space MSR handling Alexander Graf
2020-09-03 19:31   ` Aaron Lewis

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=c90a705d-8768-efd1-e744-b56cd6ab3c0f@amazon.com \
    --to=graf@amazon.com \
    --cc=aaronlewis@google.com \
    --cc=corbet@lwn.net \
    --cc=dan.carpenter@oracle.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.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