Mike Frysinger posted on Thu, 20 Oct 2011 08:55:35 -0400 as excerpted: > On Thursday 20 October 2011 04:47:14 Paweł Hajdan, Jr. wrote:
>> <http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags> >> Debian is starting to make more and more hardening features default > random thoughts: > - we've long defaulted to linking with relro > - defaulting to bindnow is pretty much a no go for USE=-hardened > - PIC/PIE comes with performance penalty for (e.g. x86), > and is often the source of build issues with the hardened port > - we've long defaulted to building with _FORTIFY_SOURCE Thanks on relro and fortify_source. Magnus G suggests possibly adding PIE to amd64, which is already PIC, with the big issue there being the packages doing assembly where the upstreams aren't interested in PIC compliance so Gentoo has to maintain the patches. He says ~30 packages. Obviously hardened already has quite some experience here, and making PIE the amd64 default would certainly broaden the base and should thus make it easier than just hardened caring now, but at a bit more trouble for mainline ~amd64, I'd imagine. Still, speaking as an ~amd64 user myself, that's certainly an acceptable tradeoff from the user-side, particularly as most users will only have perhaps a handful of those 30 packages installed. If the gentoo/amd64 folks and the maintainers of those 30 packages don't mind too much, I believe it does make sense. Then, as legacy x86 gradually dies off and those who haven't already done so gradually switch to amd64 (or possibly arm, but I don't know enough about that to comment in this context), they'd get the security upgrade as a part of the package. =:^) What about x32, tho? Does it get PIC by default too, or not, and if not, given that it's a new arch, would enabling both PIC and PIE and taking whatever hit it brings with it be acceptable? What /are/ the costs there, more like x86 or amd64? And for bindnow, do you mean the "-Wl,-z,now" that's part of my LDFLAGS? If so, I've been running it for years on amd64 at least, no hardened here. And for less time but similarly system-wide, I'm running it on my early 32-bit-atom-based netbook (acer aspire one, AOA150L). AFAIK there's some initial-load-time and arguably some memory cost, but less post-load run-time latency and issues when those libs would be otherwise be lazy-loaded, and I decided that tradeoff was one I could live with! =:^) Years ago there were some issues with the xf86-video-ati driver due to circular load-time dependency issues so I had to disable it for that package (and possibly for a couple other X-related packages) for awhile, but any remaining issues in the packages I run, at least, have been long dealt with in the ebuilds using stripflags or whatever, and I've not had any LDFLAG changes in my /etc/portage/env/*/* files for quite some time. So while Frysinger's certainly the expert that I'm not, and assuming we're talking about the same thing, at least on my kde-based systems both amd64 and x86, my bindnow experience has actually been remarkably smooth, /way/ more so than say... CFLAGS containing -combine (as mine do), for which I've rather a number of /etc/portage/env/*/* entries. So from my experience, bindnow would be a go as well. But I've always been interested in why it might not be the default I thought it seemed it should be, so if Mike or anyone else can point me at something suggesting other than initial-load latency and quite rare circular load issues (or for that matter, much else on that flag, since I frankly don't know as much about it as I'd like), I'd love to read up! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
