This change detects BMI2 usability as an additional condition
to examine the usability of AVX2 version algorithm, fixes
the crash on the platfrom which supports AVX2 but not support BMI2.
Change-Id: I5438d4ec84265c79a51c1439265a33b1be04878a
Reviewed-on: https://go-review.googlesource.com/34852
Reviewed-by: Adam Langley <agl@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
ResponderID is unmarshalled into either ResponderName or
ResponderKeyHash depending on which one is present.
Fixesgolang/go#14971.
Change-Id: I5ba602753d81835da531321e94898408395068dd
Reviewed-on: https://go-review.googlesource.com/34380
Reviewed-by: Adam Langley <agl@golang.org>
Currently, autocert.Manager always generates EC-based certificates.
This change adds an optional field forcing the Manager to use RSA
instead.
An alternative idea, a "double" certificate, where the Manager
presents either RSA or EC certificate based on client's compatibility,
doesn't seem to be worth the implementation time given the constant
increase in Elliptic Curve cryptography.
Fixesgolang/go#17744
Change-Id: Idc68abfc698bcff4aad99715baefc06f8fae50ad
Reviewed-on: https://go-review.googlesource.com/34570
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
A net.IP may be represented by both by a 4 as well as a 16 byte long
byte slice. Because of this, it is not safe to compare IP addresses
using bytes.Equal as the same IP address using a different internal
representation will produce mismatches.
Change-Id: I0d228771cf363ccfb9532f8bc2a2fc8eff61f6e9
Reviewed-on: https://go-review.googlesource.com/34450
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Allows user to set the hash function to use in the OCSP response
when using ocsp.CreateResponse instead of hard-coding the use of
SHA-1. The field IssuerHash is added to the ocsp.Response struct
to set which hash to use. If none is provided CreateResponse falls
back to SHA1. ParseResponse also attempts to populate this field
and will fail if a unsupported hash algorithm is provided.
Change-Id: I3905b1706f347387724e57c33cb82a3b46ffcdf9
Reviewed-on: https://go-review.googlesource.com/32214
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
911fafb28f made MakeRaw match C's behaviour. This included clearing the
OPOST flag, which means that one now needs to write \r\n for a newline,
otherwise the cursor doesn't move back to the beginning and the terminal
prints a staircase.
(Dear god, we're still emulating line printers.)
This change causes the terminal package to do the required
transformation.
Fixesgolang/go#17364.
Change-Id: Ida15d3cf701a21eaa59161ab61b3ed4dee2ded46
Reviewed-on: https://go-review.googlesource.com/33902
Reviewed-by: Brad Fitzpatrick <bradfitz@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>
Rather than change the value of R13 during the execution, keep R13 fixed
(after the initial prelude) and always use offsets from it.
This should help the runtime figure out what's going on if, say, a
signal should occur while running this code.
I've also trimmed the set of saved registers since Go doesn't require
the callee to maintain anything except R10 and R13.
Change-Id: Ifbeca73c1d964cc43bb7f8c20c61066f22fd562d
Reviewed-on: https://go-review.googlesource.com/31717
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
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>
5f31782cfb added build constraints to
disable assembly for Go 1.6 but didn't add the needed tags to the ARM
files. Also, it's not clear that was needed as the error given in
golang/go#17424 only complains about the chacha20poly1305 package.
This change reenables the assembly for Go 1.6 in the poly1305 package.
Tested with 1.6.3 and 1.5.4.
Fixesgolang/go#17512.
Change-Id: I81b41f8810437ea327b415542402cd8ff5c8a390
Reviewed-on: https://go-review.googlesource.com/31492
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Up till now, sum_arm.s was working only because of luck. It was written
assuming that it had stack space below the current stack pointer, but Go
decrements the stack pointer in the function prelude, so it was just
writing off the end of the stack.
This change fixes the stack manipulation so that it only writes within
the bounds.
Fixesgolang/go#17499.
Change-Id: I1951b3344c21f6bd6ade79da8b96dd1bb68180db
Reviewed-on: https://go-review.googlesource.com/31443
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The names of the constant values were previously not scoped to the
package and |andMask| could collide with the variable of the same name
in the AES-GCM assembly.
Change-Id: I9387a6cace71a585ad2fe2afcc8436d44bde0917
Reviewed-on: https://go-review.googlesource.com/31265
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The ARM assembly doesn't work for NaCl on ARM because it doesn't meet
the required rules. This change disables it on ARM and also fixes the
issue that the build constraints in sum_arm.s would be ignored because
they came after the #include.
Change-Id: I6cb3815ec62ac4686a6e72f405af104293586bb6
Reviewed-on: https://go-review.googlesource.com/31264
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>