linux-kernel - Re: [RFC] transcendent memory for Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 29 Jun 2009 14:23:38 -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>
Subject: Re: [RFC] transcendent memory for Linux

On 06/29/09 14:13, Dan Magenheimer wrote:
> The uuid is only used for shared pools.  If two different
> "tmem clients" (guests) agree on a 128-bit "shared secret",
> they can share a tmem pool.  For ocfs2, the 128-bit uuid in
> the on-disk superblock is used for this purpose to implement
> shared precache.  (Pages evicted by one cluster node
> can be used by another cluster node that co-resides on
> the same physical system.)
>   

What are the implications of some third party VM guessing the "uuid" of
a shared pool?  Presumably they could view and modify the contents of
the pool.  Is there any security model beyond making UUIDs unguessable?

> The (page)size argument is always fixed (at PAGE_SIZE) for
> any given kernel.  The underlying implementation can
> be capable of supporting multiple pagesizes.
>   

Pavel's other point was that merging the size field into the flags is a
bit unusual/ugly.  But you can workaround that by just defining the
"flag" values for each plausible page size, since there's a pretty small
bound: TMEM_PAGESZ_4K, 8K, etc.

Also, having an "API version number" is a very bad idea.  Such version
numbers are very inflexible and basically don't work (esp if you're
expecting to have multiple independent implementations of this API). 
Much better is to have feature flags; the caller asks for features on
the new pool, and pool creation either succeeds or doesn't (a call to
return the set of supported features is a good compliment).

    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/