linux-kernel - Re: [PATCH v4] mm, kasan: switch SLUB to stackdepot, enable memory quarantine for SLUB

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 21 Jun 2016 10:18:14 +0200
From:	Alexander Potapenko <glider@...gle.com>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	Andrey Konovalov <adech.fo@...il.com>,
	Christoph Lameter <cl@...ux.com>,
	Dmitriy Vyukov <dvyukov@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Joonsoo Kim <js1304@...il.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Andrey Ryabinin <aryabinin@...tuozzo.com>,
	Kuthonuzo Luruo <kuthonuzo.luruo@....com>,
	kasan-dev <kasan-dev@...glegroups.com>,
	Linux Memory Management List <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] mm, kasan: switch SLUB to stackdepot, enable memory
 quarantine for SLUB

On Mon, Jun 20, 2016 at 9:50 PM, Sasha Levin <sasha.levin@...cle.com> wrote:
> On 06/20/2016 08:53 AM, Alexander Potapenko wrote:
>> On Sun, Jun 19, 2016 at 7:40 PM, Sasha Levin <sasha.levin@...cle.com> wrote:
>>> > On 06/19/2016 03:24 AM, Alexander Potapenko wrote:
>>>> >> Hi Sasha,
>>>> >>
>>>> >> This commit delays the reuse of memory after it has been freed, so
>>>> >> it's intended to help people find more use-after-free errors.
>>> >
>>> > Is there a way to tell if the use-after-free access was to a memory
>>> > that is quarantined?
>>> >
>>>> >> But I'm puzzled why the stacks are missing.
>>> >
>>> > I looked at the logs, it looks like stackdepot ran out of room pretty
>>> > early during boot.
>> This is quite strange, as there's room for ~80k stacks in the depot,
>> and usually the number of unique stacks is lower than 30k.
>> I wonder if this is specific to your config, can you please share it
>> (assuming you're using ToT kernel)?
>> Attached is the patch that you can try out to dump the new stacks
>> after 30k - it's really interesting where do they come from (note the
>> patch is not for submission).
>
> Attached a log file generated with that patch, and my kernel config.
I haven't looked close yet, but your log contains 1455 unique
'DRIVERNAME_driver_init' function names, for which it's quite likely
that 80k allocation stacks are generated.
Can you remove the dump_stack() call from my patch, fuzz for a while
and see to which number does |alloc_cnt| converge on your machine?
Maybe our estimate was just too optimistic, and we need to increase
the memory limit for the stack depot.
>
> Thanks,
> Sasha
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg