Why has -fstack-clash-protection been added to optflags?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Why has -fstack-clash-protection been added to optflags?

Dave Plater lst
Hi I've had build failures specifically on 42.3 packages that need gcc5
and up to build. The failures are due to  -fstack-clash-protection,
which only works with gcc7, having been added to %optflags. Strangely
42.2 builds with gcc5 don't have this flag.
Is there any way to bypass this besides rewriting %optflags?
Why is this flag in 42.3 builds but not 42.2?
Why does this flag pass on gcc48?
Thanks
Dave P
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why has -fstack-clash-protection been added to optflags?

Richard Biener
On Tue, 23 Jan 2018, Dave Plater wrote:

> Hi I've had build failures specifically on 42.3 packages that need gcc5 and up
> to build. The failures are due to  -fstack-clash-protection, which only works
> with gcc7, having been added to %optflags. Strangely 42.2 builds with gcc5
> don't have this flag.
> Is there any way to bypass this besides rewriting %optflags?
> Why is this flag in 42.3 builds but not 42.2?
> Why does this flag pass on gcc48?

gcc48 also supports this flag.  I would suggest to change the packages
requiring the non-system gcc5 to instead require gcc7.

Richard.

> Thanks
> Dave P
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why has -fstack-clash-protection been added to optflags?

Dave Plater lst


On 23/01/2018 10:11, Richard Biener wrote:
> gcc48 also supports this flag.  I would suggest to change the packages
> requiring the non-system gcc5 to instead require gcc7.
>
I've done that with xine-lib and will do that with libmlt but audacity
which has a gcc minimum of 4.9 has to build with the same version of gcc
as wxWidgets-3_0-nostl which the 42.3 update package is built with gcc5.
Packman doesn't seem to use the same optflags yet and I can disable and
wipe binaries in multimedia:apps/audacity 42.3 but I suppose I'll have
to rewrite optflags for 42.3 audacity. Roll on Leap:15.
Why did this bite 42.3 and not 42.2?
Thanks
Dave P
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Marcus Meissner
In reply to this post by Dave Plater lst
Hi,

This was me, I enabled it yesterday night again.

Can you use "gcc7" or "gcc48" from 42.3:Update?

Where is gcc5 coming from?

I really would like to enable this security feature.

Ciao, Marcus

On Tue, Jan 23, 2018 at 10:01:12AM +0200, Dave Plater wrote:

> Hi I've had build failures specifically on 42.3 packages that need gcc5 and
> up to build. The failures are due to  -fstack-clash-protection, which only
> works with gcc7, having been added to %optflags. Strangely 42.2 builds with
> gcc5 don't have this flag.
> Is there any way to bypass this besides rewriting %optflags?
> Why is this flag in 42.3 builds but not 42.2?
> Why does this flag pass on gcc48?
> Thanks
> Dave P
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>

--
Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <[hidden email]>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Re: [opensuse-packaging] Why has -fstack-clash-protection been added to optflags?

Marcus Meissner
In reply to this post by Dave Plater lst
On Tue, Jan 23, 2018 at 10:57:24AM +0200, Dave Plater wrote:

>
>
> On 23/01/2018 10:11, Richard Biener wrote:
> > gcc48 also supports this flag.  I would suggest to change the packages
> > requiring the non-system gcc5 to instead require gcc7.
> >
> I've done that with xine-lib and will do that with libmlt but audacity which
> has a gcc minimum of 4.9 has to build with the same version of gcc as
> wxWidgets-3_0-nostl which the 42.3 update package is built with gcc5.
> Packman doesn't seem to use the same optflags yet and I can disable and wipe
> binaries in multimedia:apps/audacity 42.3 but I suppose I'll have to rewrite
> optflags for 42.3 audacity. Roll on Leap:15.
> Why did this bite 42.3 and not 42.2?

I only enabled it on 42.3.

Note that 42.2 goes EOL this week.

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why has -fstack-clash-protection been added to optflags?

Cristian Rodríguez-2
In reply to this post by Dave Plater lst


El 23-01-2018 a las 5:01, Dave Plater escribió:
> Hi I've had build failures specifically on 42.3 packages that need gcc5
> and up to build. The failures are due to  -fstack-clash-protection,
> which only works with gcc7, having been added to %optflags. Strangely
> 42.2 builds with gcc5 don't have this flag.
> Is there any way to bypass this besides rewriting %optflags?
> Why is this flag in 42.3 builds but not 42.2?
> Why does this flag pass on gcc48?
> Thanks
> Dave P

