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?