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

["John McDermott (U.S. Navy Employee)" <mcdermott@itd.nrl.navy.mil>]

Reiner Sailer wrote:

> <snip>
> XSM would effectively replace the small set of hooks that the 
> sHype/ACM module introduced with a more generic mediation framework. 
> sHype would use the XSM hook framework to control the same operations 
> that it controls now. The way users interact with sHype(XSM) (tools, 
> policies, labeling, ...) would not be affected by XSM. Instead of 
> being both hooks and security module, sHype(XSM) would be a security 
> module and XSM would offer the hooks.
>
> Ideally, XSM would be a standardized and generic Xen interface that 
> offers the possibility for researchers to easily experiment with 
> proprietary security modules. At the same time, it must have very low 
> performance overhead and be effective to support enterprise security 
> on highly utilized platforms.
>
> It is very good for starting the discussions that George and team 
> succeeded to submit their code before the Xen Summit. Thank you!


The XSM concept looks good for prototyping and research but any 
security-related additions to Xen should be done in a way that does not 
increase the _minimum_ size of the code base. A small code base is 
essential for high assurance; having the  flexibility of XSM is good but 
it should be possible to build a Xen with something smaller than XSM. If 
XSM or other security enhancements become too deeply associated with the 
core of Xen then we loose the chance to build high-assurance Xen-based 
products.

This is really an issue about what kind of security the hypervisor 
should enforce and what should be enforced by trusted or untrusted (wrt 
the hypervisor) mechanisms outside the hypervisor.


Sincerely,

John

-- 
J.P. McDermott			building 12
Code 5542			mcdermott@itd.nrl.navy.mil
Naval Research Laboratory	voice: +1 202.404.8301
Washington, DC 20375, USA	fax:   +1 202.404.7942