linux-kernel - Re: [RFC PATCH 2/2] KUnit: KASAN Integration

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

Date:   Tue, 3 Mar 2020 17:26:37 -0800
From:   Patricia Alfonso <trishalfonso@...gle.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        David Gow <davidgow@...gle.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        LKML <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, kunit-dev@...glegroups.com
Subject: Re: [RFC PATCH 2/2] KUnit: KASAN Integration

On Sat, Feb 29, 2020 at 10:29 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
>
> On Sat, Feb 29, 2020 at 2:23 AM Patricia Alfonso
> <trishalfonso@...gle.com> wrote:
> > >
> > > On Thu, Feb 27, 2020 at 3:44 AM 'Patricia Alfonso' via kasan-dev
> > > <kasan-dev@...glegroups.com> wrote:
> > > >
> > > > --- a/tools/testing/kunit/kunit_kernel.py
> > > > +++ b/tools/testing/kunit/kunit_kernel.py
> > > > @@ -141,7 +141,7 @@ class LinuxSourceTree(object):
> > > >                 return True
> > > >
> > > >         def run_kernel(self, args=[], timeout=None, build_dir=''):
> > > > -               args.extend(['mem=256M'])
> > > > +               args.extend(['mem=256M', 'kasan_multi_shot'])
> > >
> > > This is better done somewhere else (different default value if
> > > KASAN_TEST is enabled or something). Or overridden in the KASAN tests.
> > > Not everybody uses tools/testing/kunit/kunit_kernel.py and this seems
> > > to be a mandatory part now. This means people will always hit this, be
> > > confused, figure out they need to flip the value, and only then be
> > > able to run kunit+kasan.
> > >
> > I agree. Is the best way to do this with "bool multishot =
> > kasan_save_enable_multi_shot();"  and
> > "kasan_restore_multi_shot(multishot);" inside test_kasan.c like what
> > was done in the tests before?
>
> This will fix KASAN tests, but not non-KASAN tests running under KUNIT
> and triggering KASAN reports.
> You set kasan_multi_shot for all KUNIT tests. I am reading this as
> that we don't want to abort on the first test that triggered a KASAN
> report. Or not?

I don't think I understand the question, but let me try to explain my
thinking and see if that resonates with you. We know that the KASAN
tests will require more than one report, and we want that. For most
users, since a KASAN error can cause unexpected kernel behavior for
anything after a KASAN error, it is best for just one unexpected KASAN
error to be the only error printed to the user, unless they specify
kasan-multi-shot. The way I understand it, the way to implement this
is to use  "bool multishot = kasan_save_enable_multi_shot();"  and
"kasan_restore_multi_shot(multishot);" around the KASAN tests so that
kasan-multi-shot is temporarily enabled for the tests we expect
multiple reports. I assume "kasan_restore_multi_shot(multishot);"
restores the value to what the user input was so after the KASAN tests
are finished, if the user did not specify kasan-multi-shot and an
unexpected kasan error is reported, it will print the full report and
only that first one. Is this understanding correct? If you have a
better way of implementing this or a better expected behavior, I
appreciate your thoughts.

-- 
Thanks,
Patricia Alfonso