Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
DMARC-Filter: OpenDMARC Filter v1.3.2 mta-p6.oit.umn.edu 4BdBp16jC6z9vCBC
MIME-Version: 1.0
References: <CAMV6ehGKBfXN89XeDzMHKQ_6qLg41R2Tb7=sE+NC7KrbPsigDw@mail.gmail.com>
 <20200827182730.GA712693@kroah.com> <CAMV6ehEwaStF7Xvy-u4p+eU9C1UObCN8eVmuJmVZRFykROdnnw@mail.gmail.com>
 <20200828062042.GF56396@kroah.com>
In-Reply-To: <20200828062042.GF56396@kroah.com>
From:   Qiushi Wu <wu000273@umn.edu>
Date:   Fri, 28 Aug 2020 02:59:25 -0500
Message-ID: <CAMV6ehGwjKit-uOSv1=mRON6Sw6258Xyr8RB3bkLm0-wFymOng@mail.gmail.com>
Subject: Re: Some questions about the patching process
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>,
        "David S. Miller" <davem@davemloft.net>, Kangjie Lu <kjlu@umn.edu>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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