See the update to ACVP.md for documentation but this now allows running
a test to be broken down into separate commands for each step: fetching,
processing, and uploading.
Change-Id: Id86d1cd0b07fcc9bdc6c665072b511da0832bdde
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55608
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Change-Id: I7fdc63786654f488b2502d6e9c3fb535a2766574
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55605
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Plan is:
1. This CL
2. Update the CI/CQ recipe to be able to run this
3. Update the CI/CQ config to enable this on ELF platforms
4. Do not land, but patch out the .note.GNU-stack annotations and
-Wa,--noexecstack and confirm CI/CQ fails. Based on manual testing
and https://crbug.com/boringssl/292#c4, I anticipate we'll only have
coverage on x86 and x86_64 Linux. Currently, our only Arm Linux
builders are Android, which use the LLVM linker. The LLVM linker
doesn't have this design flaw, so it doesn't need .note.GNU-stack in
the first place. It also sounds like GNU ld will make this moot in a
future release.
5. Remove -Wa,--noexecstack from crypto/CMakeLists.txt and confirm CI/CQ
still passes.
Other than generally wanting to test things, the immediate motivation is
https://boringssl-review.googlesource.com/c/boringssl/+/55626/1/crypto/perlasm/arm-xlate.pl#b246
Bug: 292
Change-Id: Id1c049bfc2b4e8b7e2c8c32ea6456733a588dfe1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55645
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Bug: 542
Change-Id: I5b19405598127a957dd3645c74b9616687c2616b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55447
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
For unknown reasons, ACVP now tests HKDF differently. This change
updates to reflect what the demo server is currently doing.
Bug: None
Change-Id: I64eec2279765b63ab1296ab6b441d2f7c669c616
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55525
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
- Adds the full set of architectures for Linux for which there are
assembly sources listed.
- Adds Android, mostly parallel to Linux.
- Adds the other Apple OSs, parallel to macOS.
Bug: 531
Change-Id: I8bb609d3563b2d151a404f8468b4c6b22c2692f9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55485
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Interestingly, the Chromium version is a bit behind the default. I've
set it to match the Chromium version.
Bug: chromium:1340825
Change-Id: Ia956e42897add5849dfe09ec8e3a19f704ed9641
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55425
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Some compiler configuration are manipulating the 16-bit register `h0`
and delocate needs to know that's a register, not a symbol. Likewise,
NZCV is Aarch64's condition flags register which can be (and is) read
with `msr`.
Change-Id: Ica5be6a059ead61d22d60fd2db1a484d9ac2be3b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55307
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
I have a use for these in the chrome verifier conversions, we
could choose to make them hidden again after a future move to
boringssl..
Change-Id: If059debbdf482d64577ad04c1ec4f9c82724de1e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55305
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
The clang script needed to be tweaked slightly because they've since
changed the URL. Also libc++ now needs to be built as C++20. (The
bundled libc++ is only built in some of our test configs, so this
doesn't imply a C++20 dependency across the board.)
Change-Id: I0a9e3aed71268bcd37059af8549a23cfc0270b05
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55272
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
ioutil has been deprecated since Go 1.16. The functions were moved to
some combination of io and os. See https://pkg.go.dev/io/ioutil.
(File-related functions went to os. Generic things went to io. Names
were kept the same except TempDir and TempFile are os.MkdirTemp and
os.CreateTemp, respectively.)
Change-Id: I031306f69e70424841df08f64fa9d90f31780928
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55186
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
This probably needs some revising (ideally the files would just live in
some BoringSSL branch), but for now just avoid undoing the manual change
done to the pregenerated files in Chromium.
Change-Id: I0435a1478af8265c085d316eb83b394289eb1f67
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55245
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Some third-party code requires it.
For now, I've just introduced a new hook on the method table. This is
rather goofy though. First, making EVP know about TLS is a layering
violation that OpenSSL introduced. They've since fixed this and added
EVP_PKEY_get1_encoded_public_key in OpenSSL 3.0, but callers expect the
TLS one to exist in OpenSSL 1.1.1, so implement that one.
Along the way, implement EC_KEY_oct2key from upstream, which is slightly
less tedious when you're already working in EC_KEY.
To make this third-party code work (and to write a test without dipping
out of EVP, or using the very tedious EVP_PKEY_paramgen API), we also
need to change EVP_PKEY_copy_parameters to work when the source EVP_PKEY
is empty, per upstream's 2986ecdc08016de978f1134315623778420b51e5.
OpenSSL's API has *multiple* levels of empty states to worry about!
Something to avoid when we get to rethinking this error-prone API.
Bug: b:238920520
Change-Id: I3fd99be560db313c1bf549a4e46ffccc31e746e1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54905
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Previously the code just flipped one bit. But, empirically, modern Clang
will sometimes produce code that doesn't depend on the first 16 bytes of
the data; they are encoded in the instructions instead. Thus zero out
the full value.
(If Clang ever starts embedding complete values into the instruction
stream then we're going to have to do something more complex. Self tests
are a bit funny: the compiler could reasonably optimise them away
completely given that it sees all the inputs. Perhaps the inputs would
have to be moved into a different object file.)
Change-Id: I7bfb18cb7868def67fc791dcc31c5915c7728ac4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54825
Commit-Queue: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
For testing vector sets, NIST supports fetching the expected results,
which can be helpful for debugging.
Change-Id: Ida1f884520b1d0600b369f705a184624fa055a52
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54665
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Tests can now be run either in a local build or on an attached
device. The script tries to infer the correct mode of operation
but it can also be specified on the command line.
Test: Ran break-tests.sh in both modes
Change-Id: I515ac0cede23e2cb775b99e0af8108a3ce0bde37
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53585
Reviewed-by: Adam Langley <agl@google.com>
b95124305a readded 3DES support in acvptool, but not in
modulewrapper because we don't want it for BoringSSL itself. But without
modulewrapper support, the tests don't work. Support could be backported
into testmodulewrapper but it doesn't seem worthwhile for a few more
months support.
Change-Id: I4e7ace66f9ac1915996db7dfdeeb7e9d4969915f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53607
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Support is still needed for ACVP until 2023
Change-Id: Ia131a85bc06e7c61c823f1b3c021e2625a8769c4
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53465
Reviewed-by: Corie Pressley <cpressley@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Since stdout and stderr aren't synchronised, grepping their combined
output can sometimes fail since the regexp is looking for the start of a
line. Better to discard the stdout, which always works.
Change-Id: I5d0331debfe4b3eddc628c1fecc9c6b83d462a7a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53106
Reviewed-by: David Benjamin <davidben@google.com>
This is required to run SHA3 tests otherwise we get an error of unknown
algorithm.
Change-Id: I085da2b6757ba1f452f33abc7f1bafc4a404e025
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52926
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: Corie Pressley <cpressley@google.com>
OpenSSL 1.1.1 added HKDF support, but by sticking it into
EVP_PKEY_derive, the API meant for Diffie-Hellman-like primitives.
Implement it for OpenSSL compatibility.
This does unfortunately mean anything using EVP now pulls in HKDF. HKDF
isn't much code, but we should make EVP more static-linker-friendly.
(Filed https://crbug.com/boringssl/497)
Change-Id: I90b9b0d918129829eb36ba9d50ff4d8580346ff0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52829
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Best to exercise the full range of lengths, where supported. This does
makes the downloads larger but the ACVP demo server seems to have mostly
solved its issue of hanging when serving large files. None the less, a
longer timeout is needed.
Change-Id: I1b4879ded8a03b40512b4e03e2b2ce59678974f7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52745
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
The OpenSSL style writes multiline block comments with a blank line at
the top and bottom, like so:
/*
* Some multi-line
* comment
*/
The script already removed the trailing blank line, but not the leading
one. When we go to run this script in crypto/asn1, etc., we'll come
across those comments.
Change-Id: I189aec87a08607008779f883a97f2c53d24ee2da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52730
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
I'm leaving libc++abi unupdated for now, because it depends on a newer
libc++ than Chromium has managed to update to just yet. (It looks like
Chromium is, for now, manually passing -D_LIBCPP_CONSTINIT=constinit.)
Probably easier to pick that up when the dust settles.
(When that happens, libc++abi will need to be built as C++20, but that's
fine because this is only used on bots.)
Change-Id: I2b7ae62b618b0e09863b4b38548be1b937fbe0d0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52646
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
I'm collecting these changes, made by `go fmt` into their own change so
that they don't add noise to a meaningful change in the future.
Change-Id: I0ca931816fdba60ecde43e3eaffd0339d1773e73
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52429
Reviewed-by: Bob Beck <bbe@google.com>
The module supports these operations, they should probably be tested
with ACVP.
Change-Id: I09a52281f0c6877862139b73a876c995aa9af92a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52428
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
PSS verification with RSA 1024 is still acceptable. This change adds it
to our regcap. SHA-512 is omitted because that doesn't fit in 1024 bits
with PSS encoding. (Unless you shrink the salt, but we don't want to
deal with odd PSS configurations like that.)
Change-Id: I05d4778d45c25c87e2e50cd095380ecd4f12c75c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52427
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
3DES is no longer acceptable for FIPS validation.
Change-Id: Id4f80f6201220eff28cb3597540a3b796bfcf54f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52426
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
I broke the delocate tests with 27ffcc6e19 because that change
switched the integrity check hash function in the tested configuration
to SHA-256, but didn't update the expectation files.
Change-Id: I05f61eda795c833847981c5b21287fd0d2b33064
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52405
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Now that we've dropped MSVC 2015, I believe we can rely on C++14 (which
is now seven years old). This switches the build to require C++14. I've
gone ahead and switched code in both public headers and within the
library, but if the public headers are a problem, we can revert those
separately.
C++14 doesn't get us quite as much as C++17, but see if we can get to
C++14 first. Still, std::enable_if_t and the less restricted constexpr
are nice wins.
Update-Note: C++14 is now required to build BoringSSL. If the build
breaks, make sure your compiler is C++14-capable and is not passing
-std=c++11. If this is causing problems for your project, let us know.
Change-Id: If03a88e3f8a11980180781f95b806e7f3c3cb6c3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52246
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This creates an install directory under the top level source directory.
The install contains a CMake config file that produces variables and
targets compatible with FindOpenSSL, or the directory can be scanned by
FindOpenSSL via -DOPEN_SSL_ROOT. This allows using BoringSSL with
third-party dependencies that find an SSL implementation via CMake.
Change-Id: Iffeac64b9cced027d549486c98a6cd9721415454
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52205
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
The ARMv8 assembly code in this commit is mostly taken from OpenSSL's `ecp_nistz256-armv8.pl` at 19e277dd19/crypto/ec/asm/ecp_nistz256-armv8.pl (see Note 1), adapting it to the implementation in p256-x86_64.c.
Most of the assembly functions found in `crypto/fipsmodule/ec/asm/p256-x86_64-asm.pl` required to support that code have their analogous functions in the imported OpenSSL ARMv8 Perl assembly implementation with the exception of the functions:
- ecp_nistz256_select_w5
- ecp_nistz256_select_w7
An implementation for these functions was added.
Summary of modifications to the imported code:
* Renamed to `p256-armv8-asm.pl`
* Modified the location of `arm-xlate.pl` and `arm_arch.h`
* Replaced the `scatter-gather subroutines` with `select subroutines`. The `select subroutines` are implemented for ARMv8 similarly to their x86_64 counterparts, `ecp_nistz256_select_w5` and `ecp_nistz256_select_w7`.
* `ecp_nistz256_add` is removed because it was conflicting during the static build with the function of the same name in p256-nistz.c. The latter calls another assembly function, `ecp_nistz256_point_add`.
* `__ecp_nistz256_add` renamed to `__ecp_nistz256_add_to` to avoid the conflict with the function `ecp_nistz256_add` during the static build.
* l. 924 `add sp,sp,#256` the calculation of the constant, 32*(12-4), is not left for the assembler to perform.
Other modifications:
* `beeu_mod_inverse_vartime()` was implemented for AArch64 in `p256_beeu-armv8-asm.pl` similarly to its implementation in `p256_beeu-x86_64-asm.pl`.
* The files containing `p256-x86_64` in their name were renamed to, `p256-nistz` since the functions and tests defined in them are hereby running on ARMv8 as well, if enabled.
* Updated `delocate.go` and `delocate.peg` to handle the offset calculation in the assembly instructions.
* Regenerated `delocate.peg.go`.
Notes:
1- The last commit in the history of the file is in master only, the previous commits are in OpenSSL 3.0.1
2- This change focuses on AArch64 (64-bit architecture of ARMv8). It does not support ARMv4 or ARMv7.
Testing the performance on Armv8 platform using -DCMAKE_BUILD_TYPE=Release:
Before:
```
Did 2596 ECDH P-256 operations in 1093956us (2373.0 ops/sec)
Did 6996 ECDSA P-256 signing operations in 1044630us (6697.1 ops/sec)
Did 2970 ECDSA P-256 verify operations in 1084848us (2737.7 ops/sec)
```
After:
```
Did 6699 ECDH P-256 operations in 1091684us (6136.4 ops/sec)
Did 20000 ECDSA P-256 signing operations in 1012944us (19744.4 ops/sec)
Did 7051 ECDSA P-256 verify operations in 1060000us (6651.9 ops/sec)
```
Change-Id: I9fdef12db365967a9264b5b32c07967b55ea48bd
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51805
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
There are paperwork reasons why it's useful to use the same hash
function in all cases. Thus unify on SHA-256 because contexts where
SHA-512 is faster, are faster overall and thus less sensitive.
Change-Id: I7a782a3adba4ace3257313a24dc8bc213b9d64ec
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52165
Reviewed-by: David Benjamin <davidben@google.com>
VS 2017 was released in March 2017, five years ago now. This means VS
2015 is now past our support window.
This will make the unmarked and "vs2017" configs in CI/CQ do the same
thing. I'll follow up with a separate CL in infra/config to switch the
test VS 2019 instead.
Update-Note: BoringSSL may no longer build with VS 2015. Consumers
should upgrade to the latest Visual Studio release. VS 2017 or later is
required.
Change-Id: I477759deb95a27efe132de76d9ed103826110df0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52085
Reviewed-by: Bob Beck <bbe@google.com>
Reviewed-by: Adam Langley <agl@google.com>
We need a function that returns a version that links to a certificate.
Previously we have used the git hash as the version of our modules but
the source cannot contain its own hash. Thus this change defines a new
format for FIPS module versions which will be filled in once we're ready
to define a version.
Change-Id: Ie4641945119106bc47e8da94ed8a45a86abb6f92
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51986
Reviewed-by: David Benjamin <davidben@google.com>
VS2015 has finally dropped off our support window. As part of dropping
it from the bots, I'm thinking of using the current vs2017 builders to
test vs2019. In preparation for that, add a vs2019 hash to
vs_toolchain.py.
Change-Id: I4c3dde2825f57c39a8da0e155e96d08550d39893
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/52005
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Adam Langley
David Benjamin
Adam Langley
Adam Langley
Christopher Peterson Sauer
Bob Beck
Adam Langley
Pete Bentley
Sureshbhai Dave
Daniel Thornburgh
Nevine Ebeid
Bob Beck