Message-ID: <20111228164055.GR27266@moon>
Date:	Wed, 28 Dec 2011 20:40:55 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	linux-kernel@...r.kernel.org,
	Pavel Emelyanov <xemul@...allels.com>,
	Glauber Costa <glommer@...allels.com>,
	Andi Kleen <andi@...stfloor.org>,
	Matt Helsley <matthltc@...ibm.com>,
	Pekka Enberg <penberg@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Vasiliy Kulikov <segoon@...nwall.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [patch 1/4] Add routine for generating an ID for kernel pointer

On Wed, Dec 28, 2011 at 08:26:53AM -0800, Tejun Heo wrote:
> Hello,
> 
> On Wed, Dec 28, 2011 at 08:18:09PM +0400, Cyrill Gorcunov wrote:
> > Hi Tejun, thanks for comment! Yes, XOR is useless here in security meaning,
> > but it simply breaks impression that these generating numbers "mean" somthing
> > (I remained them as Vasily asked).
> 
> But that comes at the cost of creating the impression that the XOR
> does something, which doesn't seem like a good situation.  e.g. Why do
> we need per-domain XOR random keys for then?  That code now doesn't
> mean anything.
> 

Strictly speaking, yes, we don't need per-domain keys, one would be enough,
I left them here just to add some more entropy in IDs. And comment in code
and in proc.txt mention pretty clearly (I hope) that one should interpret
the IDs as a string of bytes rather than a number to be on a safe side since
one day the generating algorithm might be changed (I dont think there will be
a need, but still better to warn users and give them a safe way).

> > I personally fine to simply leave plain pointers here and root-only access
> > since that is enough for us (and our tool will require root privileges
> > anyway :)
> > 
> > OTOH, we could add some sha2 here with pointer+cookie as an initial value but I fear
> > this will bring more code comlexity and computing sha2 hash is not that
> > fast operation, which should be taken into account (note on x86-32 since
> > pointers are 32bit values one could compute prehash for all space covered
> > and if an attacker will know somehow cookie value the hash will be easily
> > broken, not sure if it's really usefull for someone, since if you have root
> > access to the machine such IDs will be the last thing attacker should be
> > interested in :)
> 
> We have the whole crypto subsystem dealing with this.  It sure would
> be more complex than ^ operator but it's not like you have to open
> code the whole thing.  Is it really that complex to use?

No, Tejun, the use of crypto engine is not hard but it means more memory
consumption (one need to carry resulting hashes and print them out into
/proc) and more cpu consuption while we really need some fast and cheap
solution. Unlike other usage of crypto engine (such as encoding for net
layer, iirc ipsec uses it) I'm not really convinced we should use that
heavy artillery here ;)

> 
> > And it seems noone except us need this interface yet, so maybe sticking with
> > "pointer exported under root-only" would be enough?
> 
> Maybe, dunno.  But even if it's gonna be raw pointer or XOR'd value
> for now, I would suggest exporting it in the form which can be
> replaced by proper hash in the future.  ie. Don't let userland assume
> it's 32bit or 64bit value.
> 

I see, I could use some other form of output, it's not a problem. The main
problem which interface community prefer, should I really switch to crypto
usage or we can leave with root-only+plain-pointer approach?

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