[gentoo-dev] Re: Moving more hardening features to default?

[Duncan]

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