Well.. answering subject,this is the needed fix for a full class of
vulnerabilities described here
https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash

Now, this is not the only flag you will need to handle .. you will soon
need to handle -mindirect-branch= to prevent Spectre ..
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Dave Plater lst
In reply to this post by Marcus Meissner


On 23/01/2018 11:33, Marcus Meissner wrote:
> Hi,
>
> This was me, I enabled it yesterday night again.
>
> Can you use "gcc7" or "gcc48" from 42.3:Update?
Any chance of a gcc5 update as well?
>
> Where is gcc5 coming from?
My home and multimedia:apps repos are fed from openSUSE:Leap:42.3:Update.
>
> I really would like to enable this security feature.
>
> Ciao, Marcus
gcc7 is fine for all but audacity's 42.3 build. At the onset of 42.3
audacity had a minimum gcc requirement of 4.9 so I used gcc5 and found
that wxWidgets-3_0-nostl also had to be built with gcc5, updates were
made but this means that newer audacity's also have to build with gcc5
for 42.3. I'm assuming that  -fstack-clash-protection must be a build
option which wasn't used with gcc5 and gcc6.
I'm going to wipe the multimedia:apps/audacity 42.3 binaries, it's still
available in Packman for 42.3, their repos obviously don't link to 42.3
update, they should though.
Thanks
Dave P
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Why has -fstack-clash-protection been added to optflags?

Dave Plater lst
In reply to this post by Cristian Rodríguez-2


On 23/01/2018 15:59, Cristian Rodríguez wrote:

>
>
> El 23-01-2018 a las 5:01, Dave Plater escribió:
>> Hi I've had build failures specifically on 42.3 packages that need
>> gcc5 and up to build. The failures are due to  
>> -fstack-clash-protection, which only works with gcc7, having been
>> added to %optflags. Strangely 42.2 builds with gcc5 don't have this flag.
>> Is there any way to bypass this besides rewriting %optflags?
>> Why is this flag in 42.3 builds but not 42.2?
>> Why does this flag pass on gcc48?
>> Thanks
>> Dave P
>
> Well.. answering subject,this is the needed fix for a full class of
> vulnerabilities described here
> https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
>
> Now, this is not the only flag you will need to handle .. you will soon
> need to handle -mindirect-branch= to prevent Spectre ..
The main question is why were Leap:42.3's gcc5 and gcc6 excluded from
this security fix?
I've created a bug:
https://bugzilla.novell.com/show_bug.cgi?id=1077345
Dave P
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Richard Biener
In reply to this post by Dave Plater lst
On Tue, 23 Jan 2018, Dave Plater wrote:

>
>
> On 23/01/2018 11:33, Marcus Meissner wrote:
> > Hi,
> >
> > This was me, I enabled it yesterday night again.
> >
> > Can you use "gcc7" or "gcc48" from 42.3:Update?
> Any chance of a gcc5 update as well?
> >
> > Where is gcc5 coming from?
> My home and multimedia:apps repos are fed from openSUSE:Leap:42.3:Update.
> >
> > I really would like to enable this security feature.
> >
> > Ciao, Marcus
> gcc7 is fine for all but audacity's 42.3 build. At the onset of 42.3 audacity
> had a minimum gcc requirement of 4.9 so I used gcc5 and found that
> wxWidgets-3_0-nostl also had to be built with gcc5, updates were made but this
> means that newer audacity's also have to build with gcc5 for 42.3. I'm
> assuming that  -fstack-clash-protection must be a build option which wasn't
> used with gcc5 and gcc6.

I can't see how anything sane would prevent using a newer compiler for
any of the above packages.  The compilers generate ABI compatible
code after all, so unless audacity and friends do sth very stupid there
shouldn't be an issue with building one of them with a newer compiler.

Richard.

> I'm going to wipe the multimedia:apps/audacity 42.3 binaries, it's still
> available in Packman for 42.3, their repos obviously don't link to 42.3
> update, they should though.
> Thanks
> Dave P
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Dave Plater lst


On 24/01/2018 10:26, Richard Biener wrote:
> I can't see how anything sane would prevent using a newer compiler for
> any of the above packages.  The compilers generate ABI compatible
> code after all, so unless audacity and friends do sth very stupid there
> shouldn't be an issue with building one of them with a newer compiler.
>
> Richard.
wxWidgets is very sensitive see:
http://bugzilla.suse.com/show_bug.cgi?id=1074040
https://bugzilla.opensuse.org/show_bug.cgi?id=1051717
https://bugzilla.suse.com/show_bug.cgi?id=1030196
It's a pity I didn't choose gcc7 then but audacity appears to be very
popular in our distribution.
Another question, logic dictates that a package has to actually build
with  -fstack-clash-protection to benefit from it? Doesn't this mean
that all 42.3 packages need to rebuild?
BTW packman does connect to 42.3:Update, audacity fails to build there.
Dave
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Richard Biener
On Wed, 24 Jan 2018, Dave Plater wrote:

