linux-kernel - Re: Linux Testing Microconference at LPC

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]

Message-ID: <CACT4Y+aj8i0VNad91F-QkHNsXYXUFrYF+j=wnG-USzfQfoD55A@mail.gmail.com>
Date:   Wed, 22 May 2019 17:52:17 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Andrea Parri <andrea.parri@...rulasolutions.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Dhaval Giani <dhaval.giani@...il.com>,
        Sasha Levin <alexander.levin@...rosoft.com>,
        shuah <shuah@...nel.org>, Kevin Hilman <khilman@...libre.com>,
        Tim Bird <tbird20d@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        "Carpenter,Dan" <dan.carpenter@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        gustavo padovan <gustavo.padovan@...labora.co.uk>,
        knut omang <knut.omang@...cle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        "Paul E. McKenney" <paulmck@...ux.ibm.com>,
        Alan Stern <stern@...land.harvard.edu>
Subject: Re: Linux Testing Microconference at LPC

On Sun, May 12, 2019 at 2:40 AM Andrea Parri
<andrea.parri@...rulasolutions.com> wrote:
>
> On Tue, Apr 23, 2019 at 11:22:50AM +0100, Mark Rutland wrote:
> > On Thu, Apr 11, 2019 at 10:37:51AM -0700, Dhaval Giani wrote:
> > > Hi Folks,
> > >
> > > This is a call for participation for the Linux Testing microconference
> > > at LPC this year.
> > >
> > > For those who were at LPC last year, as the closing panel mentioned,
> > > testing is probably the next big push needed to improve quality. From
> > > getting more selftests in, to regression testing to ensure we don't
> > > break realtime as more of PREEMPT_RT comes in, to more stable distros,
> > > we need more testing around the kernel.
> > >
> > > We have talked about different efforts around testing, such as fuzzing
> > > (using syzkaller and trinity), automating fuzzing with syzbot, 0day
> > > testing, test frameworks such as ktests, smatch to find bugs in the
> > > past. We want to push this discussion further this year and are
> > > interested in hearing from you what you want to talk about, and where
> > > kernel testing needs to go next.
> >
> > I'd be interested to discuss what we could do with annotations and
> > compiler instrumentation to make the kernel more amenable to static and
> > dynamic analysis (and to some extent, documenting implicit
> > requirements).
> >
> > One idea that I'd like to explore in the context of RT is to annotate
> > function signatures with their required IRQ/preempt context, such that
> > we could dynamically check whether those requirements were violated
> > (even if it didn't happen to cause a problem at that point in time), and
> > static analysis would be able to find some obviously broken usage. I had
> > some rough ideas of how to do the dynamic part atop/within ftrace. Maybe
> > there are similar problems elsewhere.
> >
> > I know that some clang folk were interested in similar stuff. IIRC Nick
> > Desaulniers was interested in whether clang's thread safety analysis
> > tooling could be applied to the kernel (e.g. based on lockdep
> > annotations).
>
> FWIW, I'd also be interested in discussing these developments.
>
> There have been several activities/projects related to such "tooling"
> (thread safety analysis) recently:  I could point out the (brand new)
> Google Summer of Code "Applying Clang Thread Safety Analyser to Linux
> Kernel" project [1] and (for the "dynamic analysis" side) the efforts
> to revive the Kernel Thread sanitizer [2].  I should also mention the
> efforts to add (support for) "unmarked" accesses and to formalize the
> notion of "data race" in the memory consistency model [3].
>
> So, again, I'd welcome a discussion on these works/ideas.
>
> Thanks,
>   Andrea

I would be interested in discussing all of this too: thread safety
annotations, ktsan, unmarked accesses.