This adds use* flags for all arches so a common test can observe what
implementations are supported and test all supported implementations.
Change-Id: I0497b91294ed99309074ac4614ac996e006630c5
Reviewed-on: https://go-review.googlesource.com/31714
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
This adds use* flags for all arches so a common test can observe what
implementations are supported and test all supported implementations.
Change-Id: Icc9c3c1d15626e95f0446493b7fa3159bbe9567d
Reviewed-on: https://go-review.googlesource.com/31712
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
Now that the frame sizes of these functions are correct, the compiler
is detecting that they overflow the NOSPLIT stack. They don't need to
be NOSPLIT, so remove that flag.
This fixes the 1.7 build. The build is not broken at tip because the
stack guard is larger.
Change-Id: Ie32779c819f63b27ec0a77a44b7d20ee2d550843
Reviewed-on: https://go-review.googlesource.com/31667
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
keccakF1600 manually subtracts 200 from SP, but the generated prologue
already does this and the extra subtraction just means keccakF1600 is
defeating the stack growth check.
Remove the unnecessary SP adjustment.
Change-Id: I9450f6b12489bcd20e9ace30f9dd3066025d3a1a
Reviewed-on: https://go-review.googlesource.com/31653
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
SP offsets were adjusted to fill in the now unused callee save area
using the following Python script:
import sys, re
def adj(m):
delta = int(m.group(1))
if delta >= 408:
delta -= (408 - 352)
return "%d(SP)" % delta
sys.stdout.write(re.sub(r"(\d+)\(SP\)", adj, sys.stdin.read()))
Change-Id: I06675a75d89e5834f804df595868fe4bb8976719
Reviewed-on: https://go-review.googlesource.com/31587
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
The spadj computation in the assembler can't handle SP alignment code
and will just get confused by how it's currently written. Do the
alignment in a scratch register to hide it from the assembler.
Change-Id: I8857f428d96717db29e3a56050f2381bd86807c6
Reviewed-on: https://go-review.googlesource.com/31586
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Adam Langley <agl@golang.org>
Similar to the previous commit, blake2b's assembly routines claim they
have a zero byte frame and manually subtract a frame from the SP,
which can fail to grow the stack when necessary, leading to memory
corruption.
Fix this by using the correct stack frame sizes so the generated stack
growth prologue is correct, and aligning the SP up instead of down.
Change-Id: Ic426338c45c94a2c01d549860c2295a0ee9200be
Reviewed-on: https://go-review.googlesource.com/31585
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
Currently blake2s's assembly routines claim they have a zero byte
frame and manually subtract upwards of 704 bytes from the stack
pointer without cooperating with Go's ABI. As a result, these
functions may not grow the stack when necessary, leading to memory
corruption.
Fix this by using the correct stack frame sizes so the generated stack
growth prologue is correct, and aligning the SP up instead of down.
Change-Id: Ic426338c45c94a2c01d549860c2295a0ee9200bf
Reviewed-on: https://go-review.googlesource.com/31583
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Andreas Auernhammer <aead@mail.de>
Reviewed-by: Minux Ma <minux@golang.org>
The assembly implementations of ladderstep and mul contain register
save prologues that are unnecessary in Go because there are no callee
save registers in the Go ABI. Remove these prologues, update all SP
offsets, and reduce the frame size accordingly.
The SP offsets were updated with:
python -c 'import sys, re; sys.stdout.write(re.sub(r"(\d+)\(SP\)", lambda m: "%d(SP)" % (int(m.group(1))-YYY), sys.stdin.read()))'
where YYY was 64 for mul_amd64.s and 56 for ladderstep_amd64.s.
Change-Id: I728948809f479b1c061cc65167dadad651efab31
Reviewed-on: https://go-review.googlesource.com/31580
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
The curve25519 assembly routines do very non-Go-ABI SP adjustments.
These would thoroughly confuse traceback if it were to fire in one of
these functions (say, because of a signal). Plus, we're about to make
the assembler track SP balance through more operations (which it
should have done all along), and the SP alignment performed by these
functions is going to make the assembler think the SP is out of
balance.
Fix this by eliminating the SP alignment prologue from all four
assembly functions. They don't do any operations that care about SP
alignment, so this is simply unnecessary. square and freeze don't even
use the stack for anything other that saving what were presumably
"callee save" registers in some other ABI, so for these we can
eliminate the stack frame entirely.
Change-Id: If9dbb2fb6800d9cd733daa91f483eb2937e95f0f
Reviewed-on: https://go-review.googlesource.com/31579
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Austin Clements