Are there any stacks worth protecting? Without knowing all the gory details, I would imagine there's some amount of bootstrapping and interfacing with the OS using "unsafe" stacks, for lack of a better term.

I don't think this question makes sense. Your understanding of stacks may be a bit off. Or maybe I'm just not understanding.

Is there a way to include stack protectors?

I'm sure it would be technically feasible to add this feature to the Go compiler. But from a user perspective, no, not currently.

Should any protection be included by default?
If stack protectors aren't necessary, why aren't they?

Go is considered memory safe for the most part. That may be a bit debatable since data races do exist, and it is possible to achieve arbitrary code execution, but it's really hard to exploit in practice. I've yet to see or hear of anyone exploiting a Go application in this way.

So my opinion is that stack protectors aren't necessary and should not be included by default.

If the vendor of one of these tools is convinced that Go binaries are safe, and would like to exclude all Go binaries from this sort of scan, is there a way to do that?

You could probably use rsc/goversion to determine if a binary is a Go binary and exclude it.

Stack checking as implemented by -fstack-protector is designed to detect buffer overflows for buffers located on the stack. This concept is not particularly meaningful for Go, as in Go there is no pointer arithmetic and all slice and array bounds are checked.

That said, it is possible, though not simple, to set an unsafe.Pointer to the address of a variable that does not escape, and then to modify the value of that unsafe.Pointer to point to a different section of the stack, and then modify the stack in that way. However, even this kind of error is very unlikely to be caught by a stack cookie of the form used by -fstack-protector. The -fstack-protector option is designed for erroneous buffer overruns, and Go code is not written in a way that creates buffer overruns, and the only way to do it in Go is to very explicitly use unsafe.Pointer to write C style memory accesses, which nobody ever does.

So, in short, in my opinion, -fstack-protector has no use for Go.

To address your specific points.

Are there any stacks worth protecting? Without knowing all the gory details, I would imagine there's some amount of bootstrapping and interfacing with the OS using "unsafe" stacks, for lack of a better term.

No, there isn't. There is some assembly code that could in principle use stacks in an unsafe way, but -fstack-protector, which does not apply to assembly, wouldn't help there anyhow.

Is there a way to include stack protectors?

Yes, we could add this to the compiler, but we shouldn't.

Should any protection be included by default?

Not beyond the existing protection, no.

If stack protectors aren't necessary, why aren't they?

See above.

If the vendor of one of these tools is convinced that Go binaries are safe, and would like to exclude all Go binaries from this sort of scan, is there a way to do that?

Sure, just look at the symbol table. Go symbol names have periods in them, C symbol names do not.

I'll mention that Go does, of course, have an interface for calling C code, and it would be perfectly reasonable to compile that C code with -fstack-protector. That is a choice that we leave up to the programmer, and the cgo documentation (https://golang.org/cmd/cgo) explains how to set flags to use for compiling the C code used by cgo.

I'm going to close this issue because I don't think there is anything that the Go project should do here. Please comment if you disagree.