This post, and probably a few more posts that will come to be, is being written about a day before it’s actually being posted. The reason for this is that, as I’ll be probably be hospitalised at the end of August, I want to have something going on so I don’t need to write during the hospitalisation.
I was reflecting tonight with Mark (Halcy0n) that for having hardened features on GCC 4.x you shouldn’t, in general, need any particular support in the compiler. What hardened would be doing for the modern compilers is creating new “spec files” that tell the compiler which flags to use by default. This would force the compiler to always generate PIE (Position Independent Executable) code and SSP (Stack Smashing Protection).
In general, to have the same features it would be enough to properly set CFLAGS and CXXFLAGS. The idea is that once you put -fPIE in your flags, all the code that Portage built would be PIE, and if you set -fstack-protector in your CFLAGS (and not CXXFLAGS because SSP is known not to cope properly with C++ code), you expect your system to be built with stack protector turned on.
The problem is, reality and theory don’t seem to coincide. The problem is that a huge lot of ebuilds ignore your flags entirely, others strip them, and might strip -fPIE and -fstack-protector, and quite a few mix CFLAGS and CXXFLAGS, using the former to build C++ code and the latter to build C code. The result is that you end up with something different than what you asked for.
Even worse, there are packages that save your CFLAGS in their -config files, letting your custom flags creep into other projects that might not want them.
So the result is that if we want to make it much easier for everybody to enable hardened, we should be making sure that the behaviour of ebuilds is standardised on the policy of respecting the flags set by the user, not filtering them unless really needed, and even then letting most of the non-optimisation flags through. And to actually use the correct variable depending on the language used.
What are the problems? The first is obviously upstreams that don’t want users to use their own flags for building their code (MPlayer, anyone?), then there is at least the problem of broken build systems that either don’t understand the difference between CFLAGS and CXXFLAGS or don’t support custom flags at all.
If you wish to help, there is an easy way to actually find where the flags are mixed up. As the most obvious problem is CFLAGS used for building C++ code (rather than the other way around), you can add -Wno-pointer-sign to your CFLAGS. When the variable is misused, it turns out this error:
cc1plus: warning: command line option "-Wno-pointer-sign" is valid for C/ObjC but not for C++
When you see that, it’s time to report it against bug #234011 so that the maintainers know they need to fix something in the build system to keep the two variables separated.
As to how to fix this, on custom build systems it’s difficult to say, on autotools-based systems, the problem might be in the configure.ac, if code similar to this is present:
CFLAGS="${CFLAGS} -DSOMETHING"
CXXFLAGS="${CFLAGS} -DSOMETHING"
An alternative is that the build system is adding to _CXXFLAGS the value of a variable reported by one of the foo-config scripts that are bugged and report the flags used to build the source package rather than just the flags needed to get their include directories right. In that case the bug lies in a different package, and is there that it has to be fixed.
Hopefully, this kind of fixes will become routine and new packages won’t be added to the tree if they mix CFLAGS and CXXFLAGS… I can always dream, can’t I?
But yes this is another point of my checklist when creating an ebuild, if the new ebuild is not needed immediately and upstream fails to understand CFLAGS and CXXFLAGS differences, then I avoid adding it at all. I hope other developers will start considering this, too 🙂
Oh yeah I’m sorry I’m actually filing bugs now without providing a fix immediately. The reason why I stopped providing fixes right away is that first of all I’m opening a huge amount of bugs when I find them, rather than waiting to have time to debug and fix them, and I have not enough time for myself to take care of that stuff too, and I’d rather explain how to fix them and then see them fixed by the actual maintainers. And also, I think I have bugs with patches still waiting on maintainers, so…