Ronald Perez
2005-Feb-14 02:59 UTC
[Xen-devel] sHype hypervisor security architecture - additional info available
A few weeks ago, we -- the Secure Systems group at IBM''s TJ Watson Research Center -- communicated our intentions to port our sHype hypervisor security architecture to Xen. We mentioned that we were working on a white paper for the purpose of providing more information about sHype to the Xen community and as a basis for an open discussion on this subject; that paper is now available. Search for research report "RC23511" at the following site: http://www.research.ibm.com/resources/paper_search.shtml Or you can also access it directly via this intuitive URL: http://domino.watson.ibm.com/library/cyberdig.nsf/1e4115aea78b6e7c85256b360066f0d4/265c8e3a6f95ca8d85256fa1005cbf0f?OpenDocument This report discusses the general sHype architecture and a specific implementation of that architecture in an IBM Research hypervisor. The key design and implementation goal of sHype is the security principle of minimizing complexity and the trusted computing base (while retaining configuration options that allow running with security "off"). In that regard, sHype separates security (isolation / resource sharing) policy from enforcement, with the often more dynamic policy portion largely residing in a secure service virtual machine (VM) and lightweight enforcement capabilities residing in the measurably less complex and more trustworthy hypervisor itself whenever possible. Thus, the hypervisor security policy is enforced on a VM granularity from within the hypervisor -- policy can be changed, but the enforcement capabilities can not -- leading to a relatively simple implementation that is more stable and capable of satisfying assurance guarantees than it would be if it were entirely implemented in a privileged VM. The sHype model is well suited to traditional hypervisors / VMMs, with "natural" resource access control points in the hypervisor. However, Xen is currently designed / implemented with these control points residing almost entirely in privileged domains (e.g., dom0) -- minimizing the actual hypervisor layer. We feel that there are drawbacks to this minimalist approach from a security perspective -- chief of which is a large, complex, and fluid trusted computing base that consists of Xen and all such privileged domains (e.g., dom0 is effectively "root"). For these and other reasons, over time we envision key resource access control points migrating into the hypervisor from dom0 today. We encourage those interested to take a look at our sHype research report and to participate with us in a discussion regarding these issues / differences in order to determine how best to proceed with the port of sHype to Xen. We look forward to your comments and to the discussion to follow. -Ron Ronald Perez Manager, Secure Systems Department IBM Thomas J. Watson Research Center, Hawthorne, NY Postscript: This report mainly addresses the first two of six sHype security goals -- isolation between and controlled sharing among VMs. We are also implementing sHype approaches to the other goals -- e.g., addressing VM integrity guarantees as well as VM content attestation based on a trusted computing framework. We believe the remaining goals are also appropriate and achievable in Xen and will similarly discuss them in this venue. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Xen-devel mailing list Xen-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xen-devel