[Tmem-devel] [RFC] transcendent memory for Linux

[Jeremy Fitzhardinge]

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):

   1. You can create new shared pools until it starts failing as a
      result of hitting the MAX_GLOBAL_SHARED_POOLS limit with junk
      uuids.  If you then successfully "create" a shared pool while
      searching, you know it already existed.
   2. The returned pool id will increase unless the pool already exists,
      in which case you'll get a smaller id back (ignoring wraparound).


> Hmmm... that is definitely a thornier problem.  I guess the
> security angle definitely deserves more design.  But, again,
> this affects only shared precache which is not intended
> to part of the proposed initial tmem patchset, so this is a futures
> issue.)

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.

    J