linux-kernel - Re: [PATCH] kasan: distinguish kasan report from generic BUG()

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 25 Nov 2021 08:15:52 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Marco Elver <elver@...gle.com>
Cc:     Jiri Kosina <jikos@...nel.org>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kasan-dev@...glegroups.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, jslaby@...e.cz
Subject: Re: [PATCH] kasan: distinguish kasan report from generic BUG()

On Wed, 24 Nov 2021 at 19:06, Marco Elver <elver@...gle.com> wrote:
>
> On Wed, 24 Nov 2021 at 18:41, Jiri Kosina <jikos@...nel.org> wrote:
> >
> > From: Jiri Kosina <jkosina@...e.cz>
> >
> > The typical KASAN report always begins with
> >
> >         BUG: KASAN: ....
> >
> > in kernel log. That 'BUG:' prefix creates a false impression that it's an
> > actual BUG() codepath being executed, and as such things like
> > 'panic_on_oops' etc. would work on it as expected; but that's obviously
> > not the case.
> >
> > Switch the order of prefixes to make this distinction clear and avoid
> > confusion.
> >
> > Signed-off-by: Jiri Kosina <jkosina@...e.cz>
>
> I'm afraid writing "KASAN: BUG: " doesn't really tell me this is a
> non-BUG() vs. "BUG: KASAN". Using this ordering ambiguity to try and
> resolve human confusion just adds more confusion.
>
> The bigger problem is a whole bunch of testing tools rely on the
> existing order, which has been like this for years -- changing it now
> just adds unnecessary churn. For example syzkaller, which looks for
> "BUG: <tool>: report".
>
> Changing the order would have to teach all kinds of testing tools to
> look for different strings. The same format is also used by other
> dynamic analysis tools, such as KCSAN, and KFENCE, for the simple
> reason that it's an established format and testing tools don't need to
> be taught new tricks.

Yes, lots of kernel testing systems may be looking just for "BUG:" and
start missing KASAN bugs. Or they may be doing more special things
when they see the current "BUG: KASAN:".

> Granted, there is a subtle inconsistency wrt. panic_on_oops, in that
> the debugging tools do use panic_on_warn instead, since their
> reporting behaviour is more like a WARN. But I'd also not want to
> prefix them with "WARNING" either, since all reports are serious bugs
> and shouldn't be ignored. KASAN has more fine-grained control on when
> to panic, see Documentation/dev-tools/kasan.rst.
>
> If the problem is potentially confusing people, I think the better
> solution is to simply document all kernel error reports and their
> panic-behaviour (and flags affecting panic-behaviour) in a central
> place in Documentation/.
>
> Thanks,
> -- Marco