From: Walter Wu <walter-zh.wu@mediatek.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Qian Cai <cai@lca.pw>, wsd_upstream <wsd_upstream@mediatek.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Linux-MM <linux-mm@kvack.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Josh Triplett <josh@joshtriplett.org>,
kasan-dev <kasan-dev@googlegroups.com>,
LKML <linux-kernel@vger.kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
linux-mediatek@lists.infradead.org,
Alexander Potapenko <glider@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH 0/3] kasan: memorize and print call_rcu stack
Date: Wed, 6 May 2020 20:01:50 +0800 [thread overview]
Message-ID: <1588766510.23664.31.camel@mtksdccf07> (raw)
In-Reply-To: <CACT4Y+atTS6p4b23AH+G9LM-k2gU=kMdkKQdARSboxc-H8CLTQ@mail.gmail.com>
On Wed, 2020-05-06 at 11:37 +0200, 'Dmitry Vyukov' via kasan-dev wrote:
> On Wed, May 6, 2020 at 8:23 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > This patchset improves KASAN reports by making them to have
> > > > call_rcu() call stack information. It is helpful for programmers
> > > > to solve use-after-free or double-free memory issue.
> > > >
> > > > The KASAN report was as follows(cleaned up slightly):
> > > >
> > > > BUG: KASAN: use-after-free in kasan_rcu_reclaim+0x58/0x60
> > > >
> > > > Freed by task 0:
> > > > save_stack+0x24/0x50
> > > > __kasan_slab_free+0x110/0x178
> > > > kasan_slab_free+0x10/0x18
> > > > kfree+0x98/0x270
> > > > kasan_rcu_reclaim+0x1c/0x60
> > > > rcu_core+0x8b4/0x10f8
> > > > rcu_core_si+0xc/0x18
> > > > efi_header_end+0x238/0xa6c
> > > >
> > > > First call_rcu() call stack:
> > > > save_stack+0x24/0x50
> > > > kasan_record_callrcu+0xc8/0xd8
> > > > call_rcu+0x190/0x580
> > > > kasan_rcu_uaf+0x1d8/0x278
> > > >
> > > > Last call_rcu() call stack:
> > > > (stack is not available)
> > > >
> > > >
> > > > Add new CONFIG option to record first and last call_rcu() call stack
> > > > and KASAN report prints two call_rcu() call stack.
> > > >
> > > > This option doesn't increase the cost of memory consumption. It is
> > > > only suitable for generic KASAN.
> > >
> > > I don’t understand why this needs to be a Kconfig option at all. If call_rcu() stacks are useful in general, then just always gather those information. How do developers judge if they need to select this option or not?
> >
> > Because we don't want to increase slub meta-data size, so enabling this
> > option can print call_rcu() stacks, but the in-use slub object doesn't
> > print free stack. So if have out-of-bound issue, then it will not print
> > free stack. It is a trade-off, see [1].
> >
> > [1] https://bugzilla.kernel.org/show_bug.cgi?id=198437
>
> Hi Walter,
>
> Great you are tackling this!
>
> I have the same general sentiment as Qian. I would enable this
> unconditionally because:
>
> 1. We still can't get both rcu stack and free stack. I would assume
> most kernel testing systems need to enable this (we definitely enable
> on syzbot). This means we do not have free stack for allocation
> objects in any reports coming from testing systems. Which greatly
> diminishes the value of the other mode.
>
> 2. Kernel is undertested. Introducing any additional configuration
> options is a problem in such context. Chances are that some of the
> modes are not working or will break in future.
>
> 3. That free stack actually causes lots of confusion and I never found
> it useful:
> https://bugzilla.kernel.org/show_bug.cgi?id=198425
> If it's a very delayed UAF, either one may get another report for the
> same bug with not so delayed UAF, or if it's way too delayed, then the
> previous free stack is wrong as well.
>
> 4. Most users don't care that much about debugging tools to learn
> every bit of every debugging tool and spend time fine-tuning it for
> their context. Most KASAN users won't even be aware of this choice,
> and they will just use whatever is the default.
>
> 5. Each configuration option increases implementation complexity.
>
> What would have value is if we figure out how to make both of them
> work at the same time without increasing memory consumption. But I
> don't see any way to do this.
>
> I propose to make this the only mode. I am sure lots of users will
> find this additional stack useful, whereas the free stack is even
> frequently confusing.
>
Ok.
If we want to have a default enabling it, but it should only work in
generic KASAN, because we need to get object status(allocation or
freeing) from shadow memory, tag-based KASAN can't do it. So we should
have a default enabling it in generic KASAN?
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
next prev parent reply other threads:[~2020-05-06 12:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-06 5:18 [PATCH 0/3] kasan: memorize and print call_rcu stack Walter Wu
2020-05-06 5:53 ` Qian Cai
2020-05-06 6:23 ` Walter Wu
2020-05-06 9:37 ` Dmitry Vyukov
2020-05-06 12:01 ` Walter Wu [this message]
2020-05-06 12:16 ` Dmitry Vyukov
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=1588766510.23664.31.camel@mtksdccf07 \
--to=walter-zh.wu@mediatek.com \
--cc=akpm@linux-foundation.org \
--cc=aryabinin@virtuozzo.com \
--cc=cai@lca.pw \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--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=mathieu.desnoyers@efficios.com \
--cc=matthias.bgg@gmail.com \
--cc=paulmck@kernel.org \
--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).