>
>
> On 24/01/2018 10:26, Richard Biener wrote:
> > I can't see how anything sane would prevent using a newer compiler for
> > any of the above packages.  The compilers generate ABI compatible
> > code after all, so unless audacity and friends do sth very stupid there
> > shouldn't be an issue with building one of them with a newer compiler.
> >
> > Richard.
> wxWidgets is very sensitive see:
> http://bugzilla.suse.com/show_bug.cgi?id=1074040
> https://bugzilla.opensuse.org/show_bug.cgi?id=1051717
> https://bugzilla.suse.com/show_bug.cgi?id=1030196
> It's a pity I didn't choose gcc7 then but audacity appears to be very popular
> in our distribution.

Error message from console reads thus:

audacity
Fatal Error: Mismatch between the program and library build versions
detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
containers,compatible with 2.8).

this seems to be a premature check done by wxWidgets / audacity?  They
appear to key on __GXX_ABI_VERSION but almost _nothing_ changes when
this version changes.  It's really only for corner cases like fixing
mangling with vectors and attributes.  For packages you could also
simply downgrade the ABI version via -fabi-version=N (but then you'd
have to have a way to communicate the ABI version chosen to compile
wxWidgets to wxWidget users).  There is also the corresponding
-Wabi=N so you can instead do -Wabi=N (ABI version used to compile
wxWidget).

Can you somehow disable this checking for wxWidgets?  It seems _really_
odd they invented this.

Googling reveals the current upstream version has

// GCC and Intel C++ share same C++ ABI (and possibly others in the
future),
// check if compiler versions are compatible:
#if defined(__GXX_ABI_VERSION)
    // The changes between ABI versions 1002 through 1010 (documented at
    // https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
    // under -fabi-version) don't affect wxWidgets, so we allow a library
    // and an application to differ within that range.
    #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010))
        #define wxGXX_EFFECTIVE_ABI_VERSION 1002
    #else
        #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION
#endif

so wouldn't have complained like in bnc#1074040.  GCC 7 introduces version
11 which I bet also doesn't affect wxWidgets...  quoting the docs:

Version 11, which first appeared in G++ 7, corrects the mangling of
sizeof... expressions and operator names.  For multiple entities with
the same name within a function, that are declared in different scopes,
the mangling now changes starting with the twelfth occurrence.  It also
implies @option{-fnew-inheriting-ctors}.

Just patch this insanity out ...

Richard.

> Another question, logic dictates that a package has to actually build with
> -fstack-clash-protection to benefit from it? Doesn't this mean that all 42.3
> packages need to rebuild?
> BTW packman does connect to 42.3:Update, audacity fails to build there.
> Dave
>
>

--
Richard Biener <[hidden email]>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Marcus Meissner
In reply to this post by Dave Plater lst
On Wed, Jan 24, 2018 at 11:13:35AM +0200, Dave Plater wrote:

>
>
> On 24/01/2018 10:26, Richard Biener wrote:
> > I can't see how anything sane would prevent using a newer compiler for
> > any of the above packages.  The compilers generate ABI compatible
> > code after all, so unless audacity and friends do sth very stupid there
> > shouldn't be an issue with building one of them with a newer compiler.
> >
> > Richard.
> wxWidgets is very sensitive see:
> http://bugzilla.suse.com/show_bug.cgi?id=1074040
> https://bugzilla.opensuse.org/show_bug.cgi?id=1051717
> https://bugzilla.suse.com/show_bug.cgi?id=1030196
> It's a pity I didn't choose gcc7 then but audacity appears to be very
> popular in our distribution.

> Another question, logic dictates that a package has to actually build with
> -fstack-clash-protection to benefit from it? Doesn't this mean that all 42.3
> packages need to rebuild?

The idea is to slowly get packages rebuilt with this option just by
releasing regular updates with other fixes.

We can selectively update for instance setuid root applications just for this,
but I have so far not specifically planned for that.

Ciao, Marcus
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Dave Plater lst
In reply to this post by Richard Biener


On 24/01/2018 12:02, Richard Biener wrote:

