WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Security of Xen host and guests?

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Security of Xen host and guests?
From: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Date: Tue, 24 Apr 2007 17:43:53 +0100
Cc: "Petersson, Mats" <Mats.Petersson@xxxxxxx>, Steve Brueckner <steve@xxxxxxxxxxxxxx>
Delivery-date: Tue, 24 Apr 2007 09:44:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <60D45469A1AAD311A04C009027B6BF68061956CE@SERVER20>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <60D45469A1AAD311A04C009027B6BF68061956CE@SERVER20>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.6
> > Each guest is protected from getting to any other guest and it's not
> > possible for example for a guest to access another guests memory or
> > disk-storage [a guest can ALLOW another guest to access it's memory,
> > that's how drivers work, but the guest owning the memory must perform
> > a "grant" operation].
>
> I realize that this is the security policy for Xen, but can we really
> be sure that the hypervisor implementation is provably secure?  I doubt
> that NSA would consider it so.  Just because we haven't seen someone
> "break out" of a guest doesn't mean it's impossible.  That's why there
> is still research going on into secure hypervisors (e.g., shype).
>
> I know this is a little paranoid, but nevertheless.  It posits
> something like a very clever, low-level timing attack on a fundamental
> implementation or design flaw.  Remember the blind spots inherent in
> breaking one's own security.

As with any system, there may be implementation bugs which undermine the 
intended security behaviour.  Bugs of this kind, of varying severity / 
likelihood of compromise will crop up from time to time (I believe I've seen 
a few in the past).

The basic design of the lowlevel interface is believed to be secure...  It 
would be interesting to have some formal verification of this attempted.  
This may happen as people start looking at security certifications for 
Xen-based system.  The other side of this coin is that somebody would need to 
verify the implementation truly matched this formal spec in a bug-free way.

There's lots of stuff to do on the route to more formal security properties 
but people are looking into it.

In the meantime, a system with the appropriate tweaks should be fairly secure, 
with more tested configurations being more so (e.g. the security issue 
regarding the Qemu monitor in HVM domains springs to mind as something that 
took a while to be found and fixed).

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

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

<Prev in Thread] Current Thread [Next in Thread>