On 10/25/2011 01:59 AM, Ryan Hill wrote:
> On Mon, 24 Oct 2011 13:26:01 +0200
> ""Paweł Hajdan, Jr."" <[email protected]> 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 : [email protected]
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
