Message-ID: <4A4BF1D2.8010305@goop.org>
Date:	Wed, 01 Jul 2009 16:31:30 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
CC:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	xen-devel@...ts.xensource.com, npiggin@...e.de,
	chris.mason@...cle.com, kurt.hackel@...cle.com,
	dave.mccracken@...cle.com, Avi Kivity <avi@...hat.com>,
	Rik van Riel <riel@...hat.com>, alan@...rguk.ukuu.org.uk,
	Rusty Russell <rusty@...tcorp.com.au>,
	Martin Schwidefsky <schwidefsky@...ibm.com>, akpm@...l.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	tmem-devel@....oracle.com, sunil.mushran@...cle.com,
	linux-mm@...ck.org, Himanshu Raj <rhim@...rosoft.com>,
	Keir Fraser <keir.fraser@...citrix.com>
Subject: Re: [RFC] transcendent memory for Linux

On 07/01/09 16:02, Dan Magenheimer wrote:
> 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.
>   

How does Xen distinguish between someone "guessing" uuids and a normal
user which wants to create lots of pools?

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

Revocation is one of the big problems with capabilities-based systems.

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

Well, I think you can define any security model you like, but I think
you need to have a defined security model before making it an available
API.  At the moment the model is defined by whatever you currently have
implemented, and anyone using the API as-is - without special
consideration of its security properties - is going to end up vulnerable.

In an earlier mail I said "a shared namespace of accessible objects is
an entirely new thing in the Xen universe", which is obviously not true:
we have Xenbus.

It seems to me that a better approach to shared tmem pools should be
moderated via Xenbus, which in turn allows dom0/xenstored/tmemd/etc to
apply arbitrary policies to who gets to see what handles, revoke them, etc.

You don't need to deal with "uuids" at the tmem hypercall level. 
Instead, you have a well-defined xenbus path corresponding to the
resource; reading it will return a handle number, which you can then use
with your hypercalls.  If your access is denied or revoked, then the
read will fail (or the current handle will stop working if revoked). 
This requires some privileged hypercalls to establish and remove tmem
handles for a particular domain.

I'm assuming that the job of managing and balancing tmem resources will
need to happen in a tmem-domain rather than trying to build all that
policy into Xen itself, so putting a bit more logic in there to manage
shared access rules doesn't add much complexity to the system.

    J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists