[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