Messages in this thread | | | Date | Wed, 16 Nov 2011 12:25:16 +0400 | From | Pavel Emelyanov <> | Subject | Re: [PATCH 0/4] Checkpoint/Restore: Show in proc IDs of objects that can be shared between tasks |
| |
On 11/16/2011 09:44 AM, Matt Helsley wrote: > On Tue, Nov 15, 2011 at 03:35:58PM +0400, Pavel Emelyanov wrote: >> While doing the checkpoint-restore in the userspace one need to determine >> whether various kernel objects (like mm_struct-s of file_struct-s) are shared >> between tasks and restore this state. >> >> The 2nd step can for now be solved by using respective CLONE_XXX flags and >> the unshare syscall, while there's currently no ways for solving the 1st one. >> >> One of the ways for checking whether two tasks share e.g. an mm_struct is to >> provide some mm_struct ID of a task to its proc file. The best from the >> performance point of view ID is the object address in the kernel, but showing >> them to the userspace is not good for performance reasons. > > (I think you meant "not good for security reasons."...) > >> The previous attempt to solve this was to generate an ID for slab/slub and then >> mix it up with the object index on the slab page. This attempt wasn't met >> warmly by slab maintainers, so here's the 2nd approach. >> >> The object address is XOR-ed with a "random" value of the same size and then >> shown in proc. Providing this poison is not leaked into the userspace then >> ID seem to be safe. > > Really? There's no way to quickly derive the random number from known > allocation patterns and thereby break the obfuscation scheme? > To start we can note that the low N bits are directly exposed in the ID > of anything that requires 2^N-byte alignment. > > I think it's really a question of whether the high order bits can be derived. > > And of course the random number only needs to be derived once per boot > before it reveals the address of everything with an ID.
Tejun already proposed to split ID space and use different poisons for them.
> Some wild speculation: > > I bet you could use some cpu affinity, mem policy, slab info, mmap > tricks, etc. to derive more low bits of the random number. You can probably > get even more when you consider objects that don't fit evenly in slabs. > Speaking of slabs, is there some way to use the fact that nearby slab objects > will share their high ID bits?
OK, let's assume we found out that two mm_struct IDs have higher bits equal, what can we do next to split address bits from the poison ones?
> If any of the ID-bearing objects allocated via > kmalloc then inducing memory pressure and/or watching for buddy allocator > merge/splits might reveal more low bits... > > Cheers, > -Matt Helsley > > . >
| |