A couple of processing errors crept in over time. Caught by the tests
in the next change.
Change-Id: I0caa478d3321cb8a1da1e61ddde16ba8db91eb35
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44745
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The config file is only needed if interacting with an ACVP server.
Invocations that just want to process input from a file don't need it.
By moving this chunk of code down, the config isn't loaded until
after handling JSON inputs and just can be ignore if not needed.
Change-Id: Ibce334f63ddf8df34cf2917b923db20b3aaa735f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44744
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
This is so we can build the tool in Chromium and run benchmarks using
Chromium's build config.
Change-Id: I16b4d99a923cd61f338ba488cb0abdfce3c0a3d2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44724
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This involves adding a new function |DH_compute_key_hashed| that
combines the FFDH with the output hashing inside the FIPS module. This
new function uses the padded FFDH output, as newly specified in SP
800-56Ar3.
Change-Id: Iafcb7e276f16d39bf7d25d3b2f163b5cd6f67883
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44504
Reviewed-by: David Benjamin <davidben@google.com>
As of
https://chromium-review.googlesource.com/c/chromium/tools/build/+/2586225,
we no longer test on Yasm. Yasm hasn't seen a release for over six years
now and is missing support for newer x86 instructions.
This removes the remnants of support for Yasm on the CI. It also removes
the Yasm support we patched into x86nasm.pl, which removes a now
unnecessary divergence from upstream.
Update-Note: If a x86 Windows asm build breaks, switch from Yasm to
NASM. We're also no longer testing NASM on x86_64 Windows, but there
wasn't any patch to revert.
Change-Id: I016bad8757fcc13240db9f56dd622be518e649d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44564
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This imports d741debb320bf54e8575d35603a44d4eb40fa1f9 from upstream.
We've been managing the shared libraries already because our
arm-xlate.pl automatically adds .hidden to .extern lines, but nice to
reduce the diff. (This does result in some duplicate .hidden lines in
the generated output, but we still want the arm-xlate.pl patch to
automatically hide .globl.)
Removing .comm lines does change the generated output, but having each
asm file define its own copy of OPENSSL_armcap_P as a common symbol
always seemed odd. I recall some weird issue where the armv4.pl files
subtly rely on it for iOS's strange .indirect_symbol machinery. (Not
actually because iOS wants a common symbol but because arm-xlate.pl
repurposes .comm to trigger .indirect_symbol.) Fortunately, aarch64 is
much better about PC-relative addressing, so it should be a no-op.
The .comm lines have also previously caused weird issues
(https://boringssl-review.googlesource.com/c/boringssl/+/32324), so
it's generally nice to get rid of them.
Update-Note: If aarch64 builds get some weird error about relocations,
it's this CL's fault.
Change-Id: I763ffa6cda750d99694ded8a5b68d7b27b09cfc9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44464
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This change tweaks our ACVP config to better match what BoringCrypto
has previously tested with CAVP.
Change-Id: I7d7ce5153a3eb7355ae1516f06ff591ee2c9d902
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44385
Reviewed-by: David Benjamin <davidben@google.com>
The docs at os/signal.Notify warn about this signal delivery loss bug at
https://golang.org/pkg/os/signal/#Notify, which says:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Discovered by one of Orijtech, Inc's internal static
analyzers that will eventually be donated to the Go project, and will
then be included when one runs:
go test
Change-Id: I5713f7087a195ac706240d32b53d2e4855d93a1c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44264
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I08cc198f326f02b3f38234b938208ea49a13fab6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/44164
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The ACVP MCT tests involve a double loop where the inner loop iterates
1000 (AES) or 10000 (3DES) times. This change moves that inner loop
into the subprocess. This significantly reduces the amount of IPC
traffic at the cost of making the subprocesses more complex. The traffic
volume is unimportant when talking over a local pipe, but it's
significant when channels like serial links are used.
Change-Id: Ia9d51335f06b743791f7885d366c8fd2f0f7eaf6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43844
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Chromium's VS toolchains now maintain JSON files with the expected
environment, so we don't need to pull in gyp to figure out the batch
file to run. This drops a long obsolete dependency and will make it
possible to handle other VS architectures. (gyp internally only handled
x86 and x64.)
Also trim away the logic in vs_toolchain.py to account for
non-depot_tools toolchains. Unlike Chromium, we don't use these scripts
outside of CI/CQ.
Change-Id: I2c9fddac52eef7b4895731d78c637fdcf9c85033
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43504
Reviewed-by: Adam Langley <agl@google.com>
Use empty() over size() == 0, and don't export the IterateAES*
functions. (They return private types.)
Change-Id: I8a8f33a64e28cc2eab789563c6ba91afa6df87f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43544
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
A recent change broke this but I didn't notice. (Which suggests that the
test isn't very useful, which is true, but I'm not ready to pull the
trigger on deleting it just yet.)
Change-Id: If120a553c095fa0be9f8e85fc05ee996a486621f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43484
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CopyDiaDllTo is no longer needed after
9f7781171e.
As a bonus, this makes the script much easier to use outside of the
bots.
Change-Id: Ib59b7e6ff9276b860032134ad7eaa006492e76b9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43464
Reviewed-by: Adam Langley <agl@google.com>
(There's going to be more and it was getting too big.)
Change-Id: I16a49f77975697bb5a04f2adfd465b09c2a09ef3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43404
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This change adds a config parameter PrivateKeyFile (to replace
PrivateKeyDERFile, although that still exists) because taking PKCS#1 DER
is a little odd for people. Also probe for PEM/DER and PKCS#1/8
automatically to try and work with whatever private key the user has.
Change-Id: I0f4efcd79528cfb26f791e9ee8c5141fc6a93723
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43344
Reviewed-by: David Benjamin <davidben@google.com>
Since we have support for reading vectors from files, this change adds
support for saving them. There's no support for uploading the saved
vectors, rather it's just for quicker debugging since the NIST server is
taking over a minute to produce vectors at the moment and that's a
little frustrating to iterate with.
Change-Id: I5da8a084eb06b81aefa838b4e7ad8d529d1d31a6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43144
Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I7636736752ac371fc8d86fbc6bf81ca797ac5092
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43127
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Due to a typo, if an unknown function was requested it was previously
ignored.
Change-Id: Id815c4b7e80d1452034b10bf9c7beb80a5ac3ed2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43125
Reviewed-by: David Benjamin <davidben@google.com>
Sending empty spans tripped up the code because it never considered
the iovec to have been sent. Instead, filter out empty iovecs in the
first place.
Change-Id: I48ea2a887ca64c73051346f3096735c30507525a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/43124
Commit-Queue: Adam Langley <alangley@gmail.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
A direct connections to the ACVP servers may not always be available. In
some cases, NVLAP labs will interact with the servers and send JSON back
and forth as files. This change supports both dumping the capabilities
JSON (which a lab will need in order to send to the server) and
processing vectors from a file on disk.
Change-Id: Iefa0c411b9a19808b5a7eb431169068d1c2ea966
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42704
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Most of the output formats manually call sorted(), which I've retained
since they often concatenate multiple file lists, but the JSON output
dumps the object to JSON directly. Sort everything earlier so the JSON
output is deterministic.
Change-Id: I9940f4ef3eb85a3fd7337058f5d7ce0ce6e28b9d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42544
Reviewed-by: Adam Langley <agl@google.com>
I tried to save space and use 32-bit GOT offsets since a GOT > 2GiB is
crazy. However, Clang's linker emits 64-bit relocations even for .long,
thus the four bytes following each offset get stomped. It mostly works
because the relocations are applied in order, thus the following
relocation gets stomped but is then processed and fixed. But there's
four bytes of stomp at the end which hits the module integrity hash,
which is fatal.
This could be fixed by adding four bytes of padding after the list of
offsets, but that's piling a hack on a hack. So this change just
switches to 64-bit offsets.
Change-Id: I227eec67c481d93a414fbed19aa99471f9df0f0e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42484
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Large memory models on x86-64 allow the code/data of a shared object /
executable to be larger than 2GiB. This is typically impossible because
x86-64 code frequently uses int32 offsets from RIP.
Consider the following program:
int getpid();
int main() {
return getpid();
}
This is turned into the following assembly under a large memory model:
.L0$pb:
leaq .L0$pb(%rip), %rax
movabsq $_GLOBAL_OFFSET_TABLE_-.L0$pb, %rcx
addq %rax, %rcx
movabsq $getpid@GOT, %rdx
xorl %eax, %eax
jmpq *(%rcx,%rdx) # TAILCALL
And, with relocations:
0: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 0 <main>
7: 48 b9 00 00 00 00 00 movabs $0x0,%rcx
e: 00 00 00
9: R_X86_64_GOTPC64 _GLOBAL_OFFSET_TABLE_+0x9
11: 48 01 c1 add %rax,%rcx
14: 48 ba 00 00 00 00 00 movabs $0x0,%rdx
1b: 00 00 00
16: R_X86_64_GOT64 getpid
1e: 31 c0 xor %eax,%eax
20: ff 24 11 jmpq *(%rcx,%rdx,1)
We can see that, in the large memory model, function calls involve
loading the address of _GLOBAL_OFFSET_TABLE_ (using `movabs`, which
takes a 64-bit immediate) and then indexing into it. Both cause
relocations.
If we link the binary and disassemble we get:
0000000000001120 <main>:
1120: 48 8d 05 f9 ff ff ff lea -0x7(%rip),%rax # 1120 <main>
1127: 48 b9 e0 2e 00 00 00 movabs $0x2ee0,%rcx
112e: 00 00 00
1131: 48 01 c1 add %rax,%rcx
1134: 48 ba d8 ff ff ff ff movabs $0xffffffffffffffd8,%rdx
113b: ff ff ff
113e: 31 c0 xor %eax,%eax
1140: ff 24 11 jmpq *(%rcx,%rdx,1)
Thus the _GLOBAL_OFFSET_TABLE_ symbol is at 0x1120+0x2ee0 = 0x4000.
That's the address of the .got.plt section. But the offset “into” the
table is -0x40, putting it at 0x3fd8, in .got:
Idx Name Size VMA LMA File off Algn
18 .got 00000030 0000000000003fd0 0000000000003fd0 00002fd0 2**3
19 .got.plt 00000018 0000000000004000 0000000000004000 00003000 2**3
And, indeed, there's a dynamic relocation to setup that address:
OFFSET TYPE VALUE
0000000000003fd8 R_X86_64_GLOB_DAT getpid@GLIBC_2.2.5
Accessing data or BSS works the same: the address of the variable is
stored relative to _GLOBAL_OFFSET_TABLE_.
This is a bit of a pain because we want to delocate the module into a
single .text segment so that it moves through linking unaltered. If we
took the obvious path and built our own offset table then it would need
to contain absolute addresses, but they are only available at runtime
and .text segments aren't supposed to be run-time patched. (That's why
.rela.dyn is a separate segment.) If we use a different segment then
we have the same problem as with the original offset table: the offset
to the segment is unknown when compiling the module.
Trying to pattern match this two-step lookup to do extensive rewriting
seems fragile: I'm sure the compilers will move things around and
interleave other work in time, if they don't already.
So, in order to handle movabs trying to load _GLOBAL_OFFSET_TABLE_ we
define a symbol in the same segment, but outside of the hashed region of
the module, that contains the offset from that position to
_GLOBAL_OFFSET_TABLE_:
.boringssl_got_delta:
.quad _GLOBAL_OFFSET_TABLE_-.boringssl_got_delta
Then a movabs of $_GLOBAL_OFFSET_TABLE_-.Lfoo turns into:
movq .boringssl_got_delta(%rip), %destreg
addq $.boringssl_got_delta-.Lfoo, %destreg
This works because it's calculating
_GLOBAL_OFFSET_TABLE_ - got_delta + (got_delta - .Lfoo)
When that value is added to .Lfoo, as the original code will do, the
correct address results. Also it doesn't need an extra register because
we know that 32-bit offsets are sufficient for offsets within the
module.
As for the offsets within the offset table, we have to load them from
locations outside of the hashed part of the module to get the
relocations out of the way. Again, no extra registers are needed.
Change-Id: I87b19a2f8886bd9f7ac538fd55754e526bcf3097
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42324
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
gRPC are currently importing generate_build_files.py, injecting a
custom printer, and running into problems with the symlinks they set up
to make this work, as well as needing to delete duplicate generated
files.
53a5ad34c0/src/boringssl/gen_build_yaml.py (L130)https://boringssl-review.googlesource.com/c/boringssl/+/42164
Rather than layer on more hacks, add a JSON output to
generate_build_files.py. This outputs a sources.json file that folks
with especially custom builds can consume. (Looks like gRPC converts to
some home-grown YAML format which I imagine is further processed by some
other generator?) We can then add it to master-with-bazel's output.
Change-Id: I82b4ea0647386ca6c76a977f057b9962f40d41c8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42204
Reviewed-by: Adam Langley <agl@google.com>
This fixes a couple issues:
- Which libraries to use should be based on WIN32, not MSVC.
- Windows libraries can be specified by #pragma comment lines in the
source or by build dependencies. We specified #pragma lines in
source, but also have build dependencies in crypto_test, etc. The
latter was missing bssl.
The comment line should be sufficient, but being explicit is useful,
so fill in the missing one. This should help building with MINGW,
which is missing support for the usual Windows pragma.
Change-Id: Ide9328c7dd306738ebbb0792e47da96948fe12f4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/42105
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Adam Langley
David Benjamin
Emmanuel T Odeke
Adam Langley
Daniel McArdle