linux-kernel - RE:[PATCH 1/2] mm/kasan: avoid duplicate KASAN issues from reporting

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>] [day] [month] [year] [list]

Date:   Fri, 30 Apr 2021 15:23:50 +0530
From:   Maninder Singh <maninder1.s@...sung.com>
To:     Andrey Konovalov <andreyknvl@...il.com>,
        Marco Elver <elver@...gle.com>
CC:     Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        kasan-dev <kasan-dev@...glegroups.com>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>,
        Vaneet Narang <v.narang@...sung.com>
Subject: RE:[PATCH 1/2] mm/kasan: avoid duplicate KASAN issues from
 reporting

Hi,
 
>
> > On Thu, 22 Apr 2021 at 11:17, Maninder Singh <maninder1.s@...sung.com> wrote:
> > >
> > > when KASAN multishot is ON and some buggy code hits same code path
> > > of KASAN issue repetetively, it can flood logs on console.
> > >
> > > Check for allocaton, free and backtrace path at time of KASAN error,
> > > if these are same then it is duplicate error and avoid these prints
> > > from KASAN.
> >
> > On a more fundamental level, I think this sort of filtering is the
> > wrong solution to your problem. One reason why it's good that
> > multishot is off by default is, because _every_ KASAN report is
> > critical and can destabilize the system. Therefore, any report after
> > the first one might be completely bogus, because the system is in a
> > potentially bad state and its behaviour might be completely random.
 
Yes it's valid point , But in Some scenarios testing in production take time and
waiting for one issue fix takes time as there are multiple stakeholders
in modules. So we thought it was better to catch multiple issues in one long run.
 
 
> > The correct solution is to not leave the system running, fix the first
> > bug found, continue; rinse and repeat. Therefore, this patch adds a
> > lot of code for little benefit.
>  
> I agree with Marco here.
>  
> It doesn't make sense to have this deduplication code in the kernel
> anyway. If you want unique reports, write a userspace script that
> parses dmesg and groups the reports.
>  
 
Yes agree, but issue is when multishot is ON, same KASAN error
reports multiple time and can flood the serial logs.
which can be avoided with patch [1/2]
 
Thanks,
Maninder Singh