linux-kernel - Re: Some questions about the patching process

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: <CAMV6ehGwjKit-uOSv1=mRON6Sw6258Xyr8RB3bkLm0-wFymOng@mail.gmail.com>
Date:   Fri, 28 Aug 2020 02:59:25 -0500
From:   Qiushi Wu <wu000273@....edu>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>, Kangjie Lu <kjlu@....edu>
Subject: Re: Some questions about the patching process

Hi Greg,
Thanks for your response!

> You responded in html format which got rejected by the public list,
> please resend in text-only and I will be glad to reply.
>
Sorry about this!

> > 1. Linux allows anyone to submit a patch because it is an open community.
> >
> And how is 1. a "risk"?

We are assuming the possibility of potential malicious commit contributors
and want to reduce the risk of accepting vulnerable patches from them.

> > We would like to know if maintainers have some methods and tools (such as
> > Smatch, Syzbot?) to mitigate these potential issues. We are happy to
> > discuss these issues and hope our observations could raise some awareness
> > of them.
>
> How do you "raise awareness" among a developer community that is 4000
> people each year (1000 are new each year), consisting of 450+ different
> companies?

Yes, this is a problem. Maybe people can summarize and pubic some security
coding guidelines for different modules of the kernel, or recommend maintainers
to use some bug detection tools to test the patches.

> And yes, we have lots of tools, and run them all the time on all of our
> public trees constantly.  And they fix things before they get merged and
> sent out to the rest of the world.
>
> So what specific things are you wanting to discuss here?

Specifically, we are curious about what kind of tools maintainers are often
used to test potential bugs or vulnerabilities?  Also, can these tools have a
high coverage rate to test corner cases like error-paths, indirect calls,
concurrency issues, etc?

Thanks again for your patience and reply : ),
Best regards,
Qiushi