Use Windows SecurityCookie instead of libssp (or mingw crt)?

[Andarwinux]

Hi,
Currently, when using -fstack-protector with mingw clang, it will link to libssp and libssp_nonshared, even though SSP is already implemented in mingw crt. llvm-mingw seems to generate empty .a files to fix this, but toolchains built in other ways do not do this, and results in stack protector not being ready to use out of the box.

Additionally, if set MajorSubsystemVersion to 10, exe will fail to run because mingw does not support SecurityCookie.

I noticed that mingw used to have something related to SecurityCookie, but it was later removed (because it was incomplete ?). Perhaps consider re-add a complete SecurityCookie implementation to allow using SecurityCookie instead of ssp. This way, clang can expose a new option to use SecurityCookie without linking to libssp (because it's new), and it can allow exe compatible with major-subsystem-version=10.

https://bugreports-test.qt.io/projects/QBS/issues/QBS-1724

[mstorsjo]

This results in stack protector not being ready to use out of the box.

Can you clarify this part of the problem statement? As far as I would expect, if linking with the separate libssp from GCC, the only issue is that you may need to ship that DLL along your executable, and that you have duplicate code for dealing with this. Is there a more averse effect than this, too?

[Andarwinux]

Can you clarify this part of the problem statement? As far as I would expect, if linking with the separate libssp from GCC, the only issue is that you may need to ship that DLL along your executable, and that you have duplicate code for dealing with this. Is there a more averse effect than this, too?

Since libssp.a and libssp_nonshared.a do not exist in sysroot, lld will get an error. Although I only need to manually create an empty libssp.a to solve the problem.

[mstorsjo]

Ah, I see. Yes that's somewhat inelegant indeed.

[alvinhochun]

IIRC, SecurityCookie in the load config directory is expected to point to the __security_cookie used for /GS in MSVC, which is functionally equivalent to the __stack_chk_guard in ssp.

https://github.com/mingw-w64/mingw-w64/blob/eea8f577e02a08d90e7a7c1c60251e7760f6a880/mingw-w64-crt/crt/loadcfg.S#L78-L82
https://github.com/mingw-w64/mingw-w64/blob/eea8f577e02a08d90e7a7c1c60251e7760f6a880/mingw-w64-crt/ssp/stack_chk_guard.c#L11

In the past I mentioned in passing that it may be a good idea to consider pointing SecurityCookie to __stack_chk_guard, perhaps we should do it. Doing it should also mean that in theory the Windows loader will set __stack_chk_guard to a random value for us.

I guess the question is, should it be set only if ssp is enabled when the CRT or the user code is compiled with ssp, or should it be set unconditionally?

Also I don't know if we should make __security_cookie an alias for __stack_chk_guard (I suppose that is only useful when linking msvc static libraries which is not supported anyway, and we'd still be missing the out-of-line __security_check_cookie function, so probably not...)

[Andarwinux]

In the past I mentioned in passing that it may be a good idea to consider pointing SecurityCookie to __stack_chk_guard, perhaps we should do it. Doing it should also mean that in theory the Windows loader will set __stack_chk_guard to a random value for us.

I guess the question is, should it be set only if ssp is enabled when the CRT or the user code is compiled with ssp, or should it be set unconditionally?

I think since only llvm supports LoadConfig, we could add a --enable-securitycookie option similar to --enable-cfguard, and set it unconditionally once configured. This way, once the CRT is built with --enable-securitycookie, the linked exe will get a non-zero SecurityCookie to be compatible with major-subsystem-version=10, and even SSP users will get the random number from the Windows loader instead of the CRT (I'm not sure if there is a performance or quality difference, but it sounds like it would simplify the code).