|
xen-devel
[Xen-devel] RE: [RFC] transcendent memory for Linux
|
To: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
|
Subject: |
[Xen-devel] RE: [RFC] transcendent memory for Linux |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Wed, 1 Jul 2009 16:02:38 -0700 (PDT) |
|
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>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, chris.mason@xxxxxxxxxx, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> |
|
Delivery-date: |
Mon, 06 Jul 2009 08:06:07 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<4A4A95D8.6020708@xxxxxxxx> |
|
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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> On 06/30/09 14:21, Dan Magenheimer wrote:
> > No, the uuid can't be verified. Tmem gives no indication
> > as to whether a newly-created pool is already in use (shared)
> > by another guest. So without both the 128-bit uuid and an
> > already-in-use 64-bit object id and 32-bit page index, no data
> > is readable or writable by the attacker.
>
> You have to consider things like timing attacks as well (for
> example, a
> tmem hypercall might return faster if the uuid already exists).
>
> Besides, you can tell whether a uuid exists, by at least a couple of
> mechanisms (from a quick read of the source, so I might have
> overlooked something):
All of these still require a large number of guesses
across a 128-bit space of possible uuids, right?
It should be easy to implement "guess limits" in xen
that disable tmem use by a guest if it fails too many guesses.
I'm a bit more worried about:
> 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.
But on the other hand, the security model here can be that
if a trusted entity becomes untrusted, you have to change
the locks.
> 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
less costly / more rewarding attack vectors at several layers
in the hardware/software stack of most clusters.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
Home