Chiebot-Mirror/boringssl - boringssl - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
David Benjamin	661266ea06	Move CPU detection symbols to crypto/internal.h. 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>	3 years ago
David Benjamin	37faa936b5	Move public APIs from cpu.h to crypto.h. 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>	3 years ago
David Benjamin	1e15682f1a	Enable SHA-512 ARM acceleration when available. 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>	3 years ago
David Benjamin	ce9b002ebd	Align the ARM capability functions. This is largely some cleanup so the three features follow the same patterns and is hopefully cleaner (no more separate static and non-static paths). The practical impact is probably nil. (Linux-based ARM builds with crypto extensions as a baseline, if any exist, save binary size.) Change-Id: I2214b1a54e2074024b8eeb51799a08b94646cbf3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45485 Reviewed-by: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
David Benjamin	f9bd455c85	Skip runtime NEON checks if __ARM_NEON is defined. When a feature is enabled statically in the build config, the compiler defines __ARM_NEON and also considers itself free to emit NEON code. In this case, there is no need to check for NEON support at runtime since the binary will not work without NEON anyway. Moving the check to compile time lets us drop unused code. Chrome has required NEON on Android for nearly five years now. However, historically there was a bad CPU which broke on some NEON code, but not others. See https://crbug.com/341598 and https://crbug.com/606629. We worked around that CPU by parsing /proc/cpuinfo and intentionally dropping the optimization. This is not a stable situation, however, as we're hoping the compiler is not good enough at emitting NEON to trigger this bug. Since then, the number of affected devices has dropped, and Chrome has raised the minimum Android requirement to L. The Net.HasBrokenNEON metric from Chrome is now well in the noise. This CL stops short of removing the workaround altogether because some consumers of Cronet are unsure whether they needed this workaround. Those consumers also build without __ARM_NEON, so gating on that works out. We'll decide what to do with it pending metrics from them. Update-Note: Builds with __ARM_NEON (-mfpu=neon) will now drop about 30KiB of dead code, but no longer work (if they even did before) on a particular buggy CPU. Builds without __ARM_NEON are not affected. Change-Id: Id8f7bccfb75afe0a1594572ea20c51d275b0a256 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45484 Reviewed-by: Adam Langley <agl@google.com> Commit-Queue: David Benjamin <davidben@google.com>	4 years ago
Adam Langley	fb0c05cac2	acvp: add CMAC-AES support. Change by Dan Janni. Change-Id: I3f059e7b1a822c6f97128ca92a693499a3f7fa8f Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/41984 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: David Benjamin <davidben@google.com>	5 years ago