AES, SHA256 and SHA512 modules can actually replace corresponding
C64x+ modules. This is because C64x+ instructions don't actually
provide "killer-argument" advantage in these modules. As for SHA1,
even though its performance exactly same, C64x+ module is more
responsive to interrupts, i.e. doesn't inhibit them for as long
periods as C64x module.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4265)
While ARMv7 in general is capable of unaligned access, not all instructions
actually are. And trouble is that compiler doesn't seem to differentiate
those capable and incapable of unaligned access. Side effect is that kernel
goes into endless loop retrying same instruction triggering unaligned trap.
Problem was observed in xts128.c and ccm128.c modules. It's possible to
resolve it by using (volatile u32*) casts, but letting STRICT_ALIGNMENT
be feels more appropriate.
(cherry picked from commit 3bdd80521a)
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
As for complementary fips.c modification. Goal is to ensure that
FIPS_signature does not end up in .bss segment, one guaranteed to
be zeroed upon program start-up. One would expect explicitly
initialized values to end up in .data segment, but it turned out
that values explicitly initialized with zeros can end up in .bss.
The modification does not affect program flow, because first byte
was the only one of significance [to FINGERPRINT_premain].
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 34f39b062c)
Special note about additional -pie flag in android-armv7. The initial
reason for adding it is that Android 5 refuses to execute non-PIE
binaries. But what about older systems and previously validated
platforms? It should be noted that flag is not used when compiling
object code, fipscanister.o in this context, only when linking
applications, *supplementary* fips_algvs used during validation
procedure.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 6db8e3bdc9)
Resolved conflicts:
test/fips_algvs.c
Normally it would be generated from a perlasm module, but doing so
would affect existing armv4cpuid.S, which in turn would formally void
previously validated platforms. Hense separate module is generated.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 5837e90f08)
This is achieved by filtering perlasm output through arm-xlate.pl. But note
that it's done only if "flavour" argument is not 'void'. As 'void' is
default value for other ARM targets, permasm output is not actually
filtered on previously validated platforms.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 874faf2ffb)
In the current code, the check isn't redundant.
And in fact the REAL check was missing.
This avoids a NULL-deref crash.
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
Internal pointers in CCM, GCM and XTS contexts should either be
NULL or set to point to the appropriate key schedule. This needs
to be adjusted when copying contexts.
Combination of 2 commits:
370bf1d708c2fd5d79ff
Andy Polyakov
Steve Marquess
Rich Salz
Dr. Stephen Henson
Alan Hryngle