Open david-a-wheeler opened 1 year ago
Since this document is more about security and memory saftey IDK if it should go too deep into "general code quality" if thats' what a lot of the analyze rules do. If there are plenty of worthwhile security checks in analyze then maybe it is more sensible to recommend maximally enable
Also I didn't realise gcc could output sarif, very interesting
Analyzer options are not suitable for default use even though we try to keep false positives/negatives down, but it would be great to have a section on analyzer (or even sanitizer) options for use in, e.g., CI or debug builds.
Since this document is more about security and memory saftey IDK if it should go too deep into "general code quality" if thats' what a lot of the analyze rules do. If there are plenty of worthwhile security checks in analyze then maybe it is more sensible to recommend maximally enable
There are actually a lot of security-relevant checks in the gcc analyzer like allocation tracking, but they're more heuristics than definite issues. Unfortunately some of the stringop warnings are heuristics too, which muddies the waters a bit.
(GCC analyzer author/maintainer here) Unfortunately there will be false positives (and false negatives) from the analyzer, so I can't recommend enabling it by default. I have a longer post about this that looks into the false positives rates per warning; I hope it will go live in the next week or so; sorry that it's not quite ready yet.
Also I didn't realise gcc could output sarif, very interesting
FWIW there's some more information on GCC's SARIF support here: https://github.com/oasis-tcs/sarif-spec/issues/531 (and I'm now on the SARIF technical committee)
I think whether or not an analyzer should be added should be considered case-by-case, considering how likely it is to identify a vulnerability (benefit) vs. likelihood of a false positive (cost). If it's finding vulnerabilities in many cases, but has occasional false positives that can be suppressed when they happen, that's likely to be worthwhile. At the least, that would make it worth discussion.
Many GCC analyzers are linked to CWE. CWE gives useful technical details about potential security issues. these links to CWE give a first list of GCC analyzers related to vulnerabilities : arbitrary code execution (buffer overflow, use after free, double free, uninitialized buffer, and more), arbitrary memory access (read and write), denial of service and crash.
Here a list of GCC analyzers made based on vulnerabilities described by CWEs from GCC official documentation. GCC - Static Analyzers.pdf
Has this been superseded by the C/C++ Compiler Hardening options guide? @gkunz @thomasnyman @david-a-wheeler
This issue is in relation to the hardening guide. There are a few GCC 13 flags in the doc but IDK if we've covered all new relevant options in 13.1
GCC 13.1 is now out. We should review its analyzer options, e.g.: https://gcc.gnu.org/gcc-13/changes.html I think it'd make sense to maximally enable the analyzers in most cases... but I'm happy to hear alternative views.