Re: [Xen-devel] [PATCH v12 1/9] x86: add generic resource (e.g. MSR) access hypercall

["Xu, Dongxiao" <dongxiao.xu@xxxxxxxxx>]

> -----Original Message-----
> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> Sent: Tuesday, July 08, 2014 5:08 PM
> To: Xu, Dongxiao; Jan Beulich; xen-devel@xxxxxxxxxxxxx
> Cc: keir@xxxxxxx; Ian.Campbell@xxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx;
> stefano.stabellini@xxxxxxxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx;
> dgdegra@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v12 1/9] x86: add generic resource (e.g. MSR)
> access hypercall
> 
> On 08/07/14 08:06, Xu, Dongxiao wrote:
> >> -----Original Message-----
> >> From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> >> Sent: Friday, July 04, 2014 6:53 PM
> >> To: Jan Beulich; Xu, Dongxiao; xen-devel@xxxxxxxxxxxxx
> >> Cc: Ian.Campbell@xxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx;
> >> Ian.Jackson@xxxxxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
> >> konrad.wilk@xxxxxxxxxx; dgdegra@xxxxxxxxxxxxx; keir@xxxxxxx
> >> Subject: Re: [PATCH v12 1/9] x86: add generic resource (e.g. MSR) access
> >> hypercall
> >>
> >> On 04/07/14 11:30, Jan Beulich wrote:
> >>>>>> On 04.07.14 at 11:40, <andrew.cooper3@xxxxxxxxxx> wrote:
> >>>> On 04/07/14 09:34, Dongxiao Xu wrote:
> >>>>> Add a generic resource access hypercall for tool stack or other
> >>>>> components, e.g., accessing MSR, port I/O, etc.
> >>>>>
> >>>>> Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>
> >>>> This still permits a user of the hypercalls to play with EFER or
> >>>> SYSENTER_EIP, which obviously is a very bad thing.
> >>>>
> >>>> There needs to be a whitelist of permitted MSRs which can be accessed.
> >>> Hmm, I'm not sure. One particular purpose I see here is to allow the
> >>> tool stack (or Dom0) access to MSRs Xen may not know about (yet).
> >>> Furthermore, this being a platform op, only the hardware domain
> >>> should ever have access, and it certainly ought to know what it's
> >>> doing. So the sum of these two considerations is: If at all, we may
> >>> want a black list here.
> >>>
> >>> Jan
> >>>
> >> I don't think it is safe for the toolstack to ever be playing with MSRs
> >> which Xen is completely unaware of.  There is no guarentee whatsoever
> >> that a new MSR which Xen is unaware of doesn't have security
> >> implications if the toolstack were to play with it.
> >>
> >> Adding entries to a whitelist is easy and could be considered a
> >> maintenance activity similar to keeping the model/stepping information
> >> up-to-date.
> > This resource access mechanism is useful according to some conversation with
> IPDC customers. Per their description, once the machine and VMs are online,
> they will not be turned off. Sometimes administrators may need to dynamically
> modify some resource values to fix/workaround certain issues, and our patch
> may serve this purpose.
> >
> > Adding the white/black list will bring certain constraints for the above 
> > use case.
> Also considering that the tool stack resides in dom0, I think it is not so 
> dangerous.
> 
> The whole purpose of XSM is to split the toolstack up so it isn't all in
> dom0.

We limited this resource operation in domain 0 through xsm policies.

> 
> Extending a whitelist is trivial, and requires a positive action on
> behalf of someone to decide that the added MSR *is* safe.  Anything else
> is a security bug waiting to happen.

Considering that today's QEMU could even map all guest's memory and it is also 
resides in dom0.
Not sure how dangerous this resource operation is if we didn't add such 
whitelist or blacklist...

Thanks,
Dongxiao

> 
> ~Andrew

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