Re: [RFC] transcendent memory for Linux

[Jeremy Fitzhardinge]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/