[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111119081012.GC2675@albatros>
Date: Sat, 19 Nov 2011 12:10:12 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Pavel Emelyanov <xemul@...allels.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Cyrill Gorcunov <gorcunov@...nvz.org>,
Glauber Costa <glommer@...allels.com>,
Andi Kleen <andi@...stfloor.org>, Tejun Heo <tj@...nel.org>,
Matt Helsley <matthltc@...ibm.com>,
Pekka Enberg <penberg@...nel.org>,
Eric Dumazet <eric.dumazet@...il.com>,
kernel-hardening@...ts.openwall.com
Subject: Re: [PATCH v2 0/4] Checkpoint/Restore: Show in proc IDs of objects
that can be shared between tasks
On Sat, Nov 19, 2011 at 11:57 +0400, Vasiliy Kulikov wrote:
> Doing something like hash(cookie1 ++ obj ++ cookie) would leak only the
> equation of two objects, but it can be still dangerous - learn hashes of
> (a) objects created at boot time (their addresses are known) and (b)
> some objects, which allocation scheme is known (i.e. we know
> kmem_cache_alloc() gives us specific addresses with high probability),
> and then compare the hashes against other objects after (a) and (b)
> objects are kfree'd.
>
>
> What is the highest timeframe which must maintain the property of unique
> ids? Is it the whole system lifetime or probably [dump start; dump
> end] and we can change the cookie many times? Can we probably shorten
> the time even? Can we ensure that during this timeframe no new kernel
> objects will be created (unrealistic, but would be great)?
>
> Also, I didn't understand from the quoted text who will use it - only
> the dumper or this interface is exposed to all userspace processes and
> anybody may learn hash(&kern_obj) for any kern_obj he may reference?
Also, if one should have an ability to learn IDs of specific object
types and the set of types is very limited, it's much safer to have one
increasing u64 counter for each created object of one of these types.
The exposed to userspace data will be:
ID = hash(counter ^ cookie)
cookie is generated at boot time, once. counter is a single
variable, one for all exposed kernel object types.
ID will be unpredictable if hash() is cryptographically secure, and
counter is not duplicated. So, for each newly created object the ID is
the new random value, which is unique and says nothing to userspace about
either kernel object addresses or the counter itself.
The cost:
1) counter storing for each kernel object exposed through this interface.
2) object creation will be slowed down by hash().
Also, one thought - is it safe to say two kernel objects are the same to
userspace? :) I don't see anything obviously dangerous, though.
Thanks,
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