> audacity
> Fatal Error: Mismatch between the program and library build versions
> detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
> containers,compatible with 2.8).
>
> this seems to be a premature check done by wxWidgets / audacity?  They
> appear to key on __GXX_ABI_VERSION but almost_nothing_  changes when
> this version changes.  It's really only for corner cases like fixing
> mangling with vectors and attributes.  For packages you could also
> simply downgrade the ABI version via -fabi-version=N (but then you'd
> have to have a way to communicate the ABI version chosen to compile
> wxWidgets to wxWidget users).  There is also the corresponding
> -Wabi=N so you can instead do -Wabi=N (ABI version used to compile
> wxWidget).
>
> Can you somehow disable this checking for wxWidgets?  It seems_really_
> odd they invented this.
>
> Googling reveals the current upstream version has
>
> // GCC and Intel C++ share same C++ ABI (and possibly others in the
> future),
> // check if compiler versions are compatible:
> #if defined(__GXX_ABI_VERSION)
>      // The changes between ABI versions 1002 through 1010 (documented at
>      //https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
>      // under -fabi-version) don't affect wxWidgets, so we allow a library
>      // and an application to differ within that range.
>      #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010))
>          #define wxGXX_EFFECTIVE_ABI_VERSION 1002
>      #else
>          #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION
> #endif
>
> so wouldn't have complained like in bnc#1074040.  GCC 7 introduces version
> 11 which I bet also doesn't affect wxWidgets...  quoting the docs:
>
> Version 11, which first appeared in G++ 7, corrects the mangling of
> sizeof... expressions and operator names.  For multiple entities with
> the same name within a function, that are declared in different scopes,
> the mangling now changes starting with the twelfth occurrence.  It also
> implies @option{-fnew-inheriting-ctors}.
>
> Just patch this insanity out ...
>
> Richard.

Thanks Richard, you've given me some things to try out, maybe audacity
built with gcc7 will work with wxWidgets built with gcc5. I've explored
the abi check function in the past with intent to patch it out but had
to use my time for other work.
Dave
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-factory] Why has -fstack-clash-protection been added to optflags?

Dave Plater lst
In reply to this post by Richard Biener


On 24/01/2018 12:02, Richard Biener wrote:

> Error message from console reads thus:
>
> audacity
> Fatal Error: Mismatch between the program and library build versions
> detected.
> The library used 3.0 (wchar_t,compiler with C++ ABI 1002,wx
> containers,compatible with 2.8),
> and your program used 3.0 (wchar_t,compiler with C++ ABI 1009,wx
> containers,compatible with 2.8).
>
> this seems to be a premature check done by wxWidgets / audacity?  They
> appear to key on __GXX_ABI_VERSION but almost_nothing_  changes when
> this version changes.  It's really only for corner cases like fixing
> mangling with vectors and attributes.  For packages you could also
> simply downgrade the ABI version via -fabi-version=N (but then you'd
> have to have a way to communicate the ABI version chosen to compile
> wxWidgets to wxWidget users).  There is also the corresponding
> -Wabi=N so you can instead do -Wabi=N (ABI version used to compile
> wxWidget).
>
> Can you somehow disable this checking for wxWidgets?  It seems_really_
> odd they invented this.
>
> Googling reveals the current upstream version has
>
> // GCC and Intel C++ share same C++ ABI (and possibly others in the
> future),
> // check if compiler versions are compatible:
> #if defined(__GXX_ABI_VERSION)
>      // The changes between ABI versions 1002 through 1010 (documented at
>      //https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
>      // under -fabi-version) don't affect wxWidgets, so we allow a library
>      // and an application to differ within that range.
>      #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1010))
>          #define wxGXX_EFFECTIVE_ABI_VERSION 1002
>      #else
>          #define wxGXX_EFFECTIVE_ABI_VERSION __GXX_ABI_VERSION
> #endif
>
> so wouldn't have complained like in bnc#1074040.  GCC 7 introduces version
> 11 which I bet also doesn't affect wxWidgets...  quoting the docs:
>
> Version 11, which first appeared in G++ 7, corrects the mangling of
> sizeof... expressions and operator names.  For multiple entities with
> the same name within a function, that are declared in different scopes,
> the mangling now changes starting with the twelfth occurrence.  It also
> implies @option{-fnew-inheriting-ctors}.
>
> Just patch this insanity out ...
>
> Richard.
Seems I was panicking for no reason, audacity built with gcc7 in
Leap:42.3 works fine with gcc5 built wxWidgets-3_0-nostl.
Thanks all
Dave
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]