diff options
| author | Madan mohan Manokar <[email protected]> | 2026-09-18 13:37:53 +0200 |
|---|---|---|
| committer | Tomas Mraz <[email protected]> | 2026-09-21 11:57:30 +0200 |
| commit | 99970d351c5168f08b81fb24e7d9d225e997cc8e (patch) | |
| tree | 3d9110d43d5f702beec9437bef178265f6154cc7 /include | |
| parent | Fix lock_failed output in Windows cmp_exch_ptr (diff) | |
| download | openssl-99970d351c5168f08b81fb24e7d9d225e997cc8e.tar.gz openssl-99970d351c5168f08b81fb24e7d9d225e997cc8e.zip | |
aes-ctr-avx512: disable the VAES-512 CTR path for MSVC
MSVC 14.51 builds of the VAES-512 CTR kernel return a wrong keystream for
AES-192 and AES-256 whenever the block count leaves a 4-block (single-zmm)
step. The default CTR-DRBG runs on AES-256-CTR, so this also corrupts
random byte generation and makes unrelated tests fail.
The same code is correct on VAES hardware built with gcc, so keep the hook
enabled there and off for MSVC until the code generation issue is found.
AES-CBC decryption is unaffected and stays enabled.
Hosted runners rarely have AVX-512, so whether CI exercises this path at all
depends on which host a job lands on. Run evp_extra_test under Intel SDE as
well, where -icx always reports VAES.
Refs #32873
Reviewed-by: Milan Broz <[email protected]>
Reviewed-by: Tomas Mraz <[email protected]>
Merge-date: Mon Sep 21 09:57:35 2026
Merged-from: https://github.com/openssl/openssl/pull/32883
Diffstat (limited to 'include')
| -rw-r--r-- | include/crypto/aes_platform.h | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/include/crypto/aes_platform.h b/include/crypto/aes_platform.h index 54d8a583885..8ae047def15 100644 --- a/include/crypto/aes_platform.h +++ b/include/crypto/aes_platform.h @@ -194,7 +194,25 @@ void gcm_ghash_v8(uint64_t Xi[2], const u128 Htable[16], const uint8_t *inp, siz #define VAES512_ELIGIBLE 0 #endif +/* + * An MSVC build of the VAES-512 CTR kernel returns a wrong keystream for + * AES-192 and AES-256 on a CPU that really has AVX-512 + VAES, for every + * payload whose block count leaves a 4-block (single-zmm) step. That also + * corrupts the AES-256-CTR based CTR-DRBG, so the damage is not confined to + * CTR callers. + * + * The same C is correct on VAES hardware under gcc, so this looks like code + * generation rather than a logic error. MSVC 14.51 is the toolset that fails; + * 14.41 does not reproduce it. Keep the CTR hook off for MSVC until that is + * understood. AES-CBC decryption stays enabled: it passed on the same host + * and compiler that exposed the CTR failure. + * See https://github.com/openssl/openssl/issues/32873. + */ +#if defined(_MSC_VER) && !defined(__clang__) +#define VAES_CTR_ELIGIBLE 0 +#else #define VAES_CTR_ELIGIBLE VAES512_ELIGIBLE +#endif #define VAES_CBC_ELIGIBLE VAES512_ELIGIBLE #if VAES_CTR_ELIGIBLE |