linux-kernel - Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about find

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: <20201013073524.GA1674118@kroah.com>
Date:   Tue, 13 Oct 2020 09:35:24 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Alan Stern <stern@...land.harvard.edu>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        linux-kernel@...r.kernel.org, linux-safety@...ts.elisa.tech,
        linux-usb@...r.kernel.org
Subject: Re: [linux-safety] [PATCH] usb: host: ehci-sched: add comment about
 find_tt() not returning error

On Tue, Oct 13, 2020 at 09:16:27AM +0200, Lukas Bulwahn wrote:
> Some others actually believe that the use of static analysis tools 
> increase software quality and ONLY IF a static analysis tool is used, a 
> specific level of software quality is achieved and they want to prove 
> that the software reaches a certain level that way. (I do not 
> understand that argument but some have been repeating it quite often 
> around me. This argument seems to come from a specific interpretation of 
> safety standards that claim to have methods to predict the absense of 
> bugs up to a certain confidence.)

So do those others also audit the static analysis tools to ensure that
they actually work as they "think" they do?  If not, then their
requirement is pretty pointless :)

> I am doing it for the fun and learning about tools, and I am not such a 
> believer but those others would be forced by their beliefs until they 
> understand what static analysis tools and their janitors really already 
> contribute to the kernel development and where the real gaps might be.
> 
> I hope that helps to get a bit of the motivation. Consider us 
> kernel newbies :)

Watch out, sending patches to subsystems to "fix" issues that really
are not real problems is a sure way to get your patches rejected and
make maintainers grumpy.

I recommend starting out with code that we all "know" needs help, in
drivers/staging/ for stuff like this, so you can learn the process
better, as well as start to understand the limitations of your tools
better.

good luck!

greg k-h