Re: [RFC] transcendent memory for Linux

Jeremy Fitzhardinge
2009-06-30T22:47:02Z

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