This implementation utilizes the same registers found in the reference
implementation, aiming to produce a minimal semantic diff between the
Avo-generated output and the original hand-written assembly.
To verify the Avo implementation, the reference and Avo-generated
assembly files are fed to `go tool asm`, capturing the debug output into
corresponding temp files. The debug output contains supplementary
metadata (line numbers, instruction offsets, and source file references)
that must be removed in order to obtain a semantic diff of the two
files. This is accomplished via a small utility script written in awk.
Commands used to verify Avo output:
GOROOT=$(go env GOROOT)
ASM_PATH="blake2s/blake2s_amd64.s"
REFERENCE="b2d3a6a4b4d36521cd7f653879cf6981e7c5c340"
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
<(git cat-file -p "$REFERENCE:$ASM_PATH") \
> /tmp/reference.s
go tool asm -o /dev/null -I "$GOROOT"/src/runtime -debug \
"$ASM_PATH" \
> /tmp/avo.s
normalize(){
awk '{
$1=$2=$3="";
print substr($0,4)
}'
}
diff <(normalize < /tmp/reference.s) <(normalize < /tmp/avo.s)
Change-Id: Ica8bf9f0b42dc93714aa54e783fa74ed19e6b9f4
Reviewed-on: https://go-review.googlesource.com/c/crypto/+/601216
Reviewed-by: Roland Shoemaker <roland@golang.org>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The marshal method allows the hash's internal state to be serialized and
unmarshaled at a later time, without having the re-write the entire stream
of data that was already written to the hash.
Fixesgolang/go#24548
Change-Id: I82358c34181fc815f85d5d1509fb2fe0e62e40bd
Reviewed-on: https://go-review.googlesource.com/103241
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Fix the following format string issue reported by go vet:
blake2s_test.go:188: Fatalf format %v reads arg #3, but call has only 2 args
Change-Id: I689eadb7d7310ae93acd8a8419755f2724ff41dd
Reviewed-on: https://go-review.googlesource.com/75978
Reviewed-by: Filippo Valsorda <hi@filippo.io>
Although a 128-bit digest provides little collision resistance it can be
used as a MAC, as found in the WireGuard protocol.
Change-Id: I06ee528e5711035da8f1b254c223a6fda8890abf
Reviewed-on: https://go-review.googlesource.com/39370
Reviewed-by: Adam Langley <agl@golang.org>
Having a trailing comma before a space doesn't mean that the next option
will be ANDed rather than ORed. This worked with the standard toolchain
because the filenames prevented the incorrect build constraints for
other platforms from being acted on.
Change-Id: Iaee5b60a7496166f23fc36319abe07c7a7ec04e5
Reviewed-on: https://go-review.googlesource.com/32311
Run-TryBot: Adam Langley <agl@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
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>
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>
Michael Pratt
Xiaolin Zhao
Roland Shoemaker
Garrett Bodley
Filippo Valsorda
Dmitri Shuralyov
Tobias Klauser
Russ Cox
Tamir Duberstein
Katie Hockman
Udalov Max
Igor Zhilianin
Andreas Auernhammer
ValarDragon
Mathias Hall-Andersen
Adam Langley
Austin Clements