netdev - Re: syzcaller patch postings...

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:   Thu, 22 Feb 2018 15:39:49 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Daniel Axtens <dja@...ens.net>
Cc:     Paolo Abeni <pabeni@...hat.com>,
        David Miller <davem@...emloft.net>,
        syzkaller-bugs@...glegroups.com, netdev <netdev@...r.kernel.org>,
        Florian Westphal <fw@...len.de>
Subject: Re: syzcaller patch postings...

On Thu, Feb 22, 2018 at 3:16 PM, Daniel Axtens <dja@...ens.net> wrote:
> Dmitry Vyukov <dvyukov@...gle.com> writes:
>
>> On Thu, Feb 22, 2018 at 2:31 PM, Daniel Axtens <dja@...ens.net> wrote:
>>> Dmitry Vyukov <dvyukov@...gle.com> writes:
>>>
>>>> On Thu, Feb 22, 2018 at 9:26 AM, Paolo Abeni <pabeni@...hat.com> wrote:
>>>>> On Wed, 2018-02-21 at 16:47 -0500, David Miller wrote:
>>>>>> I have to mention this now before it gets out of control.
>>>>>>
>>>>>> I would like to ask that syzkaller stop posting the patch it is
>>>>>> testing when it posts to netdev.
>>>>>
>>>>> There is an open issue on this topic:
>>>>>
>>>>> https://github.com/google/syzkaller/issues/526
>>>>>
>>>>> The current behaviour is that syzbot replies to all get_maintainer.pl
>>>>> recipients after testing a patch, regardless of the test submission
>>>>> recipient list, the idea was instead to respect such list.
>>>>
>>>>
>>>> Hi David, Florian, Paolo,
>>>>
>>>> Didn't realize it triggers patchwork. This wasn't intentional, sorry.
>>>
>>> A little-publicised and incorrectly-documented(!) feature of Patchwork
>>> is that it supports some email headers. In particular, if you include an
>>> "X-Patchwork-Hint: ignore" header, the mail will not be parsed by
>>> Patchwork.
>>>
>>> This will stop it being recorded as a patch. Unfortunately it will also
>>> stop it being recorded as a comment - I don't know if that's an issue in
>>> this case. Maybe we can set you up with Patchwork 2's new checks
>>> infrastructure instead.
>>
>> Nice. But unfortunately the current mailing technology we use allows
>> very limited set of headers and no custom headers:
>> https://cloud.google.com/appengine/docs/standard/go/mail/mail-with-headers-attachments
>> So while possible, it would require very significant rework...
>
> Ah, oh well, nevermind.
>
>> What's the Patchwork 2's new checks infrastructure?
>
> <puts on patchwork maintainer hat>
> It's probably more a long-term thing than an immediate fix, but...
> The checks API is designed to integrate reporting of CI/testing results
> into Patchwork. It allows - through a REST API - an arbitrary process
> (like your checking) to report success/warning/failure against a
> patch. In your case you could report success = patch prevents bug, and
> failure = bug still exists with patch. It's still slightly a
> work-in-progress: at the moment you need an API key from a maintainer to
> post checks. But it does look pretty in the web frontend:
> e.g. https://patchwork.ozlabs.org/patch/871346/ - and the number of
> successful/warning/failed tests shows up on the patch list page.
>
> There's currently only one project (that I know of) out there that uses
> the checks API - Snowpatch: https://github.com/ruscur/snowpatch
>
> If, at any point in the future, you want to explore this, let me know as
> I'd be *very* happy to help with the implementation and if needed push
> features into Patchwork that make it easier/better.
> </hat>

Interesting.

So far syzbot does not test all patches, it only tests by an explicit
developer request (and that patch is not necessary on Patchwork yet,
e.g. it can be just a debugging patch that add more checks and debug
output and it still meant to fail).
But long term we probably would like to test all fixes for syzbot
bugs, so I will keep this in mind.
Is there any kind of push/poll api to get list of patches? Or
otherwise how are external systems are meant to know that there is
something to test?


>> If it will still remain a problem (hopefully not), then maybe it's
>> possible to blacklist syzbot address from creating new patches. syzbot
>> can do a lot, but so far does not also generate fixes for the bugs it
>> discovers :)
>
> In immediate practical terms, that might be the easiest. They all come
> from the same email address, right?

More or less. It would be "syzbot\+[0-9a-f]+@...kaller\.appspotmail\.com".