linux-kernel - Re: [PATCH 0/4] Checkpoint/Restore: Show in proc IDs of objects that can be shared between tasks

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]

Message-ID: <4EC3736C.2040006@parallels.com>
Date:	Wed, 16 Nov 2011 12:25:16 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Matt Helsley <matthltc@...ibm.com>
CC:	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>,
	Andrew Morton <akpm@...ux-foundation.org>
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
> 
> .
> 

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