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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190423102250.GA56999@lakrids.cambridge.arm.com>
Date:   Tue, 23 Apr 2019 11:22:50 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Dhaval Giani <dhaval.giani@...il.com>
Cc:     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>, willy@...radead.org,
        gustavo.padovan@...labora.co.uk,
        Dmitry Vyukov <dvyukov@...gle.com>, knut.omang@...cle.com,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: Linux Testing Microconference at LPC

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).

Thanks,
Mark.