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

Re: [Xen-devel][Xense-devel][PATCH][1/4] Xen Security Modules: XSM



I'm interested in whether this code could be used to supersede IS_PRIV (dom), particularly when doing an mmu_update operation.

As far as I can see, the xsm_mmu_normal_update() hook is called after set_foreigndom(). set_foreigndom() will fail if the calling domain is not privileged (!IS_PRIV(current->domain)) and the operation specifies a different domain as the foreigndom.

For disaggregation of the domain builder, we would like to be able to delegate this privilege to a small, trusted domain (domB): it seems to me that XSM would be the cleanest way to do this. Would it therefore be possible to add a hook in set_foreigndom() on the ! IS_PRIV(d) branch, or is there some security consequence that I am overlooking?

Regards,

Derek Murray.

On 7 May 2007, at 22:41, George S. Coker, II wrote:

Updates in this patch set include:
    - adaptation to new create secure interface for domain_create
    - cleanup of xsm enable/disable framework through xsm_call macro
    - ifdef architecture/config specific hooks

Signed-off-by: George Coker <gscoker@xxxxxxxxxxxxxx>
<xsm-050707-xen-15011.diff>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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