Hi

Revisiting this, I've hit [1] during the ongoing toolchain upgrade, so as I read it since we have

-Wp,-D_FORTIFY_SOURCE=2

in the cflags we'll also need -fstack-protector in the ldflags, and gcc should take care of adding -lssp -lssp_nonshared automatically (trying this out here [2]).

Any comments/objections to adding -fstack-protector to the ldflags (or perhaps even -fstack-protector-strong)?

Thanks Sandro

[1] https://sourceforge.net/p/mingw-w64/bugs/818/ [2] https://copr.fedorainfracloud.org/coprs/smani/mingw-7.0.0/builds/

On 22.05.20 23:25, Yaakov Selkowitz wrote:

On Fri, 2020-05-22 at 22:25 +0200, Sandro Mani wrote:

...

While looking through the mingw rpm macros, I noticed that we currently have

mingw{32,64}_cflags = -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4

whereas for native packages we have

optflags = -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection

As I read the gcc docs and [1] (by no means an expert in the matter), I'd say the following might also make sense for the mingw cflags:

• -Werror=format-security

Probably a safe addition.

...

• -Wp,-D_GLIBCXX_ASSERTIONS

Not sure about this one.

...

• -fstack-protector-strong

Careful with this one, as it then requires linking with -lssp -lssp_nonshared. gcc is supposed to handle that automatically, but anything that tries to be too smart might miss this.

...

• -fasynchronous-unwind-tables
• -fstack-clash-protection

Have binaries resulting from these been tried?

...

I've got a mass tool chain update scheduled before the F33 mass rebuild, I could in the same go also update the flags. Opinions?