From: Thomas Gleixner <tglx@linutronix.de>
To: Walter Wu <walter-zh.wu@mediatek.com>,
Andrew Morton <akpm@linux-foundation.org>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>, Marco Elver <elver@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>
Cc: Walter Wu <walter-zh.wu@mediatek.com>,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-mm@kvack.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/6] timer: kasan: record timer stack
Date: Thu, 24 Sep 2020 23:41:27 +0200 [thread overview]
Message-ID: <87h7rm97js.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200924040335.30934-1-walter-zh.wu@mediatek.com>
On Thu, Sep 24 2020 at 12:03, Walter Wu wrote:
> When analyze use-after-free or double-free issue, recording the timer
> stacks is helpful to preserve usage history which potentially gives
> a hint about the affected code.
>
> Record the most recent two timer init calls in KASAN which are printed
> on failure in the KASAN report.
>
> For timers it has turned out to be useful to record the stack trace
> of the timer init call.
In which way? And what kind of bug does it catch which cannot be catched
by existing debug mechanisms already?
> Because if the UAF root cause is in timer init, then user can see
> KASAN report to get where it is registered and find out the root
> cause.
What? If the UAF root cause is in timer init, then registering it after
using it in that very same function is pretty pointless.
> It don't need to enable DEBUG_OBJECTS_TIMERS, but they have a chance
> to find out the root cause.
There is a lot of handwaving how useful this is, but TBH I don't see the
value at all.
DEBUG_OBJECTS_TIMERS does a lot more than crashing on UAF. If KASAN
provides additional value over DEBUG_OBJECTS_TIMERS then spell it out,
but just saying that you don't need to enable DEBUG_OBJECTS_TIMERS is
not making an argument for that change.
Try again please.
Thanks,
tglx
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Walter Wu <walter-zh.wu@mediatek.com>,
Andrew Morton <akpm@linux-foundation.org>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>, Marco Elver <elver@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>
Cc: Walter Wu <walter-zh.wu@mediatek.com>,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com,
linux-mm@kvack.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v4 1/6] timer: kasan: record timer stack
Date: Thu, 24 Sep 2020 23:41:27 +0200 [thread overview]
Message-ID: <87h7rm97js.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200924040335.30934-1-walter-zh.wu@mediatek.com>
On Thu, Sep 24 2020 at 12:03, Walter Wu wrote:
> When analyze use-after-free or double-free issue, recording the timer
> stacks is helpful to preserve usage history which potentially gives
> a hint about the affected code.
>
> Record the most recent two timer init calls in KASAN which are printed
> on failure in the KASAN report.
>
> For timers it has turned out to be useful to record the stack trace
> of the timer init call.
In which way? And what kind of bug does it catch which cannot be catched
by existing debug mechanisms already?
> Because if the UAF root cause is in timer init, then user can see
> KASAN report to get where it is registered and find out the root
> cause.
What? If the UAF root cause is in timer init, then registering it after
using it in that very same function is pretty pointless.
> It don't need to enable DEBUG_OBJECTS_TIMERS, but they have a chance
> to find out the root cause.
There is a lot of handwaving how useful this is, but TBH I don't see the
value at all.
DEBUG_OBJECTS_TIMERS does a lot more than crashing on UAF. If KASAN
provides additional value over DEBUG_OBJECTS_TIMERS then spell it out,
but just saying that you don't need to enable DEBUG_OBJECTS_TIMERS is
not making an argument for that change.
Try again please.
Thanks,
tglx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Walter Wu <walter-zh.wu@mediatek.com>,
Andrew Morton <akpm@linux-foundation.org>,
John Stultz <john.stultz@linaro.org>,
Stephen Boyd <sboyd@kernel.org>, Marco Elver <elver@google.com>,
Andrey Ryabinin <aryabinin@virtuozzo.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@google.com>,
Matthias Brugger <matthias.bgg@gmail.com>
Cc: kasan-dev@googlegroups.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-mediatek@lists.infradead.org,
Walter Wu <walter-zh.wu@mediatek.com>
Subject: Re: [PATCH v4 1/6] timer: kasan: record timer stack
Date: Thu, 24 Sep 2020 23:41:27 +0200 [thread overview]
Message-ID: <87h7rm97js.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200924040335.30934-1-walter-zh.wu@mediatek.com>
On Thu, Sep 24 2020 at 12:03, Walter Wu wrote:
> When analyze use-after-free or double-free issue, recording the timer
> stacks is helpful to preserve usage history which potentially gives
> a hint about the affected code.
>
> Record the most recent two timer init calls in KASAN which are printed
> on failure in the KASAN report.
>
> For timers it has turned out to be useful to record the stack trace
> of the timer init call.
In which way? And what kind of bug does it catch which cannot be catched
by existing debug mechanisms already?
> Because if the UAF root cause is in timer init, then user can see
> KASAN report to get where it is registered and find out the root
> cause.
What? If the UAF root cause is in timer init, then registering it after
using it in that very same function is pretty pointless.
> It don't need to enable DEBUG_OBJECTS_TIMERS, but they have a chance
> to find out the root cause.
There is a lot of handwaving how useful this is, but TBH I don't see the
value at all.
DEBUG_OBJECTS_TIMERS does a lot more than crashing on UAF. If KASAN
provides additional value over DEBUG_OBJECTS_TIMERS then spell it out,
but just saying that you don't need to enable DEBUG_OBJECTS_TIMERS is
not making an argument for that change.
Try again please.
Thanks,
tglx
next prev parent reply other threads:[~2020-09-24 21:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-24 4:03 [PATCH v4 1/6] timer: kasan: record timer stack Walter Wu
2020-09-24 4:03 ` Walter Wu
2020-09-24 4:03 ` Walter Wu
2020-09-24 21:41 ` Thomas Gleixner [this message]
2020-09-24 21:41 ` Thomas Gleixner
2020-09-24 21:41 ` Thomas Gleixner
2020-09-25 7:18 ` Walter Wu
2020-09-25 7:18 ` Walter Wu
2020-09-25 7:18 ` Walter Wu
2020-09-25 8:55 ` Thomas Gleixner
2020-09-25 8:55 ` Thomas Gleixner
2020-09-25 8:55 ` Thomas Gleixner
2020-09-25 9:15 ` Walter Wu
2020-09-25 9:15 ` Walter Wu
2020-09-25 9:15 ` Walter Wu
2020-09-25 22:59 ` Thomas Gleixner
2020-09-25 22:59 ` Thomas Gleixner
2020-09-25 22:59 ` Thomas Gleixner
2020-09-26 17:11 ` Walter Wu
2020-09-26 17:11 ` Walter Wu
2020-09-26 17:11 ` Walter Wu
2020-09-30 7:18 ` Thomas Gleixner
2020-09-30 7:18 ` Thomas Gleixner
2020-09-30 7:18 ` Thomas Gleixner
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=87h7rm97js.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=aryabinin@virtuozzo.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=john.stultz@linaro.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=matthias.bgg@gmail.com \
--cc=sboyd@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.