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/
Home Products Support Community News


[Xen-devel] Re: [RFC] transcendent memory for Linux

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC] transcendent memory for Linux
From: Pavel Machek <pavel@xxxxxx>
Date: Thu, 2 Jul 2009 08:38:13 +0200
Cc: npiggin@xxxxxxx, akpm@xxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, alan@xxxxxxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dave.mccracken@xxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Himanshu Raj <rhim@xxxxxxxxxxxxx>, sunil.mushran@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, chris.mason@xxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Jul 2009 08:07:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <79a405e4-3c4c-4194-aed4-a3832c6c5d6e@default>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4A4A95D8.6020708@xxxxxxxx> <79a405e4-3c4c-4194-aed4-a3832c6c5d6e@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
> > Yeah, a shared namespace of accessible objects is an entirely 
> > new thing
> > in the Xen universe.  I would also drop Xen support until 
> > there's a good
> > security story about how they can be used.
> While I agree that the security is not bulletproof, I wonder
> if this position might be a bit extreme.  Certainly, the NSA
> should not turn on tmem in a cluster, but that doesn't mean that
> nobody should be allowed to.  I really suspect that there are

This has more problems than "just" security, and yes, security should
be really solved at design time...

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 

Xen-devel mailing list