[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 19 Nov 2011 19:34:10 +0400
From: Cyrill Gorcunov <gorcunov@...il.com>
To: Vasiliy Kulikov <segoon@...nwall.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Pavel Emelyanov <xemul@...allels.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.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 12:10:12PM +0400, Vasiliy Kulikov wrote:
> 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.
> >
First of all, thanks a *huge* for comments Vasiliy! Yes, agreed that plain
single xor is not sufficient here.
> >
> > 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
Yes, dump-start/dump-end is a mininum timeframe.
> > the time even? Can we ensure that during this timeframe no new kernel
> > objects will be created (unrealistic, but would be great)?
> >
We might use PT_SEIZED as such flag and don't allow to allocate new kernel
objects but it will bring too much complexity into kernel code I think,
which is not what we want eventually ;)
> > 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?
>
It's limited to /proc/$pid/
> 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.
>
Yes, this is main concern.
> 2) object creation will be slowed down by hash().
>
This is not that important I think, since it's not a time-critical operation.
> Also, one thought - is it safe to say two kernel objects are the same to
> userspace? :) I don't see anything obviously dangerous, though.
>
Cyrill
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.
