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

Author	SHA1	Message	Date
David Benjamin	dd81bf7707	Introduce ossl_ssize_t and use it in ASN1_STRING_set. We have a number of APIs that cannot migrate to size_t because OpenSSL used negative numbers as some special indicator. This makes it hard to become size_t-clean. However, in reality, the largest buffer size is SSIZE_MAX, or, more accurately PTRDIFF_MAX. But every platform I've ever seen make ptrdiff_t and size_t the same size. malloc is just obligated to fail allocations that don't fit in ssize_t. ssize_t itself is not portable (Windows doesn't have it), but we can define ossl_ssize_t to be ptrdiff_t. OpenSSL also has an ossl_ssize_t (though they don't use it much), so we're also improving compatibility. Start this out with ASN1_STRING_set. It still internally refuses to construct a string bigger than INT_MAX; the struct can't hold this and even if we fix the struct, no other code, inside or outside the library, can tolerate it. But now code which passes in a size_t (including our own) can do so without overflow. Bug: 428, 516 Change-Id: I17aa6971733f34dfda7d971882d0f062e92340e9 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/54953 Commit-Queue: Bob Beck <bbe@google.com> Auto-Submit: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>	2 years ago
David Benjamin	846a22700f	Switch __ARM_FEATURE_CRYPTO to __ARM_FEATURE_{AES,SHA2}. 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>	3 years ago
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	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
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