Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Some local vulnerability scanners attempt to detect binaries that are compiled without stack cookies (e.g.
What should Go's stance be for this sort of thing?
I'm not necessarily for or against a change, but the only discussion I can find is in this old thread which predates the current compiler tool chain, and it would be nicer to have an open or closed issue to reference.
I don't think this question makes sense. Your understanding of stacks may be a bit off. Or maybe I'm just not understanding.
I'm sure it would be technically feasible to add this feature to the Go compiler. But from a user perspective, no, not currently.
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.
You could probably use rsc/goversion to determine if a binary is a Go binary and exclude it.
Stack checking as implemented by
That said, it is possible, though not simple, to set an
So, in short, in my opinion,
To address your specific points.
No, there isn't. There is some assembly code that could in principle use stacks in an unsafe way, but
Yes, we could add this to the compiler, but we shouldn't.
Not beyond the existing protection, no.
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
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.