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

[Jürgen Groß <jgross@xxxxxxxx>]

On 07/08/2014 11:07 AM, Andrew Cooper wrote:
> 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.
>
> 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.
Why not adding a whitelist which is tested as default and make the test
switchable via a boot parameter?

Juergen


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