[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 07/08/2014 10:06 PM, Xu, Dongxiao wrote:
-----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.

In this case, I expect a security-conscious administrator will need to
block access to this hypercall completely.  XSM does make this possible,
but that loses all the benefits of adding this feature.


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

The toolstack domain can only map all guest memory for all guests as
long as the toolstack is not disaggregated.  Even without diaggregation,
it is possible to set up domains whose memory dom0 cannot map: dom0
merely needs to be trusted to set the XSM label after domain creation,
which can be done from an initrd or before accepting logins/commands.

The resource operation has already been identified to be fully
dangerous: modifying SYSENTER_EIP allows a userspace program in domain 0
to run code in hypervisor context.  This bypasses any security features
that the Linux kernel in dom0 may be trying to provide in addition to
those that Xen provides.

--
Daniel De Graaf
National Security Agency

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.