[openssl/openssl] 28d8df: bn_nist: Fix strict-aliasing violations in little-...
Xi Ruoyao
noreply at github.com
Thu Nov 30 17:45:11 UTC 2023
Branch: refs/heads/openssl-3.0
Home: https://github.com/openssl/openssl
Commit: 28d8df496ea612ae49467ae013b9cd1dd0f33c8b
https://github.com/openssl/openssl/commit/28d8df496ea612ae49467ae013b9cd1dd0f33c8b
Author: Xi Ruoyao <xry111 at xry111.site>
Date: 2023-11-30 (Thu, 30 Nov 2023)
Changed paths:
M crypto/bn/bn_nist.c
Log Message:
-----------
bn_nist: Fix strict-aliasing violations in little-endian optimizations
The little-endian optimization is doing some type-punning in a way
violating the C standard aliasing rule by loading or storing through a
lvalue with type "unsigned int" but the memory location has effective
type "unsigned long" or "unsigned long long" (BN_ULONG). Convert these
accesses to use memcpy instead, as memcpy is defined as-is "accessing
through the lvalues with type char" and char is aliasing with all types.
GCC does a good job to optimize away the temporary copies introduced
with the change. Ideally copying to a temporary unsigned int array,
doing the calculation, and then copying back to `r_d` will make the code
look better, but unfortunately GCC would fail to optimize away this
temporary array then.
I've not touched the LE optimization in BN_nist_mod_224 because it's
guarded by BN_BITS2!=64, then BN_BITS2 must be 32 and BN_ULONG must be
unsigned int, thus there is no aliasing issue in BN_nist_mod_224.
Fixes #12247.
Reviewed-by: Tom Cosgrove <tom.cosgrove at arm.com>
Reviewed-by: Tomas Mraz <tomas at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/22816)
(cherry picked from commit 990d9ff508070757912c000f0c4132dbb5a0bb0a)
More information about the openssl-commits
mailing list