[Xen-devel] sHype hypervisor security architecture - additional info available

[Ronald Perez <ronpz@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel