* [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
@ 2011-10-23 18:00 "Paweł Hajdan, Jr."
2011-10-23 19:03 ` Anthony G. Basile
0 siblings, 1 reply; 13+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-23 18:00 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 820 bytes --]
Looks like the thread I started about moving more hardened features to
default
<http://archives.gentoo.org/gentoo-dev/msg_ef3dbd4ba400a5936cd5b7546b86d875.xml>
got a lot of positive feedback. Kernel hardening features are more
problematic, but hardening the toolchain seems to be within reach.
I'd like to produce some implementation plan for that, and my suggestion
is to change the meaning of the "hardened" USE flag for GCC. I'd like to
build all 4 or so specs for gcc always, and the "hardened" USE flag
would just control which one is the default: the vanilla one or
full-hardening one.
This would allow people to manually start using hardened toolchain
without even switching profile, and should be a no-op for everyone else.
From there we can later proceed to apply more features.
Thoughts?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-23 18:00 [gentoo-dev] Building hardened gcc specs always, just not enabling them by default "Paweł Hajdan, Jr."
@ 2011-10-23 19:03 ` Anthony G. Basile
2011-10-23 19:20 ` Alexandre Rostovtsev
0 siblings, 1 reply; 13+ messages in thread
From: Anthony G. Basile @ 2011-10-23 19:03 UTC (permalink / raw
To: gentoo-dev
On 10/23/2011 02:00 PM, "Paweł Hajdan, Jr." wrote:
> Looks like the thread I started about moving more hardened features to
> default
> <http://archives.gentoo.org/gentoo-dev/msg_ef3dbd4ba400a5936cd5b7546b86d875.xml>
> got a lot of positive feedback. Kernel hardening features are more
> problematic, but hardening the toolchain seems to be within reach.
>
> I'd like to produce some implementation plan for that, and my suggestion
> is to change the meaning of the "hardened" USE flag for GCC. I'd like to
> build all 4 or so specs for gcc always, and the "hardened" USE flag
> would just control which one is the default: the vanilla one or
> full-hardening one.
>
> This would allow people to manually start using hardened toolchain
> without even switching profile, and should be a no-op for everyone else.
> From there we can later proceed to apply more features.
>
> Thoughts?
>
Where would the hardened profiles fit in this? This requires some
thought. Right now "hardened" means three choices: 1) hardened
toolchain, 2) hardened-sources kernel, 3) hardened profile. Some
packages are masked or added to the profile for the toolchain, some for
the kernel. We'd have to disentangle those. I'm not sure how the
details would play out.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-23 19:03 ` Anthony G. Basile
@ 2011-10-23 19:20 ` Alexandre Rostovtsev
2011-10-23 19:47 ` Anthony G. Basile
0 siblings, 1 reply; 13+ messages in thread
From: Alexandre Rostovtsev @ 2011-10-23 19:20 UTC (permalink / raw
To: gentoo-dev
On Sun, Oct 23, 2011 at 3:03 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> Where would the hardened profiles fit in this? This requires some
> thought. Right now "hardened" means three choices: 1) hardened
> toolchain, 2) hardened-sources kernel, 3) hardened profile. Some
> packages are masked or added to the profile for the toolchain, some for
> the kernel. We'd have to disentangle those. I'm not sure how the
> details would play out.
My impression was that for the hardened kernels case, specific USE
flags such as "pax_kernel" are supposed to be used instead of the
generic "hardened".
-Alexandre
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-23 19:20 ` Alexandre Rostovtsev
@ 2011-10-23 19:47 ` Anthony G. Basile
2011-10-24 6:58 ` "Paweł Hajdan, Jr."
0 siblings, 1 reply; 13+ messages in thread
From: Anthony G. Basile @ 2011-10-23 19:47 UTC (permalink / raw
To: gentoo-dev
On 10/23/2011 03:20 PM, Alexandre Rostovtsev wrote:
> On Sun, Oct 23, 2011 at 3:03 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> Where would the hardened profiles fit in this? This requires some
>> thought. Right now "hardened" means three choices: 1) hardened
>> toolchain, 2) hardened-sources kernel, 3) hardened profile. Some
>> packages are masked or added to the profile for the toolchain, some for
>> the kernel. We'd have to disentangle those. I'm not sure how the
>> details would play out.
> My impression was that for the hardened kernels case, specific USE
> flags such as "pax_kernel" are supposed to be used instead of the
> generic "hardened".
>
> -Alexandre
>
Yes. Because some people wanted binaries built with a vanilla toolchain
running under a pax kernel. So, we encouraged the use of a different
USE flag to tell ebuilds that this package *might* be run under a
pax_kernel and therefore should have certain pax markings. Since that
has nothing to do with a hardened toolchain, we encouraged the use of a
new local flag, pax_kernel. However, this is a weak USE flag because
pax marking a binary that runs under a vanilla kernel is harmless, as
the kernel will simply ignore the pt_pax program header in the ELF. And
all binaries built in gentoo have this header automatically because of a
patch in binutils. Its added "just in case". You can see it when you
do readelf -l /path/to/elf.
So if you look in the hardened profiles, you'll see some things masked
like net-im/skype because of the kernel, and some things masked like
=sys-devel/gdb-7.0* because of the toolchain. If the hardened toolchain
moves into mainstream, then we'll have to sort through those and figure
out how to incorporate them into the main profiles. How would we say,
if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
gdb-7.0*? I don't think its impossible, but I'm not seeing how to
proceed right now.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-23 19:47 ` Anthony G. Basile
@ 2011-10-24 6:58 ` "Paweł Hajdan, Jr."
2011-10-24 8:49 ` [gentoo-dev] " Duncan
2011-10-24 10:58 ` [gentoo-dev] " Anthony G. Basile
0 siblings, 2 replies; 13+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-24 6:58 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]
On 10/23/11 9:47 PM, Anthony G. Basile wrote:
> So if you look in the hardened profiles, you'll see some things masked
> like net-im/skype because of the kernel, and some things masked like
> =sys-devel/gdb-7.0* because of the toolchain. If the hardened toolchain
> moves into mainstream, then we'll have to sort through those and figure
> out how to incorporate them into the main profiles.
That's right. My goal now is to come up with a realistic plan how to do
that. It seems most people agree it's a good goal, now we'd need to
identify possible problems and find solutions.
Thank you for helping identify problems. Please take a look to see if my
suggestions make sense.
> How would we say,
> if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
> gdb-7.0*? I don't think its impossible, but I'm not seeing how to
> proceed right now.
First, I'd like the hardened spec to be non-default, so that if the user
chooses the hardened spec he'd be "on his own", and expect possibly more
breakages.
Second, profiles/hardened/package.mask seems to contain only few
entries, and a more recent gdb than 7.0 works and is in stable. I've
checked on my hardened system. This doesn't seem to be a serious issue,
maybe we can just punt gdb 7.0 or print a message that it's expected to
be broken with hardened spec.
Third - can we forcefully disable hardened features in packages that are
not compatible? My assumption is yes, and we should probably print a
warning then.
Fourth - we can add the gcc spec to emerge --info.
What do you think?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default
2011-10-24 6:58 ` "Paweł Hajdan, Jr."
@ 2011-10-24 8:49 ` Duncan
2011-10-24 10:58 ` [gentoo-dev] " Anthony G. Basile
1 sibling, 0 replies; 13+ messages in thread
From: Duncan @ 2011-10-24 8:49 UTC (permalink / raw
To: gentoo-dev
Paweł Hajdan, Jr. posted on Mon, 24 Oct 2011 08:58:57 +0200 as excerpted:
> Third - can we forcefully disable hardened features in packages that are
> not compatible? My assumption is yes, and we should probably print a
> warning then.
If a warning is to be printed (and I agree that's a good idea), please
arrange for it to be disableable per-package (perhaps via environmental
variable setting, WARN_DISABLE_HARDENED or the like).
That way, either the PM can implement a package.hardened-warn or
whatever, or (for portage at least) the user can arrange for the same
effect via /etc/portage/env/*/* files.
The idea would be that the user can accumulate an easily checked list of
packages he knows about and doesn't want to be bothered by the hardened-
disable warnings for, while he still gets visible warnings for packages
not on that list (and thus presumably that he's not yet aware of) that
disable whatever hardening feature.
Or just make it a USE flag on the packages it applies to: hardened-warn
or the like, which use-defaults to ON.
Either way, an eclass to standardize things sounds very useful.
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-24 6:58 ` "Paweł Hajdan, Jr."
2011-10-24 8:49 ` [gentoo-dev] " Duncan
@ 2011-10-24 10:58 ` Anthony G. Basile
2011-10-24 11:26 ` "Paweł Hajdan, Jr."
1 sibling, 1 reply; 13+ messages in thread
From: Anthony G. Basile @ 2011-10-24 10:58 UTC (permalink / raw
To: gentoo-dev
On 10/24/2011 02:58 AM, "Paweł Hajdan, Jr." wrote:
>
>> How would we say,
>> if you use gcc-config and choose gcc-4.5.1-hardened spec, mask
>> gdb-7.0*? I don't think its impossible, but I'm not seeing how to
>> proceed right now.
> First, I'd like the hardened spec to be non-default, so that if the user
> chooses the hardened spec he'd be "on his own", and expect possibly more
> breakages.
Well not totally on their own, they'd report it and we'd have to see
what we want to do on an ad hoc basis. So maybe the first step would be
to just build 5 specs:
[1] x86_64-pc-linux-gnu-4.4.5
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
[4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
[5] x86_64-pc-linux-gnu-4.4.5-vanilla
Here [1] = fully hardened. Then ship with no other changes. When bug
start to come in, you can deal with each --- some may be fixes at the
package level (usually the build system), some may be ebuild fixes, some
may need to go into the profiles.
There is one other catch Zorry pointed out, glibc. There are some
patches against glibc which would have to go in unconditionally. Take a
look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
they're if use hardened. That conditional would be removed.
> Second, profiles/hardened/package.mask seems to contain only few
> entries, and a more recent gdb than 7.0 works and is in stable. I've
> checked on my hardened system. This doesn't seem to be a serious issue,
> maybe we can just punt gdb 7.0 or print a message that it's expected to
> be broken with hardened spec.
Those profiles have some ancient stuff in them which we know about, but
haven't removed for legacy reasons. You want to look at the files under
profiles/hardened/linux/ What would wind up happening if hardened goes
mainstream is that those profiles would be reduced to just the
maskings/unmaskings for a pax hardened kernel. Selinux has its own.
> Third - can we forcefully disable hardened features in packages that are
> not compatible? My assumption is yes, and we should probably print a
> warning then.
There are a few things you can do here, yes. It is always possible to
turn off hardening because the *last* resort solution is just switch
compile specs in the ebuild. This is only if none of the other methods
work, the best method being fix the build system so you can switch the
feature off in configure. I had to use it once for virtualbox which has
a brain dead build system. There we warn the user to switch specs in
pkg_setup() using ... if built_with_use sys-devel/gcc hardened.
> Fourth - we can add the gcc spec to emerge --info.
>
> What do you think?
>
Good idea.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-24 10:58 ` [gentoo-dev] " Anthony G. Basile
@ 2011-10-24 11:26 ` "Paweł Hajdan, Jr."
2011-10-24 13:04 ` Francesco Riosa
2011-10-25 5:59 ` [gentoo-dev] " Ryan Hill
0 siblings, 2 replies; 13+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-24 11:26 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4108 bytes --]
On 10/24/11 12:58 PM, Anthony G. Basile wrote:
> Well not totally on their own, they'd report it and we'd have to see
> what we want to do on an ad hoc basis.
Fair enough, that's why I suggested to make the hardened spec
non-default, so that they have to switch it, and include the info in
emerge --info so we can identify the reason.
> So maybe the first step would be
> to just build 5 specs:
>
> [1] x86_64-pc-linux-gnu-4.4.5
> [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
> [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
> [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
> [5] x86_64-pc-linux-gnu-4.4.5-vanilla
>
> Here [1] = fully hardened. Then ship with no other changes. When bug
> start to come in, you can deal with each --- some may be fixes at the
> package level (usually the build system), some may be ebuild fixes, some
> may need to go into the profiles.
Right, this is exactly what I'm suggesting, just make [5] the default or
do some juggling so that [1] is vanilla and [5] is fully hardened or
something like that.
> There is one other catch Zorry pointed out, glibc. There are some
> patches against glibc which would have to go in unconditionally. Take a
> look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
> they're if use hardened. That conditional would be removed.
Ah, ok. So we have another one. Let's find out our exact constraints:
1. Are those glibc patches required for gcc built with hardened support?
Will the gcc build fail without them, or will things fail at runtime
without them?
2. Enabling glibc patches would mean enabling PIC by default, right? Is
that OK? Can it cause breakages?
3. Am I reading things correctly that PIE is _not_ enabled by default,
but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs?
> Those profiles have some ancient stuff in them which we know about, but
> haven't removed for legacy reasons.
Please note I've checked on my hardened system and the file I cited has
been used and provided as the mask reason. Maybe it's ancient, but it's
still in use.
> You want to look at the files under
> profiles/hardened/linux/ What would wind up happening if hardened goes
> mainstream is that those profiles would be reduced to just the
> maskings/unmaskings for a pax hardened kernel. Selinux has its own.
Sounds good. By the way, if you're concerned about masking things and so
on - why are hardened-sources _not_ masked on non-hardened profiles?
There are two ways to get an invalid mix of hardened kernel and
incompatible packages:
a) hardened profile + trying to emerge incompatible packages (this is
currently blocked by p.mask entries)
b) normal profile + incompatible packages + hardened-sources (not blocked)
>> Third - can we forcefully disable hardened features in packages that are
>> not compatible? My assumption is yes, and we should probably print a
>> warning then.
>
> There are a few things you can do here, yes. It is always possible to
> turn off hardening because the *last* resort solution is just switch
> compile specs in the ebuild.
Do you mean calling gcc-config here or something else? If gcc-config,
it'd be quite hacky and fragile (parallel building of multiple packages,
having multiple versions of gcc installed).
Is it possible to just pass flags to GCC: disable all this hardened
stuff? I know you can disable stack protector, but how about PIE or PIC,
and possible other hardening features?
> This is only if none of the other methods
> work, the best method being fix the build system so you can switch the
> feature off in configure. I had to use it once for virtualbox which has
> a brain dead build system. There we warn the user to switch specs in
> pkg_setup() using ... if built_with_use sys-devel/gcc hardened.
Ah, so it tells the user to switch gcc profile and dies. :-/
Well, in my opinion we could get rid of virtualbox anyway (p.mask it
everywhere), I think it has been tainted in the kernel as crap.
<https://lkml.org/lkml/2011/10/6/317>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default
2011-10-24 11:26 ` "Paweł Hajdan, Jr."
@ 2011-10-24 13:04 ` Francesco Riosa
2011-10-25 5:59 ` [gentoo-dev] " Ryan Hill
1 sibling, 0 replies; 13+ messages in thread
From: Francesco Riosa @ 2011-10-24 13:04 UTC (permalink / raw
To: gentoo-dev
[...]
>
> Well, in my opinion we could get rid of virtualbox anyway (p.mask it
> everywhere), I think it has been tainted in the kernel as crap.
> <https://lkml.org/lkml/2011/10/6/317>
>
<troll>
please do the same for x11-drivers/nvidia-drivers and x11-drivers/ati-drivers
</troll>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default
2011-10-24 11:26 ` "Paweł Hajdan, Jr."
2011-10-24 13:04 ` Francesco Riosa
@ 2011-10-25 5:59 ` Ryan Hill
2011-10-25 12:04 ` Rich Freeman
2011-10-25 13:58 ` Anthony G. Basile
1 sibling, 2 replies; 13+ messages in thread
From: Ryan Hill @ 2011-10-25 5:59 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3441 bytes --]
On Mon, 24 Oct 2011 13:26:01 +0200
""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
> On 10/24/11 12:58 PM, Anthony G. Basile wrote:
> > Well not totally on their own, they'd report it and we'd have to see
> > what we want to do on an ad hoc basis.
>
> Fair enough, that's why I suggested to make the hardened spec
> non-default, so that they have to switch it, and include the info in
> emerge --info so we can identify the reason.
>
> > So maybe the first step would be
> > to just build 5 specs:
> >
> > [1] x86_64-pc-linux-gnu-4.4.5
> > [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
> > [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
> > [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
> > [5] x86_64-pc-linux-gnu-4.4.5-vanilla
> >
> > Here [1] = fully hardened. Then ship with no other changes. When bug
> > start to come in, you can deal with each --- some may be fixes at the
> > package level (usually the build system), some may be ebuild fixes, some
> > may need to go into the profiles.
>
> Right, this is exactly what I'm suggesting, just make [5] the default or
> do some juggling so that [1] is vanilla and [5] is fully hardened or
> something like that.
I would expect x86_64-pc-linux-gnu-4.4.5 to be the vanilla profile and the
fully hardened one to be something like x86_64-pc-linux-gnu-4.4.5-hardened.
> > There is one other catch Zorry pointed out, glibc. There are some
> > patches against glibc which would have to go in unconditionally. Take a
> > look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
> > they're if use hardened. That conditional would be removed.
>
> Ah, ok. So we have another one. Let's find out our exact constraints:
>
> 1. Are those glibc patches required for gcc built with hardened support?
> Will the gcc build fail without them, or will things fail at runtime
> without them?
>
> 2. Enabling glibc patches would mean enabling PIC by default, right? Is
> that OK? Can it cause breakages?
>
> 3. Am I reading things correctly that PIE is _not_ enabled by default,
> but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs?
I imagine they're conditional for a reason. I just don't know what that
reason is myself. ;)
> >> Third - can we forcefully disable hardened features in packages that are
> >> not compatible? My assumption is yes, and we should probably print a
> >> warning then.
> >
> > There are a few things you can do here, yes. It is always possible to
> > turn off hardening because the *last* resort solution is just switch
> > compile specs in the ebuild.
>
> Do you mean calling gcc-config here or something else? If gcc-config,
> it'd be quite hacky and fragile (parallel building of multiple packages,
> having multiple versions of gcc installed).
>
> Is it possible to just pass flags to GCC: disable all this hardened
> stuff? I know you can disable stack protector, but how about PIE or PIC,
> and possible other hardening features?
You might be able to use the GCC_SPECS env var.
Personally I think this is a lot of work for not much benefit, but if you
want to do it then who am I to argue.
--
fonts, gcc-porting, it makes no sense how it makes no sense
toolchain, wxwidgets but i'll take it free anytime
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default
2011-10-25 5:59 ` [gentoo-dev] " Ryan Hill
@ 2011-10-25 12:04 ` Rich Freeman
2011-10-25 13:58 ` Anthony G. Basile
1 sibling, 0 replies; 13+ messages in thread
From: Rich Freeman @ 2011-10-25 12:04 UTC (permalink / raw
To: gentoo-dev
On Tue, Oct 25, 2011 at 1:59 AM, Ryan Hill <dirtyepic@gentoo.org> wrote:
> On Mon, 24 Oct 2011 13:26:01 +0200
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
>> Is it possible to just pass flags to GCC: disable all this hardened
>> stuff? I know you can disable stack protector, but how about PIE or PIC,
>> and possible other hardening features?
>
> You might be able to use the GCC_SPECS env var.
>
> Personally I think this is a lot of work for not much benefit, but if you
> want to do it then who am I to argue.
Wouldn't the potential benefit to be allowing more hardened flags to
go into the default specs so that everybody benefits, but then
allowing individual packages to turn them off for compatibility
reasons. This would be not unlike what we do with filter-flags for
packages that are finicky about optimizations.
I'm not suggesting putting flags that break 90% of packages in the
defaults. However, right now in the discussion about moving some
hardened features to default the sense is that we sacrifice hardening
for the sake of package selection, so a flag that breaks 5% of the
packages in the tree wouldn't be a good one to enable. However,
setting the specs per-package would let you be a little more
aggressive since fixing a few odd ebuilds isn't a big deal, as long as
the settings don't cause trouble if not enabled system-wide.
Rich
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default
2011-10-25 5:59 ` [gentoo-dev] " Ryan Hill
2011-10-25 12:04 ` Rich Freeman
@ 2011-10-25 13:58 ` Anthony G. Basile
2011-10-26 9:51 ` "Paweł Hajdan, Jr."
1 sibling, 1 reply; 13+ messages in thread
From: Anthony G. Basile @ 2011-10-25 13:58 UTC (permalink / raw
To: gentoo-dev
On 10/25/2011 01:59 AM, Ryan Hill wrote:
> On Mon, 24 Oct 2011 13:26:01 +0200
> ""Paweł Hajdan, Jr."" <phajdan.jr@gentoo.org> wrote:
>
>> On 10/24/11 12:58 PM, Anthony G. Basile wrote:
>>> Well not totally on their own, they'd report it and we'd have to see
>>> what we want to do on an ad hoc basis.
>> Fair enough, that's why I suggested to make the hardened spec
>> non-default, so that they have to switch it, and include the info in
>> emerge --info so we can identify the reason.
>>
>>> So maybe the first step would be
>>> to just build 5 specs:
>>>
>>> [1] x86_64-pc-linux-gnu-4.4.5
>>> [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
>>> [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
>>> [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
>>> [5] x86_64-pc-linux-gnu-4.4.5-vanilla
>>>
>>> Here [1] = fully hardened. Then ship with no other changes. When bug
>>> start to come in, you can deal with each --- some may be fixes at the
>>> package level (usually the build system), some may be ebuild fixes, some
>>> may need to go into the profiles.
>> Right, this is exactly what I'm suggesting, just make [5] the default or
>> do some juggling so that [1] is vanilla and [5] is fully hardened or
>> something like that.
> I would expect x86_64-pc-linux-gnu-4.4.5 to be the vanilla profile and the
> fully hardened one to be something like x86_64-pc-linux-gnu-4.4.5-hardened.
>
Actually, that's what I would expect too, I just cut and pasted the
above from my gcc-config on a hardened profile. On vanilla gentoo, it
would read:
[1] x86_64-pc-linux-gnu-4.4.5
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
[4] x86_64-pc-linux-gnu-4.4.5-hardenednossp
[5] x86_64-pc-linux-gnu-4.4.5-hardened
Where [1] is vanilla and default.
>>> There is one other catch Zorry pointed out, glibc. There are some
>>> patches against glibc which would have to go in unconditionally. Take a
>>> look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently
>>> they're if use hardened. That conditional would be removed.
>> Ah, ok. So we have another one. Let's find out our exact constraints:
>>
>> 1. Are those glibc patches required for gcc built with hardened support?
>> Will the gcc build fail without them, or will things fail at runtime
>> without them?
>>
>> 2. Enabling glibc patches would mean enabling PIC by default, right? Is
>> that OK? Can it cause breakages?
>>
>> 3. Am I reading things correctly that PIE is _not_ enabled by default,
>> but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs?
> I imagine they're conditional for a reason. I just don't know what that
> reason is myself. ;)
>
Zorry's the expert here, so I'll ask him to correct me if I miss
anything or get something wrong.
You won't get hardening without those patches. So they need to be there
if the user switches specs from vanilla to hardened. Here's what they do:
1) glibc-2.10-gentoo-chk_fail.c - introduces a wrapper function for
__chk_fail() which is triggered on FORTIFY_SOURCES failure (I think, I'm
not certain on this one). The wrapped function
__hardened_gentoo_chk_fail() writes messages/dumps and kills the process.
2) glibc-2.6-gentoo-stack_chk_fail.c - similar but for
__stack_chk_fail() and __stack_smash_handler() triggered on stack
smashing. Needed at runtime.
The later symbol is there when compiling with
x86_64-pc-linux-gnu-4.4.5-hardened but not x86_64-pc-linux-gnu-4.4.5.
Here's nm test.o for int main(){;return0;}
Hardened:
<skip stuff>
U __libc_start_main@@GLIBC_2.2.5
U __stack_chk_fail@@GLIBC_2.4 < called on stack
smashing
0000000000201010 A _edata
0000000000201020 A _end
<skip stuff>
Vanilla:
<skip stuff>
00000000004004f0 T __libc_csu_init
U __libc_start_main@@GLIBC_2.2.5
0000000000601018 A _edata
0000000000601028 A _end
<skip stuff>
3) glibc-2.10-hardened-ssp-compat.patch - this is for the older gcc-3
stack smashing protection using __guard() instead of __stack_chk_fail().
4) glibc-2.10-hardened-configure-picdefault.patch +
glibc-2.10-hardened-inittls-nosysenter.patch +
glibc-2.12-hardened-pie.patch. These are needed at compile time to make
sure we build glibc pie and enable pic by default.
Binaries are not built pie with vanilla, hardenednopie or
hardenednopiessp gcc. You get pie with the other two specs.
>>>> Third - can we forcefully disable hardened features in packages that are
>>>> not compatible? My assumption is yes, and we should probably print a
>>>> warning then.
>>> There are a few things you can do here, yes. It is always possible to
>>> turn off hardening because the *last* resort solution is just switch
>>> compile specs in the ebuild.
>> Do you mean calling gcc-config here or something else? If gcc-config,
>> it'd be quite hacky and fragile (parallel building of multiple packages,
>> having multiple versions of gcc installed).
>>
>> Is it possible to just pass flags to GCC: disable all this hardened
>> stuff? I know you can disable stack protector, but how about PIE or PIC,
>> and possible other hardening features?
Yes, I was referring to something like gcc-config but I only meant it as
an extreme. If you are using x86_64-pc-linux-gnu-4.4.5-hardened, you
can pass it the --nopie flag to turn off pie. This can be introduced to
the build system via CFLAGS. Like I said, only virtualbox has a build
system where I just couldn't get it to accept this flag. But manually
switching to hardenednopie works.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : blueness@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [gentoo-dev] Re: Building hardened gcc specs always, just not enabling them by default
2011-10-25 13:58 ` Anthony G. Basile
@ 2011-10-26 9:51 ` "Paweł Hajdan, Jr."
0 siblings, 0 replies; 13+ messages in thread
From: "Paweł Hajdan, Jr." @ 2011-10-26 9:51 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
On 10/25/11 3:58 PM, Anthony G. Basile wrote:
> Zorry's the expert here, so I'll ask him to correct me if I miss
> anything or get something wrong.
>
> You won't get hardening without those patches. So they need to be there
> if the user switches specs from vanilla to hardened.
Thanks, I've filed <https://bugs.gentoo.org/show_bug.cgi?id=388525> and
tested this locally.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-10-26 9:52 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-23 18:00 [gentoo-dev] Building hardened gcc specs always, just not enabling them by default "Paweł Hajdan, Jr."
2011-10-23 19:03 ` Anthony G. Basile
2011-10-23 19:20 ` Alexandre Rostovtsev
2011-10-23 19:47 ` Anthony G. Basile
2011-10-24 6:58 ` "Paweł Hajdan, Jr."
2011-10-24 8:49 ` [gentoo-dev] " Duncan
2011-10-24 10:58 ` [gentoo-dev] " Anthony G. Basile
2011-10-24 11:26 ` "Paweł Hajdan, Jr."
2011-10-24 13:04 ` Francesco Riosa
2011-10-25 5:59 ` [gentoo-dev] " Ryan Hill
2011-10-25 12:04 ` Rich Freeman
2011-10-25 13:58 ` Anthony G. Basile
2011-10-26 9:51 ` "Paweł Hajdan, Jr."
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox