linux-kernel - RE: [PATCH v5 12/21] kvm: x86: Intercept #NM for saving IA32_XFD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Jan 2022 01:04:01 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Jim Mattson <jmattson@...gle.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>
CC:     "Zhong, Yang" <yang.zhong@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "corbet@....net" <corbet@....net>,
        "shuah@...nel.org" <shuah@...nel.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        "jing2.liu@...ux.intel.com" <jing2.liu@...ux.intel.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Zeng, Guang" <guang.zeng@...el.com>,
        "Wang, Wei W" <wei.w.wang@...el.com>
Subject: RE: [PATCH v5 12/21] kvm: x86: Intercept #NM for saving IA32_XFD_ERR

> From: Jim Mattson <jmattson@...gle.com>
> Sent: Thursday, January 6, 2022 6:31 AM
> 
> On Wed, Jan 5, 2022 at 2:22 PM Sean Christopherson <seanjc@...gle.com>
> wrote:
> >
> > On Wed, Jan 05, 2022, Yang Zhong wrote:
> > > @@ -6399,6 +6424,26 @@ static void handle_interrupt_nmi_irqoff(struct
> kvm_vcpu *vcpu,
> > >       kvm_after_interrupt(vcpu);
> > >  }
> > >
> > > +static void handle_nm_fault_irqoff(struct kvm_vcpu *vcpu)
> > > +{
> > > +     /*
> > > +      * Save xfd_err to guest_fpu before interrupt is enabled, so the
> > > +      * MSR value is not clobbered by the host activity before the guest
> > > +      * has chance to consume it.
> > > +      *
> > > +      * We should not blindly read xfd_err here, since this exception
> >
> > Nit, avoid "we", and explain what KVM does (or doesn't) do, not what KVM
> "should"
> > do, e.g. just say
> >
> >          * Do not blindly read ...
> >
> > > +      * might be caused by L1 interception on a platform which doesn't
> > > +      * support xfd at all.
> > > +      *
> > > +      * Do it conditionally upon guest_fpu::xfd. xfd_err matters
> > > +      * only when xfd contains a non-zero value.
> > > +      *
> > > +      * Queuing exception is done in vmx_handle_exit. See comment there.
> >
> > Another nit, it's worth explaining why XFD_ERR needs to be read here
> regardless
> > of is_guest_mode().  E.g.
> >
> >          * Injecting the #NM back into the guest is handled in the standard path
> >          * as an #NM in L2 may be reflected into L1 as a VM-Exit.  Read
> XFD_ERR
> >          * even if the #NM is from L2, as L1 may have exposed XFD to L2.
> 
> Do we have tests of L1 passing through XFD to L2?

As Sean mentioned passing through XFD to L2 still needs one more change
in nested_vmx_prepare_msr_bitmap(). This will be done in a follow-up patch.

btw we did verify having L1 emulate XFD for L2, by running the amx selftest
in L1. But overall nested configuration will need more test and polish after
this series.

Thanks
Kevin