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

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

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: [Xen-devel] Re: [RFC] transcendent memory for Linux
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 29 Jun 2009 15:15:53 -0700
Cc: npiggin@xxxxxxx, akpm@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>, Pavel Machek <pavel@xxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>, chris.mason@xxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 06 Jul 2009 08:01:50 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a2cac9b3-74c1-4eea-8273-afe2226cef1d@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: <a2cac9b3-74c1-4eea-8273-afe2226cef1d@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2
On 06/29/09 14:57, Dan Magenheimer wrote:
> Interesting question.  But, more than the 128-bit UUID must
> be guessed... a valid 64-bit object id and a valid 32-bit
> page index must also be guessed (though most instances of
> the page index are small numbers so easy to guess).  Once
> 192 bits are guessed though, yes, the pages could be viewed
> and modified.  I suspect there are much more easily targeted
> security holes in most data centers than guessing 192 (or
> even 128) bits.
>   

If its possible to verify the uuid is valid before trying to find a
valid oid+page, then its much easier (since you can concentrate on the
uuid first).  If the uuid is derived from something like the
filesystem's uuid - which wouldn't normally be considered sensitive
information - then its not like its a search of the full 128-bit space. 
And even if it were secret, uuids are not generally 128 randomly chosen
bits.

You also have to consider the case of a domain which was once part of
the ocfs cluster, but now is not - it may still know the uuid, but not
be otherwise allowed to use the cluster.

> Now this only affects shared pools, and shared-precache is still
> experimental and not really part of this patchset.  Does "mount"
> of an accessible disk/filesystem have a better security model?
> Perhaps there are opportunities to leverage that?
>   

Well, a domain is allowed to access any block device you give it access
to.  I'm not sure what the equivalent model for tmem would be.

Anyway, it sounds like you need to think a fair bit more about shared
tmem's security model before it can be considered for use.

> Yes.  Perhaps all the non-flag bits should just be reserved for
> future use.  Today, the implementation just checks for (and implements)
> only zero anyway and nothing is defined anywhere except the 4K
> pagesize at the lowest levels of the (currently xen-only) API.
>   

Yes.  It should fail if it sees any unknown flags set in a guest request.

    J

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