[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 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

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.


Xen-devel mailing list



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