lkml.org 
[lkml]   [2019]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From
Date
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
>
>
>

\
 
 \ /
  Last update: 2019-09-05 10:04    [W:0.051 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site