Re: [Xen-devel] [PATCH 10/10] x86/cpuid: Always enable faulting for the control domain

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 14, 2017 at 09:13:08AM -0600, Jan Beulich wrote:
> >>> On 14.03.17 at 16:06, <wei.liu2@xxxxxxxxxx> wrote:
> > On Mon, Mar 13, 2017 at 05:48:44AM -0600, Jan Beulich wrote:
> >> >>> On 10.03.17 at 18:10, <andrew.cooper3@xxxxxxxxxx> wrote:
> >> > On 28/02/17 09:31, Jan Beulich wrote:
> >> >>>>> On 27.02.17 at 16:10, <andrew.cooper3@xxxxxxxxxx> wrote:
> >> >>> On 22/02/17 10:10, Jan Beulich wrote:
> >> >>>>>>> On 22.02.17 at 11:00, <andrew.cooper3@xxxxxxxxxx> wrote:
> >> >>>>> On 22/02/17 09:23, Jan Beulich wrote:
> >> >>>>>>>>> On 20.02.17 at 12:00, <andrew.cooper3@xxxxxxxxxx> wrote:
> >> >>>>>>> The domain builder in libxc no longer depends on leaked CPUID 
> >> >>>>>>> information 
> > to
> >> >>>>>>> properly construct HVM domains.  Remove the control domain 
> >> >>>>>>> exclusion.
> >> >>>>>> Am I missing some intermediate step? As long as there's a raw
> >> >>>>>> CPUID invocation in xc_cpuid_x86.c (which is still there in staging
> >> >>>>>> and I don't recall this series removing it) it at least _feels_ 
> >> >>>>>> unsafe.
> >> >>>>> Strictly speaking, the domain builder part of this was completed 
> >> >>>>> after
> >> >>>>> my xsave adjustments.  All the guest-type-dependent information now
> >> >>>>> comes from non-cpuid sources in libxc, or Xen ignores the toolstack
> >> >>>>> values and recalculates information itself.
> >> >>>>>
> >> >>>>> However, until the Intel leaves were complete, dom0 had a hard time
> >> >>>>> booting with this change as there were no toolstack-provided policy 
> >> >>>>> and
> >> >>>>> no leakage from hardware.
> >> >>>> So what are the CPUID uses in libxc then needed for at this point?
> >> >>>> Could they be removed in a prereq patch to make clear all needed
> >> >>>> information is now being obtained via hypercalls?
> >> >>> I'd prefer to defer that work.  The next chunk of CPUID work is going 
> >> >>> to
> >> >>> be redesigning and reimplementing the hypervisor/libxc interface, and
> >> >>> all cpuid() calls in libxc will fall out there, but its not a trivial
> >> >>> set of changes to make.
> >> >> With that, could you live with deferring the patch here until then?
> >> > 
> >> > We currently have a lot of dom0 implicit dependencies on leaked CPUID
> >> > state into PV dom0.
> >> > 
> >> > With this series, I believe I have identified all leaked dependencies,
> >> > and I really want to prevent is introducing any new implicit dependences
> >> > accidentally.
> >> 
> >> I can certainly understand this, but the state libxc code is in then
> >> makes this a rather implicit thing, instead of being fully explicit. I
> >> think I'd like to have another (tools or REST) maintainer voice a 3rd
> >> opinion. Extending Cc list ...
> > 
> > I'm not sure I follow the implicit vs explicit bit.
> 
> Right now libxc still uses the CPUID instruction, thus implicitly (via
> CPUID faulting / masking) obtaining the intended (filtered) state of
> individual feature flags. The intended explicit way would be for it
> to instead use hypercalls to retrieve the information.
> 

AFAICT having this patch won't make things worse than before, with the
added benefit of avoiding dependencies of leaked information. If my
understanding is correct, I'm slightly in favour of committing it now.

Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel