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

[Francisco Blas Izquierdo Riera (klondike)]

El 23/10/11 05:56, Steven J Long escribió:
> Will we be able to switch off SSP via config, or will we have to setup our 
> own profile?
This should do the trick:
CFLAGS=$CFLAGS -fno-stack-protector



signature.asc
Description: OpenPGP digital signature

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

[Paweł Hajdan, Jr.]

On 10/23/11 5:56 AM, Steven J Long wrote:
> Will we be able to switch off SSP via config, or will we have to setup our 
> own profile?

In my proposal the SSP would be off by default on non-hardened profiles,
at least initially. At any time I'd like it to be switchable via
gcc-config, as it currently is on hardened.



signature.asc
Description: OpenPGP digital signature

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

[Steven J Long]

Magnus Granberg wrote:

> It's hard to keep the patches up to date when they
> are not maintained upstream.
> 
> There are about 30 packages which have problems with PIE.  We either add
> patch to these or else use filter-flags on them.

Sounds perfectly reasonable just to filter those, and not give yourself the
maintenance burden.

Will we be able to switch off SSP via config, or will we have to setup our 
own profile?

(Since PIE has minimal performance burden on AMD64, and won't be default
elsewhere it doesn't seem like a concern.)
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

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

[Magnus Granberg]

fredag 21 oktober 2011 15.25.54 skrev  Duncan:
> Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:
> > On Thursday 20 October 2011 23:20:35 Duncan wrote:
> >> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
> > 
> > this isn't quite right.  amd64 shared objects (i.e. libraries) are PIC.
> > the applications are not.
> 
> Thanks for the correction.  I knew the library think but supposed that
> was the difference between PIC/PIE, the E/executable for executables
> only, the more generic C/code for the feature applied to shared objects.
> 
> Seems there's a bit more to it than that.  Thanks again, I can look it up
> now that I know to do so.
> 
> > usually these packages are multimedia related.  like ffmpeg iirc.  so i
> > think the impact is much greater than your estimate here.
>
I don't have any probs with ffmpeg. We disable the asm stuff only for x86 and
not amd64 and that is the case on alot of the multimedia related packages.
Most problem we have now is the packages in app-emulation

> I figured mm, but also assumed strip-flags-like exceptions (probably
> controlled via USE flag) for packages where the default was really
> costly.  But now that I think of it, implementing that as arch defaults
> while allowing overrides isn't quite the simple matter it is for user-set
> CFLAGS, etc, and strip-flags, etc.
We allready use pic USE flag, filter-flags -fPIE or gcc-specs-pie to disable 
or do stuff so the package works.

> 
> I assume it can still be done, but am not in a position to estimate
> whether it'd be worth the cost to implement.
> 
> >> What about x32, tho?  Does it get PIC by default too
> > 
> > x32 is same as x86_64 wrt PIC
> 
> Good to know.  Thanks.

/Magnus

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

[Duncan]

Mike Frysinger posted on Fri, 21 Oct 2011 08:13:22 -0400 as excerpted:

> On Thursday 20 October 2011 23:20:35 Duncan wrote:
>> Magnus G suggests possibly adding PIE to amd64, which is already PIC,
> 
> this isn't quite right.  amd64 shared objects (i.e. libraries) are PIC. 
> the applications are not.

Thanks for the correction.  I knew the library think but supposed that 
was the difference between PIC/PIE, the E/executable for executables 
only, the more generic C/code for the feature applied to shared objects.

Seems there's a bit more to it than that.  Thanks again, I can look it up 
now that I know to do so.

> usually these packages are multimedia related.  like ffmpeg iirc.  so i
> think the impact is much greater than your estimate here.

I figured mm, but also assumed strip-flags-like exceptions (probably 
controlled via USE flag) for packages where the default was really 
costly.  But now that I think of it, implementing that as arch defaults 
while allowing overrides isn't quite the simple matter it is for user-set 
CFLAGS, etc, and strip-flags, etc.

I assume it can still be done, but am not in a position to estimate 
whether it'd be worth the cost to implement.

>> What about x32, tho?  Does it get PIC by default too
> 
> x32 is same as x86_64 wrt PIC

Good to know.  Thanks.

-- 
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

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

[Mike Frysinger]

On Thursday 20 October 2011 23:20:35 Duncan wrote:
> Magnus G suggests possibly adding PIE to amd64, which is already PIC,

this isn't quite right.  amd64 shared objects (i.e. libraries) are PIC.  the 
applications are not.

> 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.

usually these packages are multimedia related.  like ffmpeg iirc.  so i think 
the impact is much greater than your estimate here.

> 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. =:^)

poor PIC performance isn't specific to x86.  it's just the largest affected 
user 
base.  i'd have to dig into the ABI's to say which others have issues.

> What about x32, tho?  Does it get PIC by default too, or not, and if not,

x32 is same as x86_64 wrt PIC

> And for bindnow, do you mean the "-Wl,-z,now" that's part of my LDFLAGS?

yes

> 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!

i don't think there's a memory cost.  the initial load time is waste and is 
noticeable on much larger packages like OOo.
-mike


signature.asc
Description: This is a digitally signed message part.

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

[Ryan Hill]

On Thu, 20 Oct 2011 06:40:43 -0400
"Anthony G. Basile"  wrote:

> USE=hardened refers to only toolchain hardening.  The problems there are
> mostly packages which break with PIE because they (ab)use assembly. 
> Things like virtualbox and some codecs.  This can become a thorny mess.
> 
> It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> and ssp into mainstream though.  Packages which break because of either
> of those two features are broken and should be fixed anyhow.

If any of these features (other than -D_FORTIFY_SOURCE) relies on spec rule
handling of preprocessor flags then I'd like you to try reimplementing them
another way. I'm going to hack 4.6 to work properly but I expect it to break
again with 4.7.


-- 
fonts, gcc-porting,  it makes no sense how it makes no sense
toolchain, wxwidgets   but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

[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:

>> 
>> 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

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

[Mike Frysinger]

On Thursday 20 October 2011 07:46:57 Diego Elio Pettenò wrote:
> Il giorno gio, 20/10/2011 alle 06.40 -0400, Anthony G. Basile ha scritto:
> > It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> > and ssp into mainstream though.  Packages which break because of
> > either
> > of those two features are broken and should be fixed anyhow.
> 
> -D_FORTIFY_SOURCES=2 has been enabled in mainline since GCC 4.3.3-r1 if
> my memory serves me right.

it isn't in mainline gcc.  but it is in all Gentoo gcc versions since 4.3.3.  
first added like 3 years ago.
-mike


signature.asc
Description: This is a digitally signed message part.

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

[Diego Elio Pettenò]

Il giorno gio, 20/10/2011 alle 06.40 -0400, Anthony G. Basile ha
scritto:
> It would probably be nearly painless to bring in -D_FORTIFY_SOURCES=2
> and ssp into mainstream though.  Packages which break because of
> either
> of those two features are broken and should be fixed anyhow. 

-D_FORTIFY_SOURCES=2 has been enabled in mainline since GCC 4.3.3-r1 if
my memory serves me right.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/


signature.asc
Description: This is a digitally signed message part