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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 07/09/2014 01:28 AM, Xu, Dongxiao wrote:
>> -----Original Message-----
>> From: Daniel De Graaf [mailto:dgdegra@tycho.nsa.gov]
>> Sent: Wednesday, July 09, 2014 5:22 AM
>> To: Xu, Dongxiao; xen-devel@lists.xen.org
>> Cc: keir@xen.org; JBeulich@suse.com; Ian.Jackson@eu.citrix.com;
>> Ian.Campbell@citrix.com; stefano.stabellini@eu.citrix.com;
>> andrew.cooper3@citrix.com; konrad.wilk@oracle.com;
>> George.Dunlap@eu.citrix.com
>> 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@intel.com>
>>
>> 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