[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 for-4.15] x86/msr: introduce an option for HVM relaxed rdmsr behavior


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 8 Mar 2021 15:30:58 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4d3Dy42PE2eMQRfsKn+OZa7KCKiS9akaynW4wHVieqg=; b=ikY4LwpgbclGAMC1qTfKwYZeYIez4mIqYf/I8hvHTZy8qZNn/pQVdvGE8ZnpEUOg1FNCSIE6KjwNUVOj/IGCFVF/wU305mN8mwerPq8UcFO5xolr2buJR5cwnRR+4qXPEF0AuXDknMzR1TVI+50Y3K/BlL69G85a+Xw07GTQKblbkFoy/J8Zu50jKkUp3MWDkH7W4NXEu5r3O08Ukt4kEjrKO2ozdQoOj0yM6nMObEFFBg83wcNeBnjDwjZ3FmkcsB/xoZ2jYX2Bi3iLSyu+aHCwvIhbQi16KBDpBYw9FxUPnXeffxuMsKGpEHsF+HXBNKQZK5PxqHe3akk5Jgkm6A==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CSYHXPI8ZReX43OqOZJFlSxOUjUg78O9spm9dZId90cv5+M6f63nRDruIrhUVtNwVyVYzWubLEcsGDL/mS+PAKa56vQP6lDXRlHpu8xJu28bWUrf+PBTVZbAD12RXPIkf/I/6t1ng1PIHDxxGz15DxF1+ZlME9hLXx8JUVZkEhGXpAJ+4h9/2PAO54eUFTVpq2zx1Ev9ZU04vkfU9w71IL0/kbAjx0ZRv64YdRzoGsu7ixevZxpbm9cT8BJQSSC452ojOpC0q7lXiJNttyNLxbKbL96utKI2KZkbEH7ZUJHvBQmM+utPq+L56W/CZsJ4OS1ZyShineFzpyxlj+9bSw==
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 08 Mar 2021 14:31:29 +0000
  • Ironport-sdr: PzLq33xz9an6GQUv3BMNSxCw9kcT0W7yXnY/FBvuSKYNdyBiMlguqJqFZnfMuOuSbwNB37tMHf PmIrSGcot4F5imP7TWQ5YmSkWN4INbXYlCipOi9zZO+wkkcwlW4vvxaTYEYhs4Qpy961r9Qa/W 5eM06Mr8aaPd+16YCsWy84LUTG7G2DQSf3a8u02L/S/eS6uA9eu3scaStrlunc3gOuYy+CcNcm owU/g7cYg33aF1FRnEsql/pnGeHepXntEfHvID7Rtu5uEgaz0n1XrDCDX9SUXy4GMeE6FFd8sV Ivc=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Mar 05, 2021 at 11:56:33AM +0100, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/hvm/svm/svm.c
> > +++ b/xen/arch/x86/hvm/svm/svm.c
> > @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr, 
> > uint64_t *msr_content)
> >      const struct domain *d = v->domain;
> >      struct vmcb_struct *vmcb = v->arch.hvm.svm.vmcb;
> >      const struct nestedsvm *nsvm = &vcpu_nestedsvm(v);
> > +    uint64_t tmp;
> >  
> >      switch ( msr )
> >      {
> > @@ -1965,6 +1966,11 @@ static int svm_msr_read_intercept(unsigned int msr, 
> > uint64_t *msr_content)
> >          break;
> >  
> >      default:
> > +        if ( d->arch.hvm.rdmsr_relaxed && !rdmsr_safe(msr, tmp) )
> > +        {
> > +            *msr_content = 0;
> > +            break;
> > +        }
> 
> You don't really need "tmp" here, do you? You could as well read
> into *msr_content, as you're zapping the value afterwards anyway.

I also thought about doing this, but felt unease. I fear the code
might be changed in the future and maybe msr_content is not zapped
anymore, thus leaking the content. I feel it's safer to use a
temporary variable that will never be returned to the guest. Maybe
I'm just too paranoid.

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.