| 1 |
torsdag 12 juni 2014 03.45.23 skrev Greg Turner: |
| 2 |
> On Wed, Jun 11, 2014 at 6:23 AM, Jeroen Roovers <jer@g.o> wrote: |
| 3 |
> > Will bug #332823 and its ilk somehow be mitigated? Emerging glibc with |
| 4 |
> > -fstack-protector still leads to similar problems. There doesn't |
| 5 |
> > currently seem to be a bug report about this that isn't marked INVALID. |
| 6 |
> |
| 7 |
> Is this a bug/limitation in glibc's actual code, or in glibc's build |
| 8 |
> environment? |
| 9 |
> |
| 10 |
> Asked another (wordier) way -- should I understand -- assuming nobody |
| 11 |
> adds some explicit -fno-stack-protector to the non-hardened profiles |
| 12 |
> or the glibc ebuild -- and, of course, also that the user has not put |
| 13 |
> it in make.conf or similar -- that this would break glibc compilation |
| 14 |
> in the base configurations of the x86/amd64 non-hardened profiles?* |
| 15 |
> |
| 16 |
> If that's so... that doesn't sound so great, does it? |
| 17 |
> |
| 18 |
> Just thinking out loud, I guess, but, the fact -- if it is, indeed, |
| 19 |
> still a fact (?) -- that, as of gcc-4.8.2, putting -fstack-protector |
| 20 |
> in your CFLAGS breaks glibc.ebuild doesn't /necessarily/ mean that, as |
| 21 |
> of gcc-4.8.3, leaving -fno-stack-protector out of your cflags would |
| 22 |
> also break it, even if they are supposed to mean the same thing -- |
| 23 |
> that would depend on the specific etiology of the problem. |
| 24 |
> |
| 25 |
> Sorry, perhaps Google Search would answer my question as readily as |
| 26 |
> portage, in which case, by all means feel free to "lmgtfy" my ass. |
| 27 |
> But if nobody knows the answer for sure, presumably you have the means |
| 28 |
> to find out, Ryan? |
| 29 |
> |
| 30 |
> If for any reason you need a guinea-pig, I have a non-hardened |
| 31 |
> triple-multilib (but mostly ABI_X86="64 32") workstation, here, that |
| 32 |
> I'm not afraid to break. |
| 33 |
> |
| 34 |
> -gmt |
| 35 |
> |
| 36 |
> *Apologies for the horrific run-on sentence! |
| 37 |
|
| 38 |
Glibc don't compile well with -fstack-protector* and that way we pass |
| 39 |
-fno-stack-protector to the compiler when we build the lib. It is done in |
| 40 |
common.eblit where we check if the compiler have the ssp spec added as |
| 41 |
hardened and the default gcc 4.9 and 4.8.3 have. |
| 42 |
|
| 43 |
The problem was when user did add -fstack-protector* to the cflag for the check |
| 44 |
didd't check that and upstream will just invalid the bug if you try to compile |
| 45 |
it with -fstack-protector*. |
| 46 |
/Magnus |
Archives