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] [day] [month] [year] [list]
Message-ID: <MWHPR21MB1593448243F5DC37B0DC15D0D7E39@MWHPR21MB1593.namprd21.prod.outlook.com>
Date:   Wed, 21 Jul 2021 15:07:22 +0000
From:   Michael Kelley <mikelley@...rosoft.com>
To:     Praveen Kumar <kumarpraveen@...ux.microsoft.com>,
        Wei Liu <wei.liu@...nel.org>
CC:     "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Dexuan Cui <decui@...rosoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>, "x86@...nel.org" <x86@...nel.org>,
        "hpa@...or.com" <hpa@...or.com>,
        "viremana@...ux.microsoft.com" <viremana@...ux.microsoft.com>,
        Sunil Muthuswamy <sunilmut@...rosoft.com>,
        "nunodasneves@...ux.microsoft.com" <nunodasneves@...ux.microsoft.com>
Subject: RE: [PATCH] hyperv: root partition faults writing to VP ASSIST MSR
 PAGE

From: Praveen Kumar <kumarpraveen@...ux.microsoft.com> Sent: Wednesday, July 21, 2021 4:32 AM
> 
> On 21-07-2021 15:40, Wei Liu wrote:
> > On Wed, Jul 21, 2021 at 12:42:52PM +0530, Praveen Kumar wrote:
> >> On 21-07-2021 09:40, Michael Kelley wrote:
> >>> From: Wei Liu <wei.liu@...nel.org> Sent: Tuesday, July 20, 2021 9:29 AM
> >>>>
> >>>> On Tue, Jul 20, 2021 at 04:20:44PM +0000, Michael Kelley wrote:
> >>>>> From: Wei Liu <wei.liu@...nel.org> Sent: Tuesday, July 20, 2021 6:35 AM
> >>>>>>
> >>>>>> On Tue, Jul 20, 2021 at 06:55:56PM +0530, Praveen Kumar wrote:
> >>>>>> [...]
> >>>>>>>>
> >>>>>>>>> +	if (hv_root_partition &&
> >>>>>>>>> +	    ms_hyperv.features & HV_MSR_APIC_ACCESS_AVAILABLE) {
> >>>>>>>>
> >>>>>>>> Is HV_MSR_APIC_ACCESS_AVAILABLE a root only flag? Shouldn't non-root
> >>>>>>>> kernel check this too?
> >>>>>>>
> >>>>>>> Yes, you are right. Will update this in v2. thanks.
> >>>>>>
> >>>>>> Please split adding this check to its own patch.
> >>>>>>
> >>>>>> Ideally one patch only does one thing.
> >>>>>>
> >>>>>> Wei.
> >>>>>>
> >>>>>
> >>>>> I was just looking around in the Hyper-V TLFS, and I didn't see
> >>>>> anywhere that the ability to set up a VP Assist page is dependent
> >>>>> on HV_MSR_APIC_ACCESS_AVAILABLE.  Or did I just miss it?
> >>>>
> >>>> The feature bit Praveen used is wrong and should be fixed.
> >>>>
> >>>> Per internal discussion this is gated by the AccessIntrCtrlRegs bit.
> >>>>
> >>>> Wei.
> >>>>
> >>>
> >>> The AccessIntrCtrlRegs bit *is* HV_MSR_APIC_ACCESS_AVAILABLE.
> >>> Both are defined as bit 4 of the Partition Privilege flags.  :-)   I don't
> >>> know why the names don't line up.   Even so, it's not clear to me that
> >>> AccessIntrCtrlRegs has any bearing on the VP Assist page.  I see this
> >>> description of AccessIntrCtrlRegs:
> >>>
> >>
> >> Yup, what I understood as well, this is the one required one for Partition Privilege Flags (4th bit), however, cannot
> comment on the naming convention.
> >>
> >>      5 /* Virtual APIC assist and VP assist page registers available */
> >>      4 #define HV_MSR_APIC_ACCESS_AVAILABLE            BIT(4)
> >>
> >
> > Urgh, okay. It is my fault for not reading the code closely. Sorry for
> > the confusion.
> >
> >>> The partition has access to the synthetic MSRs associated with the
> >>> APIC (HV_X64_MSR_EOI, HV_X64_MSR_ICR and HV_X64_MSR_TPR).
> >>> If this flag is cleared, accesses to these MSRs results in a #GP fault if
> >>> the MSR intercept is not installed.
> >>>
> >>
> >> As per what I also understood from the TLFS doc,that we let partition
> >> access the MSR and do a fault.  However, the point is, does it make
> >> sense to allocate page for vp assist and perform action which is meant
> >> to fail when the flag is cleared ?
> >
> > Like Michael said, there are some other things that are not tied to that
> > particular bit. We should get more clarity on what gates what.  Perhaps
> > that privilege bit only controls access to the EOI assist bit and the
> > other things in the VP assist page are gated by other privilege bits.
> > This basically means we should setup the page when there is at least one
> > thing in that page can be used.
> >
> > This is mostly an orthogonal issue from the one we want to fix. In
> > the interest of making progress we can drop the new check for now and
> > just add a root specific path for setting up and tearing down the VP
> > assist pages.
> >
> > How does that sound?
> >
> 
> Sounds good to me. Thanks Wei.
> 

Work for me as well.  Praveen -- The inconsistency in the name is
historical, and not something that needs to be changed now.  My
comment was just musing, not something actionable. :-)

Michael

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