runtime: fix over-eager SPWRITE check

[rsc]

x/crypto/blake2s/blake2s_386.s masks and writes to SP during function execution.
This is not allowed by the Go ABI. All SP modifications on goroutine stacks must be constant additions or subtractions, or else the garbage collector cannot unwind the stack from that location.

Code used to get away with this due to cooperative scheduling, but now that we scan stacks preemptively, it is especially important that functions not do this.

New code in Go 1.17 will stop stack traces in such functions, which will make programs crash more loudly. But they are still broken in earlier versions and may just cause silent memory corruption instead of loud crashes.

hashBlocksSSE2 and hashBlocksSSSE3 should leave SP alone.

Edit: also blake2b, salsa20/salsa.

[rsc]

This is true of blake2s_amd64.s as well - the SP write is hidden in a macro.

[rsc]

Also blake2b. Also salsa20.

[gopherbot]

Change https://golang.org/cl/292052 mentions this issue: blake2s: fix 386 assembly not to smash SP

[gopherbot]

Change https://golang.org/cl/292051 mentions this issue: blake2b: fix amd64 assembly not to smash SP

[gopherbot]

Change https://golang.org/cl/292050 mentions this issue: salsa20/salsa: fix amd64 assembly not to smash SP

[gopherbot]

Change https://golang.org/cl/292049 mentions this issue: blake2s: fix amd64 assembly not to smash SP

[zx2c4]

This also applies to windows/svc/sys_*.s in x/sys.

[rsc]

@zx2c4 I don't believe that's true, since servicemain appears to run on a Windows stack called from Windows - it's not a Go function subject to the Go ABI rules.

[FiloSottile]

"go vet" has a checker that runs on the TryBots against clobbering the frame pointer. It's caught real examples for me before (FiloSottile/edwards25519#11). Could we add one for this, too, so we don't reintroduce the issue later?

[zx2c4]

go build -asmflags=all=-v will show a splat for it at build time. I agree go vet sounds like a nice place for this.

A few implementation strategies:

1. Assemble with -v, and scrape the output. :(
2. Parse the assembly file with regexes, like x/tools/go/analysis/passes/framepointer/framepointer.go does. :(
3. Look at the SPWRITE bit in pclntbl after building.
4. Somehow reuse the assembler code from the compiler in the analyzer to re-run the pass that the assembler is doing.

3 seems most appealing, but I don't know if vet can look at post-build artifacts or how that works. I've never looked at this code before.

[zx2c4]

https://go-review.googlesource.com/c/tools/+/292529 is strategy (2). Kind of meh, but perhaps this is just how analyzer works.

[gopherbot]

Change https://golang.org/cl/292529 mentions this issue: go/analysis: add SPWRITE verifier

[zx2c4]

It apparently works too!

zx2c4@thinkpad ~/Projects/golang-dev/crypto $ GOARCH=386 ~/Projects/golang-dev/go/bin/go vet -stackpointer ./...
# golang.org/x/crypto/blake2s
blake2s/blake2s_386.s:304:1: stack pointer is manually modified
blake2s/blake2s_386.s:358:1: stack pointer is manually modified
blake2s/blake2s_386.s:373:1: stack pointer is manually modified
blake2s/blake2s_386.s:434:1: stack pointer is manually modified
zx2c4@thinkpad ~/Projects/golang-dev/crypto $ GOARCH=amd64 ~/Projects/golang-dev/go/bin/go vet -stackpointer ./...
# golang.org/x/crypto/blake2s
blake2s/blake2s_amd64.s:423:1: stack pointer is manually modified
# golang.org/x/crypto/blake2b
blake2b/blake2bAVX2_amd64.s:288:1: stack pointer is manually modified
blake2b/blake2bAVX2_amd64.s:369:1: stack pointer is manually modified
blake2b/blake2bAVX2_amd64.s:591:1: stack pointer is manually modified
blake2b/blake2bAVX2_amd64.s:749:1: stack pointer is manually modified
blake2b/blake2b_amd64.s:125:1: stack pointer is manually modified
blake2b/blake2b_amd64.s:280:1: stack pointer is manually modified
# golang.org/x/crypto/salsa20/salsa
salsa20/salsa/salsa20_amd64.s:23:1: stack pointer is manually modified
salsa20/salsa/salsa20_amd64.s:877:1: stack pointer is manually modified

[FiloSottile]

Awesome, I'd support turning this on by default in "go vet" like #43014

[zx2c4]

I've got that code written, but it looks like it needs to be in x/tools first before I can vendor it and push a CL.

[gopherbot]

Change https://golang.org/cl/292569 mentions this issue: cmd/vet: add stackpointer analysis run

[gopherbot]

Change https://golang.org/cl/317669 mentions this issue: runtime: fix handling of SPWRITE functions in traceback

[rsc]

On further analysis it appears that the old x/crypto code was dodgy but technically okay, in the sense that the runtime can work around it reasonably well. I have relaxed the check in the runtime in CL 317669, so now there is no need for a vet check nor to go looking for other dodgy-but-technically-okay assembly code in the wild.

CL 317669 will close this issue when submitted.