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

Re: [Xen-devel] [PATCH v12 2/9] xsm: add resource operation related xsm policy

On 07/09/2014 01:28 AM, Xu, Dongxiao wrote:
-----Original Message-----
From: Daniel De Graaf [mailto:dgdegra@xxxxxxxxxxxxx]
Sent: Wednesday, July 09, 2014 5:22 AM
To: Xu, Dongxiao; xen-devel@xxxxxxxxxxxxx
Cc: keir@xxxxxxx; JBeulich@xxxxxxxx; Ian.Jackson@xxxxxxxxxxxxx;
Ian.Campbell@xxxxxxxxxx; stefano.stabellini@xxxxxxxxxxxxx;
andrew.cooper3@xxxxxxxxxx; konrad.wilk@xxxxxxxxxx;
Subject: Re: [PATCH v12 2/9] xsm: add resource operation related xsm policy

On 07/04/2014 04:34 AM, Dongxiao Xu wrote:
Add xsm policies for resource access related hypercall, such as MSR
access, port I/O read/write, and other related resource operations.

Signed-off-by: Dongxiao Xu <dongxiao.xu@xxxxxxxxx>

This is correct as far as a permission check, but I think the name
should be changed to reflect the contents of the white-list for the
access: pqos_monitor_op would work for the two MSRs used in #9.

Now the hypercall is a generic resource access mechanism, which covers MSR, 
port I/O, etc.
Therefore I named it as "resource_op"...

If arbitrary access to MSRs is permitted without a white-list or other
categorization in the hypervisor, then the XSM policy needs to be able
to label individual MSRs and allow the security policy author to create
their own white- or black-lists.  This handles the use case you
described at the cost of requiring XSM to be enabled to manage the lists
of MSRs permitted to a toolstack domain.  I do not think this is the
best solution, since it will leave Xen without XSM unprotected, and the
construction of an XSM policy that permits useful features (like CQM)
but denies harmful ones (SYSENTER_EIP) will be more difficult than if
the permissions were explicit (pqos_monitor_op, compromise_hypervisor_op).

We use the xsm policy to limit the execution of this resource_op only in dom0, 
and suppose dom0 and its toolstack is trusted...

One concern to add the white list is that, some customers also need this 
resource access mechanism to dynamically adjust some resource values (MSR) 
without turn off the machine, and if we add white list here, they may not be 
able to achieve it.

These MSRs are documented somewhere prior to the processor's release, I assume.
In that case, they can be added to a whitelist in the hypervisor before it
is possible to start the hypervisor on the new processor, so that any dom0 run
on the new processor has access to the new MSRs.  This type of update should be
suitable for backporting to stable releases, so you won't need to require the
newest hypervisor to take advantage of these features (at least, that's my
impression given Andrew's comments on the other thread).

Daniel De Graaf
National Security Agency

Xen-devel mailing list



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