cmd/asm,cmd/compile: add support for shadow stack

[loqs]

X86_64 CPUs can support Shadow Stack (SHSTK). SHSTK helps to mitigate against Return Oriented Programming (ROP) expoits, as well as others that target a process's call stack.

On linux binaries need to be marked with a note section .note.gnu.property marking support for GNU_PROPERTY_X86_FEATURE_1_SHSTK in order to support SHSTK. I believe Windows also supports SHSTK but have no knowledge of how.

Go should ideally support SHSTK on Linux and add the note section showing it does support it. Provided Go does not change the stack I believe it should be sufficient for Go to mark the binaries it generates.

#66054 is for the other half of Control-flow Enforcement Technology (CET).

[cherrymui]

I'm not sure it is simple. Go runtime switches goroutines by switching stacks (changing the value of SP). When the stack switches, the shadow stack may also need to be switched. If we want to support this, we may need to do something similar to what C setjmp/longjmp does.

[loqs]

@hjl-tools is this of interest to you or you can suggest someone who may be interested in it?

[hjl-tools]

Just compile the run-time library with -fcf-protection should enable shadow stack if there are no custom context switching functions.

[ianlancetaylor]

@hjl-tools In this case the runtime is written in Go, not C. There is no -fcf-protection option. There are custom context switching functions, written in assembler.

[bjorndm]

SHSTK is a palliative for C and C++ which allow ROP due to their deficient design and allowance for undefined behavior.

If one doesn't use unsafe, then ROP should not be possible in Go. This might negatively affect the performance of Go programs and is another example of how non C programming languages have to pay "C taxes" as it were. This should certainly remain optional.

[cherrymui]

This should certainly remain optional.

Sure. It should be optional (if we do this).