Update BoringSSL #80
Merged
Update BoringSSL #80
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Otherwise BoringSSL may select one the private key does not support. Change-Id: Ia0a57657bd6dedaa6653c23cc850bb6b6fa8f219 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48525 Reviewed-by: Adam Langley <agl@google.com>
Some callers want the value to be heap-allocated. It's a little annoying that this returns an empty value (if we only supported heap-allocated ones, I'd have merged init into new), but since we have multiple constructor functions, this is probably the least fuss. Change-Id: I42f586e39850954fb6743f8be50a7cfffa0755ba Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48526 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
Currently, GetUnsigned() calls strtoul and checks whether the resulting unsigned long int is greater than UINT_MAX. This implicitly assumes that UINT_MAX < ULONG_MAX. Problematically, `unsigned long int` and `unsigned` have the same size on Windows [0] and on 32-bit architectures. For correctness, we now check whether strtoul failed because it would overflow the unsigned long int before checking whether the value fits in an unsigned type. [0]: https://docs.microsoft.com/en-us/cpp/cpp/data-type-ranges?view=msvc-160 Change-Id: I49702febf4543bfb7991592717443e0b2adb954f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48545 Commit-Queue: Dan McArdle <dmcardle@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
In configurations without threads, we're not thread-safe anyway. Instead use the refcount_lock.c implementation which, in turn, calls into thread_none.c, so this turns into a plain refcount. This avoids a build issue on platforms which define NO_THREADS, use C11, lack C11 atomics, and are missing a __STDC_NO_ATOMICS__ definition. The platforms ought to define __STDC_NO_ATOMICS__ or implement them, but atomics are also unnecessary overheard in NO_THREADS configurations anyway. Change-Id: I927e1825dd6474d95226b93dad704594f120450a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48565 Commit-Queue: David Benjamin <davidben@google.com> Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com>
The tool generates three files: an ECHConfig, its corresponding private
key, and the ECHConfig wrapped in an ECHConfigList.
For example, the following invocation generates the files:
bssl generate-ech \
-out-ech-config-list ech_config_list.data \
-out-ech-config ech_config.data \
-out-private-key ech.key \
-public-name foo.example \
-config-id 0
Now, we can pass the ECHConfig and private key into the 'server' and
'client' commands:
bssl server -accept 4430 \
-ech-config ech_config.data \
-ech-key ech.key
bssl client -connect localhost:4430 \
-ech-config-list ech_config_list.data
Bug: 275
Change-Id: Id4342855483fb01aa956f9aff356105c4a8ca4f6
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48466
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: I26251ce85f2cb1b441ae415b1506161a90bd3efa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48585 Reviewed-by: David Benjamin <davidben@google.com>
…3.""" This reverts commit be9a86f. Let's try this again. Bug: 375 Change-Id: Ie01cced8017835b2cc6d80e5e81a4508a37fbbaf Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48625 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Some JSON files have a header, but without a URL. Thus consider a block that doesn't contain an algorithm to also be a header. Change-Id: Ic35a827843e9d0169ba8398df69c46a5baeffb44 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48605 Reviewed-by: David Benjamin <davidben@google.com>
The polynomials have 701, 16-bit values. But poly_Rq_mul was reading 32 bytes at offset 1384 in order to get the last 18 of them. This silently worked for a long time, but when 7153013 switched to keeping variables on the stack it was noticed by Valgrind. This change fixes the overread. Setting watchpoints at the ends of the two inputs (and one output) now shows no overreads nor overwrites. BUG=424 Change-Id: Id86c1407ffce66593541c10feee47213f4b95c5d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48645 Reviewed-by: David Benjamin <davidben@google.com>
Change-Id: I04c8bb68801aeb0938e5b038b98811ca4ffe50f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48685 Commit-Queue: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: David Benjamin <davidben@google.com>
It is not obvious from "It does not take ownership of |buf|" whether the function makes a copy or not. It does not make a copy (maybe it should...), so callers are obligated to manage their lifetimes. Change-Id: I7df9a5814321fd833fcb8d009d9e0318d6668dd4 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48669 Reviewed-by: Adam Langley <agl@google.com>
This covers most of the ASN.1 time functions and a handful more of x509.h. Also remove some code under #if 0. I'm running out of a easy ones to do, which is probably a good thing. Change-Id: I085b1e2a54d191a7a5f18c801b3c135cfda7bd88 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48665 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
This flag is set when an ASN1_STRING is created from a codepath that is aware it is an "mstring" (CHOICE of multiple string or string-like types). With setters like X509_set_notBefore, it is very easy to accidentally lose the flag on some field that normally has it. The only place the flag is checked is X509_time_adj_ex. X509_time_adj_ex usually transparently picks UTCTime vs GeneralizedTime, as in the X.509 CHOICE type. But if writing to an existing object AND if the object lacks the flag, it will lock to whichever type the object was previously. It is likely any caller hitting this codepath is doing so unintentionally and has a latent bug that won't trip until 2050. In fact, one of the ways callers might accidentally lose the ASN1_STRING_FLAG_MSTRING flag is by using X509_time_adj_ex! X509_time_adj_ex(NULL) does not use an mstring-aware constructor. This CL avoids needing such a notion in the first place. Looking through callers, the one place that wants the old behavior is a call site within OpenSSL, to set the producedAt field in OCSP. That field is a GeneralizedTime, rather than a UTCTime/GeneralizedTime CHOICE. We dropped that code, but I'm making a note of it to remember when filing upstream. Update-Note: ASN1_STRING_FLAG_MSTRING is no longer defined and X509_time_adj_ex now behaves more predictably. Callers that actually wanted to lock to a specific type should call ASN1_UTCTIME_adj or ASN1_GENERALIZEDTIME_adj instead. Change-Id: Ib9e1c9dbd0c694e1e69f938da3992d1ffc9bd060 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48668 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
Change-Id: I7712f66e16b761ee23292980cff039e62d29b22f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48666 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
They would previously output syntax errors. Change-Id: I7817a91d0c8ed8d6ac6a5a1fd9c9ed1223c5960e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48667 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
CMake's language is rather fragile and unsound. For the most part, it is
a shell script with more parentheses. That is, it simply expands command
arguments into a list of strings and then evaluates it, complete with
shell-style differences between "${FOO}" and ${FOO}.
The if() command is special and internally also expands variables. That
is why things like if(FOO STREQUAL "BAR") work. CMake interprets "FOO"
as a variable if it can find a variable, or a string otherwise. In
addition to getting very confused on typos, it means that
if("${FOO}" STREQUAL "BAR") will double-expand, and it will do strange
things if BAR is a variable.
CMP0054 patches this (which we set by minimum version) so that if() only
expands if the token was unquoted. This fixes
if("${FOO}" STREQUAL "BAR"). However, if(${FOO} STREQUAL "BAR")
continues to double-expand FOO.
We had a mix of all three of FOO, ${FOO}, and "${FOO}". It's not clear
which is the canonical spelling at this point, but CMake own files
(mostly) use FOO, as do most of our lines, so I've standardized on that.
It's a little unsatisfying if we typo a variable, but I suppose ${FOO}
also silently ignores unset variables.
Bug: 423
Change-Id: Ib6baa27f4065eed159e8fb28820b71a0c99e0db0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48705
Reviewed-by: Adam Langley <agl@google.com>
When upstreaming c1d8c5b as openssl/openssl#10883 and then openssl/openssl#10930, we ended up diverging slightly: in the upstream version, I ended up applying the same change to the xlate files. Upstream also suggested "error closing STDOUT: $!". Apply the same changes here. Change-Id: I8a8cbc3944432e94a8844f9f628a900edfe77b30 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48725 Reviewed-by: Adam Langley <agl@google.com>
This syncs this file up to e7ff223a20697e5a401d2d9bb7a75e699ed46633 from upstream's OpenSSL_1_1_1-stable branch. The main change of note is the 4x loop from upstream's 7ff2fa4b9281232f0ca1db03d42a954c462ef77d, 9ee020f8dc7813db82a119058d8f57e70e7e8904, aa7bf316980259a11dcbaf6128ed86d33dc24b97, and 603ebe03529101424670051aa0c616dc6e037b28. Benchmarks on a Pixel 4a. Before: Did 14069000 AES-128-GCM (16 bytes) seal operations in 2000042us (112.5 MB/sec) Did 6768000 AES-128-GCM (256 bytes) seal operations in 2000182us (866.2 MB/sec) Did 1902000 AES-128-GCM (1350 bytes) seal operations in 2000479us (1283.5 MB/sec) Did 359000 AES-128-GCM (8192 bytes) seal operations in 2003942us (1467.6 MB/sec) Did 182000 AES-128-GCM (16384 bytes) seal operations in 2002245us (1489.3 MB/sec) Did 13388000 AES-256-GCM (16 bytes) seal operations in 2000144us (107.1 MB/sec) Did 6069000 AES-256-GCM (256 bytes) seal operations in 2000276us (776.7 MB/sec) Did 1638000 AES-256-GCM (1350 bytes) seal operations in 2001076us (1105.1 MB/sec) Did 305000 AES-256-GCM (8192 bytes) seal operations in 2000040us (1249.3 MB/sec) Did 155000 AES-256-GCM (16384 bytes) seal operations in 2009398us (1263.8 MB/sec) After: Did 13837000 AES-128-GCM (16 bytes) seal operations in 2000131us (110.7 MB/sec) [-1.7%] Did 7506000 AES-128-GCM (256 bytes) seal operations in 2000197us (960.7 MB/sec) [+10.9%] Did 2289000 AES-128-GCM (1350 bytes) seal operations in 2000734us (1544.5 MB/sec) [+20.3%] Did 443000 AES-128-GCM (8192 bytes) seal operations in 2000321us (1814.2 MB/sec) [+23.6%] Did 225000 AES-128-GCM (16384 bytes) seal operations in 2002308us (1841.1 MB/sec) [+23.6%] Did 13280000 AES-256-GCM (16 bytes) seal operations in 2000011us (106.2 MB/sec) [-0.8%] Did 6630000 AES-256-GCM (256 bytes) seal operations in 2000229us (848.5 MB/sec) [+9.2%] Did 1916000 AES-256-GCM (1350 bytes) seal operations in 2000373us (1293.1 MB/sec) [+17.0%] Did 365000 AES-256-GCM (8192 bytes) seal operations in 2001519us (1493.9 MB/sec) [+19.6%] Did 185000 AES-256-GCM (16384 bytes) seal operations in 2006588us (1510.5 MB/sec) [+19.5%] (See cl/387919990 for some notes I made in reviewing, though likely future me will find them incomprehensible anyway.) Change-Id: Id386e80143611487e07b2fbfda15d0abc54ea145 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48726 Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ia2cb9d969b25d1815d8157dd74125d60b138138f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48765 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
ASN1_STRING_set_by_NID is very complex and depends on a "global mask" for most NIDs. (Some NIDs use a single type and use STABLE_NO_MASK to disable the global mask.) Historically, it defaulted to allowing all types, but it switched to UTF8String in OpenSSL 1.0.2. Updating the global mask is not thread-safe, and it's 2021. Let's just always use UTF-8. The only callers I found set it to UTF-8 anyway (with the exception of some test script we don't use, and some code that wasn't compiled). No-op writes in the C/C++ memory model are still race conditions, so this CL fixes some bugs in those callers. Update-Note: The global mask for ASN1_STRING_set_by_NID is now always UTF-8. Callers that want another type should reconsider and, if UTF-8 is still unsuitable, just pass the actual desired type into ASN1_mbstring_copy, X509_NAME_ENTRY_set_data, etc Change-Id: I679e99c57da9a48c805460abcb3af5b2f938c93f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48766 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
These constants aren't suitably namespaced and, moreover, are redefined in a_strnid.c. (The constants aren't especially useful because an X509_NAME doesn't check the upper bound.) Update-Note: Removed some unnamespaced constants. Change-Id: I7d15ae731628d3665119081289947600e7f38065 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48768 Reviewed-by: Adam Langley <agl@google.com>
This type does not appear in any public APIs. Change-Id: Ie57c7662e691ea05ff2133beda9760832ea0d0de Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48769 Reviewed-by: Adam Langley <agl@google.com>
This matches OpenSSL and the name. Also accessors like X509_ALGOR_get0 are in x509.h. Change-Id: Ic7583edcf04627cbfae822df11e75eebdd9ad7aa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48770 Reviewed-by: Adam Langley <agl@google.com>
We've never tested this and plenty of files depend on FILE* APIs without ifdefs. Change-Id: I8c51c043e068b30bdde1723c3810d3e890eabfca Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48771 Reviewed-by: Adam Langley <agl@google.com>
No sense in implementing a BIO/FILE abstraction when BIO is itself a FILE abstraction. Follow-up CLs will unwind the char_io abstraction and then split the ASN1 and X509 bits of this file. Change-Id: I00aaf2fbab44abdd88252ceb5feb071ad126a0b2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48772 Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ib342ce1acf7ea4fcff012bf149cf699807ddc0fa Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48773 Reviewed-by: Adam Langley <agl@google.com>
With io_ch unwound, X509_NAME_print_ex just calls ASN1_STRING_print_ex, so we can put all the code in the right directories. We need to duplicate maybe_write, but it's a one-line function. Change-Id: Ifaa9f1a24ee609cbaa24f93eb992f7d911f1b4a0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48774 Reviewed-by: Adam Langley <agl@google.com>
For some reason, ASN1_STRING_print was not in the same file as ASN1_STRING_print_ex, but X509_print. Although it also behaves very differently from ASN1_STRING_print_ex, so that's a little interesting. Change-Id: I3f88f8943c8e36426eedafa7e350a787881d0c74 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48775 Reviewed-by: Adam Langley <agl@google.com>
ASN1_STRING_print_ex is extremely complex and attempting to implement RFC2253, so write some tests for it. Along the way, unexport CHARTYPE_*, which are internal book-keeping used in ASN1_STRING_print_ex. Change-Id: Idb27cd40fb66dc099d1fd6d039a00404608c2063 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48776 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
Also use the simpler single-call variant. Change-Id: I3834a798549f12a9dcdec6a357d2380085baf940 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/48777 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com>
We currently have two aarch64 SHA-256 implementations: one using general-purpose registers and one using the SHA-256 extensions. Upstream's 866e505e0d663158b0fe63a7fb7455eebacc6470 added a NEON version. This CL syncs the transforms at the bottom of the file, to avoid potential mistranslations in future imports. It doesn't change the output for our current assembly. Skips the NEON implementation itself for now. It only helps processors without SHA-256 instructions. While Android does not actually mandate the cryptography extensions on ARMv8, most devices have it. Additionally, this file does CPU dispatch in assembly, without taking advantage of static information. We'd end up shipping both fallback SHA-256 implementations. This is particularly silly because NEON is mandatory in ARMv8-A anyway. (Does anyone build us on -R or -M? Probably not?) (If we later have a reason to import it, the binary size cost isn't that significant. Moreover, the NEON fallback is actually slightly smaller than the non-NEON fallback, so if we move CPU dispatch to C, importing may even be worthwhile.) Change-Id: I3c8ca6e77e4e6d1299f975c407cbcf4c9c240523 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50805 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This imports 753316232243ccbf86b96c1c51ffcb41651d9ad5, 46f4e1bec51dc96fa275c168752aa34359d9ee51, and 32bbb62ea634239e7cb91d6450ba23517082bab6. The last commit fixes a detection of big-endian aarch64 in the kernel, which we do not support at all, but is imported to reduce the upstream diff. Though it points out a messy part of arm_arch.h: __ARMEL__ and __ARMEB__ are specific to 32-bit ARM. __AARCH64EB__ and __AARCH64EL__ are the 64-bit ones. But OpenSSL's arm_arch.h defines __ARME[LB]__ for aarch64 and uses it in perlasm. We should fix the files upstream to look at the aarch64 ones. (Indeed our own base.h assumes __ARMEL__ implies 32-bit ARM.) Change-Id: I6c2241e103a97e8c3599cdfa43dcc6f30d4a2581 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50806 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This imports the changes to sha512-armv8.pl from upstream's af0fcf7b4668218b24d9250b95e0b96939ccb4d1. Tweaks needed: - Add an explicit .text because we put .LK$BITS in .rodata for XOM - .LK$bits and code are in separate sections, so use adrp/add instead of plain adr - Where glibc needs feature flags to *enable* pthread_rwlock, Apple interprets _XOPEN_SOURCE as a request to *disable* Apple extensions. Tighten the condition on the _XOPEN_SOURCE check. Added support for macOS and Linux, tested manually on an ARM Mac and a VM, respectively. Fuchsia and Windows do not currently have APIs to expose this bit, so I've left in TODOs. Benchmarks from an Apple M1 Max: Before: Did 4647000 SHA-512 (16 bytes) operations in 1000103us (74.3 MB/sec) Did 1614000 SHA-512 (256 bytes) operations in 1000379us (413.0 MB/sec) Did 439000 SHA-512 (1350 bytes) operations in 1001694us (591.6 MB/sec) Did 76000 SHA-512 (8192 bytes) operations in 1011821us (615.3 MB/sec) Did 39000 SHA-512 (16384 bytes) operations in 1024311us (623.8 MB/sec) After: Did 10369000 SHA-512 (16 bytes) operations in 1000088us (165.9 MB/sec) [+123.1%] Did 3650000 SHA-512 (256 bytes) operations in 1000079us (934.3 MB/sec) [+126.2%] Did 1029000 SHA-512 (1350 bytes) operations in 1000521us (1388.4 MB/sec) [+134.7%] Did 175000 SHA-512 (8192 bytes) operations in 1001874us (1430.9 MB/sec) [+132.5%] Did 89000 SHA-512 (16384 bytes) operations in 1010314us (1443.3 MB/sec) [+131.4%] (This doesn't seem to change the overall SHA-256 vs SHA-512 performance question on ARM, when hashing perf matters. SHA-256 on the same chip gets up to 2454.6 MB/s.) In terms of build coverage, for now, we'll have build coverage everywhere and test coverage on Chromium, which runs this code on macOS CI. We should request a macOS ARM64 bot for our standalone CI. Longer term, we need a QEMU-based builder to test various features. QEMU seems to have pretty good coverage of all this, which will at least give us Linux. I haven't added an OPENSSL_STATIC_ARMCAP_SHA512 for now. Instead, we just look at the standard __ARM_FEATURE_SHA512 define. Strangely, the corresponding -march tag is not sha512. Neither GCC and nor Clang have -march=armv8-a+sha512. Instead, -march=armv8-a+sha3 implies both __ARM_FEATURE_SHA3 and __ARM_FEATURE_SHA512! Yet everything else seems to describe the SHA512 extension as separate from SHA3. https://developer.arm.com/architectures/system-architectures/software-standards/acle Update-Note: Consumers with a different build setup may need to limit -D_XOPEN_SOURCE=700 to Linux or non-Apple platforms. Otherwise, <sys/types.h> won't define some typedef needed by <sys/sysctl.h>. If you see a build error about u_char, etc., being undefined in some system header, that is probably the cause. Change-Id: Ia213d3796b84c71b7966bb68e0aec92e5d7d26f0 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50807 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
We use underscores everywhere except these files, which use hyphens. Switch them to be consistent. Change-Id: I67eddbdae7caaf8405bdb4a0c1b65e6f3ca43916 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50808 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
cpu.h contains almost entirely private symbols, which aren't reliably usable outside the library because they lack OPENSSL_EXPORT. (And can't have OPENSSL_EXPORT. The linker wants references to exported symbols to go through the GOT, and our assembly doesn't do that.) In preparation for unexporting them, move the few public APIs to crypto.h. They seem similar in spirit to functions like CRYPTO_has_asm. Update-Note: As part of this, I conditioned cpu-arm-linux.c on OPENSSL_LINUX, so that the header files can have accurate conditions. This means unrecognized ARM platforms that do not set OPENSSL_STATIC_ARMCAP will fail to build, where previously we defaulted to the Linux mechanisms. This matches cpu-aarch64-linux.c, which is already gated on OPENSSL_LINUX. (And the file is quite Linux-specific. Even if a non-Linux ELF target used getauxval for ARM capabilities, it's unlikely that our hardcoded constants and /proc behavior applies anyway.) Change-Id: I1ee9eb72097be619d3f28a51b1ea058b3c37d05a Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50845 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: Adam Langley <agl@google.com>
These symbols were not marked OPENSSL_EXPORT, so they weren't really usable externally anyway. They're also very sensitive to various build configuration toggles, which don't always get reflected into projects that include our headers. Move them to crypto/internal.h. Change-Id: I79a1fcf0b24e398d75a9cc6473bae28ec85cb835 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50846 Reviewed-by: Adam Langley <agl@google.com>
The latest version of ACLE splits __ARM_FEATURE_CRYPTO into two defines
to reflect that, starting ARMv8.2, the cryptography extension can
include {AES,PMULL} and {SHA1,SHA256} separately.
Also standardize on __ARM_NEON, which is the recommended symbol from
ACLE, and the only one defined on non-Apple aarch64 targets. Digging
through GCC history, __ARM_NEON__ is a bit older. __ARM_NEON was added
in GCC's 9e94a7fc5ab770928b9e6a2b74e292d35b4c94da from 2012, part of GCC
4.8.0.
I suspect we can stop paying attention to __ARM_NEON__ at this point,
but I've left both working for now. __ARM_FEATURE_{AES,SHA2} is definite
too new to fully replace __ARM_FEATURE_CRYPTO.
Tested on Linux that -march=armv8-a+aes now also drops the fallback AES
code. Previously, we would pick up -march=armv8-a+crypto, but not
-march=armv8-a+aes. Also tested that, on an OPENSSL_STATIC_ARMCAP build,
-march=armv8-a+sha2 sets the SHA-1 and SHA-256 features.
Change-Id: I749bdbc501ba2da23177ddb823547efcd77e5c98
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50847
Reviewed-by: Adam Langley <agl@google.com>
GCC's __ARMEL__ and __ARMEB__ defines denote little- and big-endian arm, respectively. They are not defined on aarch64, which instead use __AARCH64EL__ and __AARCH64EB__. However, OpenSSL's assembly originally used the 32-bit defines on both platforms and even define __ARMEL__ and __ARMEB__ in arm_arch.h. This is less portable and can even interfere with other headers, which use __ARMEL__ to detect little-endian arm. (Our own base.h believes __ARMEL__ implies 32-bit arm. We just happen to check __AARCH64EL__ first. base.h is probably also always included before arm_arch.h.) Over time, the aarch64 assembly has switched to the correct defines, such as in 32bbb62ea634239e7cb91d6450ba23517082bab6. This commit finishes the job. (There is an even more official endianness detector, __ARM_BIG_ENDIAN in the Arm C Language Extensions. But I've stuck with the GCC ones here as that would be a larger change.) See also openssl/openssl#17373 Change-Id: Ic04ff85782e6599cdeaeb33d12c2fa8edc882224 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50848 Reviewed-by: Adam Langley <agl@google.com>
OpenSSL's assembly files have a few places where we condition code on __ARM_ARCH__, the minimum target ARM revision. It currently only controls some pre-ARMv7 code. This symbol has, from what I can tell, the same semantics as __ARM_ARCH, defined in Arm C Language Extensions, and added in GCC 4.8 and Clang 3.2: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9e94a7fc5ab770928b9e6a2b74e292d35b4c94da;hp=25bab91e017eb1d6d93117f3da96fa9b43703190 llvm/llvm-project@e98c4db Those are over nine years old, so drop all the fallback code. Also fix arm_arch.h to be includable on non-ARM platforms. Some tools expect all public headers to be cleanly includable and arm_arch.h being "public" was getting in the way (see cl/416881417). Interestingly, arm_arch.h previously only computed __ARM_ARCH__ for __GNUC__ and Clang doesn't define __GNUC__ on Windows. That means we actually weren't defining __ARM_ARCH__ for Windows. But none of the aarch64 assembly has __ARM_ARCH__-gated code, so it works out. If it ever does, that CL smooths that over. I've gated the __ARM_(MAX_)_ARCH__ bits on __ASSEMBLER__ to avoid breaking no-asm Windows/aarch64 builds on MSVC. There aren't any uses in C. Update-Note: ARM assembly now requires the compiler define __ARM_ARCH. This is not expected to break Clang or GCC from the last 8 or 9 years. Change-Id: Id45e95406edeecf8dda11dce9e82418516e9de1f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50849 Reviewed-by: Adam Langley <agl@google.com>
Change-Id: Ic3305debe9c5d85b1c47be4ebcdfcbd0660f49af Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50865 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Change-Id: If28138bbda4111b4a62f48cd30c7a71a675e44f7 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50885 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This change imports upstream's openssl/openssl@c045224 Change-Id: Ib50ff9eb8c48d9580aa2ffcae92d3990cc987e30 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50905 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
140-3 says > the zeroisation of protected and unprotected SSPs > shall be performed in the following scenarios: > ... > For temporary value(s) generated during the integrity test of the > module’s software or firmware upon completion of the integrity test. (IG 9.7.B) Change-Id: I911f294860bf33b13b2c997fc633c9bda777fc48 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50945 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This matches our other free functions. Fixed: 473 Change-Id: Ie147995c2f5b429f78e95cfc9a08ed54181af94e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51005 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
Description: Creating just a Gerrit password isn't enough. Before you can push a change to Gerrit, you must also create/associate a Gerrit account with the google account used to create the password. This avoids "git push ..." rejections like this: remote: PERMISSION_DENIED: The caller does not have permission remote: [type.googleapis.com/google.rpc.LocalizedMessage] remote: locale: "en-US" remote: message: "\'git push\' requires a Gerrit user account." Change-Id: Id02c1a69ccb0c2b8bf4c63b77ed3064125966eb3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50985 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This is designed to be the minimal infrastructure required to support using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen is used to generate Rust bindings in lockstep with the rest of the build. `rust-openssl` can consume these generated bindings with minimal changes. Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645 Reviewed-by: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>
See https://fuchsia-review.googlesource.com/c/fuchsia/+/624684. Also pick up the new, more specific, name for ZX_ARM64_FEATURE_ISA_SHA2. Update-Note: This CL is written assuming we can just rely on the SDK changes. Per go/fuchsia-sdk-age, this seems fairly safe. If this file fails to build due to missing symbols, update your project's Fuchsia SDK. If this blocks something, let us know. Change-Id: I28b0c234b577cc0de90e7ef096c15bb75a4ba501 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/50926 Reviewed-by: Adam Langley <agl@google.com>
…ndings for the targeted Arch Change-Id: I8ccd53bce0d73bd9d79f65770e544a75753ce4f8 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51025 Reviewed-by: David Benjamin <davidben@google.com>
We were fetching the mac-amd64 package even on mac-arm64. Change-Id: Iad842ebd46d467c0def9bdbd14c77698a03f58d3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51045 Reviewed-by: Adam Langley <agl@google.com>
The check finds implicit conversions of integer literals to bools: bool b1 = 1; bool b2 = static_cast<bool>(1); and transforms them to: bool b1 = true; bool b2 = true; Bug: chromium:1290142 Change-Id: I15579e28f544d07b331a230b70a8278e0651150d Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51085 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
This hash table, in applications that use pooling, can dedup received certificates in memory and thus should use a keyed hash. Change-Id: Idc40dc8f7463025183121642b30ea0de43ebac0e Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51125 Reviewed-by: Adam Langley <agl@google.com>
u8 strings in C++20 are char8_t instead of char; in order to compile on both C++17 and C++20 we need to remove the prefix. Change-Id: I85d1a9d72d24e8fa96ca22b1d99be9982fee8fb5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51065 Reviewed-by: David Benjamin <davidben@google.com> Commit-Queue: David Benjamin <davidben@google.com>
POSIX feature macros are a mess. Reportedly, FreeBSD also breaks with _XOPEN_SOURCE, so try leaving it unset by default. Update-Note: It's possible this will break yet another obscure UNIX. Hopefully we can eventually find a combination that works? Bug: 471 Change-Id: I103f8093110d343789b9c5a22eb056ab78d9cd14 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51145 Reviewed-by: Adam Langley <agl@google.com>
baentsch
approved these changes
Feb 13, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@baentsch on a side note, http://test.openquantumsafe.org/chromium-base.html lists algorithm combinations containing hybrid signatures, which aren't supported by Chromium.