Add -mshstk to the C/C++ Compiler Hardening Guide?

[david-a-wheeler]

I think we should consider adding -mshstk to the C/C++ Compiling Hardening guide.

It is recommended in Use compiler flags for stack protection in GCC and Clang, where it notes: "This form of protection splits the stack into two distinct areas, storing precious variables and user variables in non-contiguous memory areas. The goal is to make it more difficult to smash one of the stacks from the other. This process occurs in hardware (e.g., x86_64 shadow stack) or in software such as LLVM's SafeStack."

This -mshstk flag is supported in clang and GCC. GCC 9.1.0 documents it as follows: "The -mshstk option enables shadow stack built-in functions from x86 Control-flow Enforcement Technology (CET)."

I'm not recommending adding Clang's SafeStack, which it adds through this flag: -fsanitize=safe-stack. This StackOverflow answer suggests there are problems with that with shared libraries. That may be incorrect (please let me know!), but until we're confident that problems are rare, I'm not confident in recommending it.

[thesamesam]

The distinction between -fcf-protection and -mshstk is poorly covered in compiler documentation which doesn't help.

For our Hardened profiles in Gentoo, we pass -fcf-protection at least.

[thomasnyman]

The built-in functions are, in my opinion, only needed if you are building a shadow stack support into C standard libraries or other code which may be doing unconventional management of the stack.

I would suggest we cover -mshstk in the Considered Compiler Options table (for completeness) but recommend -fcf-protection.

[nlewycky]

I'm not recommending adding Clang's SafeStack, which it adds through this flag: -fsanitize=safe-stack. This StackOverflow answer suggests there are problems with that with shared libraries. That may be incorrect (please let me know!), but until we're confident that problems are rare, I'm not confident in recommending it.

“SafeStack supports linking statically modules that are compiled with and without SafeStack. An executable compiled with SafeStack can load dynamic libraries that are not compiled with SafeStack. At the moment, compiling dynamic libraries with SafeStack is not supported.”

• https://clang.llvm.org/docs/SafeStack.html#known-compatibility-limitations

Just to provide a more authoritative reference than a StackOverflow post.

FWIW, so far as I know the problem isn't hard to fix, there simply hasn't been any interest. To fix, the .so needs to have a .init function that checks whether there's a shadow stack present and mmap's one if not, and saves the pointer in the __safestack_unsafe_stack_ptr thread-local variable.