From: Vlastimil Babka <vbabka@suse.cz>
To: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Arnd Bergmann <arnd@arndb.de>,
kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, wsd_upstream@mediatek.com
Subject: Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
Date: Thu, 5 Sep 2019 10:03:28 +0200 [thread overview]
Message-ID: <99913463-0e2c-7dab-c1eb-8b9e149b3ee3@suse.cz> (raw)
In-Reply-To: <1567607063.32522.24.camel@mtksdccf07>
On 9/4/19 4:24 PM, Walter Wu wrote:
> On Wed, 2019-09-04 at 16:13 +0200, Vlastimil Babka wrote:
>> On 9/4/19 4:06 PM, Walter Wu wrote:
>>
>> The THP fix is not required for the rest of the series, it was even merged to
>> mainline separately.
>>
>>> And It looks like something is different, because we only need last
>>> stack of page, so it can decrease memory overhead.
>>
>> That would save you depot_stack_handle_t (which is u32) per page. I guess that's
>> nothing compared to KASAN overhead?
>>
> If we can use less memory, we can achieve what we want. Why not?
In my experience to solve some UAFs, it's important to know not only the
freeing stack, but also the allocating stack. Do they make sense together,
or not? In some cases, even longer history of alloc/free would be nice :)
Also by simply recording the free stack in the existing depot handle,
you might confuse existing page_owner file consumers, who won't know
that this is a freeing stack.
All that just doesn't seem to justify saving an u32 per page.
> Thanks.
> Walter
>
>
>
next prev parent reply other threads:[~2019-09-05 8:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-04 6:51 [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator Walter Wu
2019-09-04 12:49 ` Vlastimil Babka
2019-09-04 14:06 ` Walter Wu
2019-09-04 14:13 ` Vlastimil Babka
2019-09-04 14:24 ` Walter Wu
2019-09-05 8:03 ` Vlastimil Babka [this message]
2019-09-06 3:15 ` Walter Wu
2019-09-04 13:44 ` Andrey Konovalov
2019-09-04 14:16 ` Walter Wu
2019-09-04 14:37 ` Qian Cai
2019-09-05 1:54 ` Walter Wu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99913463-0e2c-7dab-c1eb-8b9e149b3ee3@suse.cz \
--to=vbabka@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-mm@kvack.org \
--cc=matthias.bgg@gmail.com \
--cc=schwidefsky@de.ibm.com \
--cc=walter-zh.wu@mediatek.com \
--cc=wsd_upstream@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).