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

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


Xen-devel mailing list