Re: Some questions about the patching process

[Greg Kroah-Hartman]

On Fri, Aug 28, 2020 at 02:59:25AM -0500, Qiushi Wu wrote:
> 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.

No, you are thinking about this all wrong.

ALL contributors make mistakes, you should not be treating anyone
different from anyone else.  I think I probably have contributed more
bugs than many contributors, does that make me a "malicious"
contributor?  Or just someone who contributes a lot?

So checking on patches needs to be done for everyone, right?

We have an idea of "trust" in kernel development, it's how we work so
well.  I don't trust people not that they will always get things
"correct", but rather that they will be around to fix it when they get
it "wrong", as everyone makes mistakes, we are all human.

So we trust people who we accept pull requests from, we don't review
their contributions because we trust that they did, and again, they will
fix it when it goes wrong.

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

We do both today quite well, why do you think this is not the case?

> > 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?

We use lots, everything we do is in the open, I suggest doing some
research first please.

> Also, can these tools have a
> high coverage rate to test corner cases like error-paths, indirect calls,
> concurrency issues, etc?

Since when does code coverage actually matter as a viable metric?

Look at the tools we use, again, it's all in the open, and tell us what
we could be doing differently by offering to help us implement those
tools into our workflows.  That would be the best way to contribute
here, don't you agree?

thanks,

greg k-h