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-devel

Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkb

To: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
From: Reiner Sailer <sailer@xxxxxxxxxx>
Date: Thu, 27 Jul 2006 13:53:16 -0400
Cc: Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, xense-devel@xxxxxxxxxxxxxxxxxxx, Bryan D Payne <bdpayne@xxxxxxxxxx>, ncmike@xxxxxxxxxx
Delivery-date: Thu, 27 Jul 2006 10:53:46 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1154020758.7906.46.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote on 07/27/2006 01:19:17 PM:

> On Thu, 2006-07-27 at 18:06 +0100, Harry Butterworth wrote:
> > Even with local devices there is no security on the device side of the
> > device driver.  Consider the case of a locally attached sata drive
> > containing 2 partitions, one for each of two domains.  It's not unheard
> > of for disk drives to write the data in the wrong place.  Or read and
> > return the wrong block.  Happens all the time.
>
> And there's all that unaudited code in the motherboard RAID
> implementation.  What's to say that isn't going to shuffle your data
> between partitions?
>


The separation / confinement can happen on the logical level. You must trust the raid software mapping logical volumes into hardware storage devices.

Your argumentation appears to be about "how highly assured can you get". Since using RAID offers some security (redundancy..>), people use it actually to store data they care about. If raid software proves so bad that it messes up the data on its drives that it basically wipes out the redundancy benefit, then one would imagine that it cannot be successful in the market place (looking back at the few economic lessens I enjoyed).

If you go to the end: on what hardware do you implement your trusted proxy? Do you use a highly-assured independent cryptographic coprocessor with tamper response/protection?

There are application environments where one better cares about this assurance level (abolutely!). It seems not (yet?) to be a major application environment for Xen.

What this discussion teaches me is that we must be careful to enable different trust models (and assurance goals) within Xen. Security for military or high-assurance environments will likely look different from security for commercial environments due to the differently motivated trade-offs.


Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>