Re: [Xen-devel] [PATCH for-4.10] xen/dom0: Fix latent dom0 construction bugs on all architectures

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Oct 16, 2017 at 03:49:54PM +0100, Andrew Cooper wrote:
> On 16/10/17 15:44, Wei Liu wrote:
> > On Mon, Oct 16, 2017 at 03:38:03PM +0100, Andrew Cooper wrote:
> >>  * x86 PV and ARM dom0's must not clear _VPF_down from v->pause_flags until
> >>    all state is actually set up.  As it currently stands, d0v0 is eligible 
> >> for
> >>    scheduling before its registers have been set.  This is latent as we 
> >> also
> >>    hold a systemcontroller pause reference at the time which prevents d0 
> >> from
> >>    being scheduled.
> >>
> >>  * x86 PVH dom0's must set v->is_initialised on d0v0, to prevent another 
> >> vcpu
> >>    being able to call VCPUOP_initialise and modify state under the feet of 
> >> the
> >>    running vcpu.  This is latent as PVH dom0 construction don't yet 
> >> function.
> >>
> > While I think this patch is a good idea, the above paragraph confuses
> > me: I did boot PVH Dom0 at one point so it did function; I also never
> > triggered a bug like the one described here.
> 
> Strictly speaking, this is the PVH v2 dom0 path, not the legacy PVH dom0
> path.
> 
> The bottom of dom0_construct_pvh() currently has:
> 
> ...
>     panic("Building a PVHv2 Dom0 is not yet supported.");
>     return 0;
> }
> 

Oh yes, I was using a development branch.

> As for the v->is_initialised, a well behaved dom0 wouldn't hit the
> issue, because it wouldn't call VCPUOP_initialise against a running
> vcpu.  Nevertheless, it is relevant to Xen's security that such an
> attempt doesn't get to the point of actually trying to edit the VMC{S,B}
> under a running vcpu.
> 

Right.

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