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

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

> -----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;
> George.Dunlap@xxxxxxxxxxxxx
> 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.

Thanks,
Dongxiao

> 
> --
> Daniel De Graaf
> National Security Agency

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