Getting the maximum of your C compiler, for security
airbus-seclab.github.io
Getting the maximum of your C compiler, for security
1–10 of 10 posts
Re: Getting the maximum of your C compiler, for security
#2Nice summarization.
Be even nicer if it had a link or two for each option stated.
Re: Getting the maximum of your C compiler, for security
#3IIRC fanalyzer is a fairly recent addition to gcc. Has it become reasonably usable yet?
I recall getting a bit excited when I first read about it, but the results I got where a bit bizarre (e.g. every single function that allocated memory and returned a pointer to it was labeled as leaking memory; not really any useful info).
I did the fun exercise myself once to riffle through the gcc manpage, cobble together warning flags and massage them into autoconf[1][2].
There is a very handy m4 script in the util-linux source for testing supported warning flags[3].
[1] https://git.infradead.org/mtd-utils.git/blob/HEAD:/configure...
[2] https://github.com/AgentD/squashfs-tools-ng/blob/master/conf...
[3] https://github.com/karelzak/util-linux/blob/master/m4/compil...
Re: Getting the maximum of your C compiler, for security
#4IIRC fanalyzer is a fairly recent addition to gcc. Has it become reasonably usable yet? I recall getting a bit excited when I first read about it, but the results I got where a bit bizarre (e.g. every single function that allocated memory and returned a pointer to it was labeled as leaking memory; not really any useful info). I did the fun exercise myself once to riffle through the gcc manpage, cobble together warnin…
There's also 'AX_APPEND_COMPILE_FLAGS' [1] (and its dependency 'AX_CHECK_COMPILE_FLAG' [2]), next to many other (related or unrelated) macros in the autoconf archive.
[1] https://www.gnu.org/software/autoconf-archive/ax_append_comp...
[2] https://www.gnu.org/software/autoconf-archive/ax_check_compi...
Re: Getting the maximum of your C compiler, for security
#5-Wl,-z,relro seems to happen by itself with my local gcc and clang. Is that a distro customization?
Re: Getting the maximum of your C compiler, for security
#6IIRC fanalyzer is a fairly recent addition to gcc. Has it become reasonably usable yet? I recall getting a bit excited when I first read about it, but the results I got where a bit bizarre (e.g. every single function that allocated memory and returned a pointer to it was labeled as leaking memory; not really any useful info). I did the fun exercise myself once to riffle through the gcc manpage, cobble together warnin…
clang has a static analyzer feature that IMO gives pretty good results. There's also a mode that's handy for long functions/funcs w/heavily nested blocks where it can show you the execution path necessary to hit a case (like used-uninitialized, e.g.).
Re: Getting the maximum of your C compiler, for security
#7Great suggestions! One caveat: -fsanitize=pointer-compare and -fsanitize=pointer-subtract have some sharp edges and (last I knew) are not considered production ready by the sanitizers team. For example: https://github.com/google/sanitizers/issues/1324
Re: Getting the maximum of your C compiler, for security
#8IIRC fanalyzer is a fairly recent addition to gcc. Has it become reasonably usable yet? I recall getting a bit excited when I first read about it, but the results I got where a bit bizarre (e.g. every single function that allocated memory and returned a pointer to it was labeled as leaking memory; not really any useful info). I did the fun exercise myself once to riffle through the gcc manpage, cobble together warnin…
I've filed loads of bugs against GCC -fanalyzer and most have been fixed so it's getting better. Most recent fix happened yesterday: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99260
However I do find the output to be very verbose.
Re: Getting the maximum of your C compiler, for security
#9If you ship a public project and do not have fixed toolchain versions, remember to only use -Werror for CI and debug builds: you do not want people building your project to fail with an error at first try.
Re: Getting the maximum of your C compiler, for security
#10If you ship a public project and do not have fixed toolchain versions, remember to only use -Werror for CI and debug builds: you do not want people building your project to fail with an error at first try.
I know this is a thing, and I've been frustrated by this in the past. But I think it's a little more nuanced than "don't use -Werror in distribution". Warnings are warnings for a reason, and sometimes that reason is "this could be a security/data corruption problem, but we can't be sure enough to make it an error". Maybe it's better that code can't be compiled in that case. I mean, the reason -Werror is annoying is that it's very hard to ignore. Maybe the best case scenario is for a builder to point out the failure to the maintainer, or maybe the worst case scenario is everyone down the chain ignores the warnings from a lack of -Werror and bad things happen.