2017-04-04 22:21:43 +01:00
|
|
|
include_directories(../../include)
|
|
|
|
|
2018-08-10 16:30:55 +01:00
|
|
|
if(${ARCH} STREQUAL "x86_64")
|
2017-04-04 22:21:43 +01:00
|
|
|
set(
|
|
|
|
BCM_ASM_SOURCES
|
|
|
|
|
2017-04-15 00:19:16 +01:00
|
|
|
aesni-gcm-x86_64.${ASM_EXT}
|
|
|
|
aesni-x86_64.${ASM_EXT}
|
|
|
|
aes-x86_64.${ASM_EXT}
|
2019-01-09 03:35:56 +00:00
|
|
|
ghash-ssse3-x86_64.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
ghash-x86_64.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
md5-x86_64.${ASM_EXT}
|
2017-05-02 22:25:39 +01:00
|
|
|
p256-x86_64-asm.${ASM_EXT}
|
2018-11-06 23:18:56 +00:00
|
|
|
p256_beeu-x86_64-asm.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
rdrand-x86_64.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
rsaz-avx2.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
sha1-x86_64.${ASM_EXT}
|
|
|
|
sha256-x86_64.${ASM_EXT}
|
|
|
|
sha512-x86_64.${ASM_EXT}
|
2017-04-13 19:00:24 +01:00
|
|
|
vpaes-x86_64.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
x86_64-mont5.${ASM_EXT}
|
|
|
|
x86_64-mont.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2018-08-10 16:30:55 +01:00
|
|
|
if(${ARCH} STREQUAL "x86")
|
2017-04-04 22:21:43 +01:00
|
|
|
set(
|
|
|
|
BCM_ASM_SOURCES
|
|
|
|
|
2017-04-15 00:19:16 +01:00
|
|
|
aes-586.${ASM_EXT}
|
|
|
|
aesni-x86.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
bn-586.${ASM_EXT}
|
|
|
|
co-586.${ASM_EXT}
|
2019-02-24 06:49:14 +00:00
|
|
|
ghash-ssse3-x86.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
ghash-x86.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
md5-586.${ASM_EXT}
|
|
|
|
sha1-586.${ASM_EXT}
|
|
|
|
sha256-586.${ASM_EXT}
|
|
|
|
sha512-586.${ASM_EXT}
|
2017-04-13 19:00:24 +01:00
|
|
|
vpaes-x86.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
x86-mont.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2018-08-10 16:30:55 +01:00
|
|
|
if(${ARCH} STREQUAL "arm")
|
2017-04-04 22:21:43 +01:00
|
|
|
set(
|
|
|
|
BCM_ASM_SOURCES
|
|
|
|
|
2017-04-13 19:00:24 +01:00
|
|
|
aes-armv4.${ASM_EXT}
|
|
|
|
aesv8-armx.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
armv4-mont.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
bsaes-armv7.${ASM_EXT}
|
2017-04-13 19:38:40 +01:00
|
|
|
ghash-armv4.${ASM_EXT}
|
|
|
|
ghashv8-armx.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
sha1-armv4-large.${ASM_EXT}
|
|
|
|
sha256-armv4.${ASM_EXT}
|
|
|
|
sha512-armv4.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2018-08-10 16:30:55 +01:00
|
|
|
if(${ARCH} STREQUAL "aarch64")
|
2017-04-04 22:21:43 +01:00
|
|
|
set(
|
|
|
|
BCM_ASM_SOURCES
|
|
|
|
|
2017-04-15 00:19:16 +01:00
|
|
|
aesv8-armx.${ASM_EXT}
|
2017-04-28 22:47:06 +01:00
|
|
|
armv8-mont.${ASM_EXT}
|
2019-03-10 05:14:49 +00:00
|
|
|
ghash-neon-armv8.${ASM_EXT}
|
2017-04-15 00:19:16 +01:00
|
|
|
ghashv8-armx.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
sha1-armv8.${ASM_EXT}
|
|
|
|
sha256-armv8.${ASM_EXT}
|
|
|
|
sha512-armv8.${ASM_EXT}
|
Enable vpaes for aarch64, with CTR optimizations.
This patches vpaes-armv8.pl to add vpaes_ctr32_encrypt_blocks. CTR mode
is by far the most important mode these days. It should have access to
_vpaes_encrypt_2x, which gives a considerable speed boost. Also exclude
vpaes_ecb_* as they're not even used.
For iOS, this change is completely a no-op. iOS ARMv8 always has crypto
extensions, and we already statically drop all other AES
implementations.
Android ARMv8 is *not* required to have crypto extensions, but every
ARMv8 device I've seen has them. For those, it is a no-op
performance-wise and a win on size. vpaes appears to be about 5.6KiB
smaller than the tables. ARMv8 always makes SIMD (NEON) available, so we
can statically drop aes_nohw.
In theory, however, crypto-less Android ARMv8 is possible. Today such
chips get a variable-time AES. This CL fixes this, but the performance
story is complex.
The Raspberry Pi 3 is not Android but has a Cortex-A53 chip
without crypto extensions. (But the official images are 32-bit, so even
this is slightly artificial...) There, vpaes is a performance win.
Raspberry Pi 3, Model B+, Cortex-A53
Before:
Did 265000 AES-128-GCM (16 bytes) seal operations in 1003312us (264125.2 ops/sec): 4.2 MB/s
Did 44000 AES-128-GCM (256 bytes) seal operations in 1002141us (43906.0 ops/sec): 11.2 MB/s
Did 9394 AES-128-GCM (1350 bytes) seal operations in 1032104us (9101.8 ops/sec): 12.3 MB/s
Did 1562 AES-128-GCM (8192 bytes) seal operations in 1008982us (1548.1 ops/sec): 12.7 MB/s
After:
Did 277000 AES-128-GCM (16 bytes) seal operations in 1001884us (276479.1 ops/sec): 4.4 MB/s
Did 52000 AES-128-GCM (256 bytes) seal operations in 1001480us (51923.2 ops/sec): 13.3 MB/s
Did 11000 AES-128-GCM (1350 bytes) seal operations in 1007979us (10912.9 ops/sec): 14.7 MB/s
Did 2013 AES-128-GCM (8192 bytes) seal operations in 1085545us (1854.4 ops/sec): 15.2 MB/s
The Pixel 3 has a Cortex-A75 with crypto extensions, so it would never
run this code. However, artificially ignoring them gives another data
point (ARM documentation[*] suggests the extensions are still optional
on a Cortex-A75.) Sadly, vpaes no longer wins on perf over aes_nohw.
But, it is constant-time:
Pixel 3, AES/PMULL extensions ignored, Cortex-A75:
Before:
Did 2102000 AES-128-GCM (16 bytes) seal operations in 1000378us (2101205.7 ops/sec): 33.6 MB/s
Did 358000 AES-128-GCM (256 bytes) seal operations in 1002658us (357051.0 ops/sec): 91.4 MB/s
Did 75000 AES-128-GCM (1350 bytes) seal operations in 1012830us (74049.9 ops/sec): 100.0 MB/s
Did 13000 AES-128-GCM (8192 bytes) seal operations in 1036524us (12541.9 ops/sec): 102.7 MB/s
After:
Did 1453000 AES-128-GCM (16 bytes) seal operations in 1000213us (1452690.6 ops/sec): 23.2 MB/s
Did 285000 AES-128-GCM (256 bytes) seal operations in 1002227us (284366.7 ops/sec): 72.8 MB/s
Did 60000 AES-128-GCM (1350 bytes) seal operations in 1016106us (59049.0 ops/sec): 79.7 MB/s
Did 11000 AES-128-GCM (8192 bytes) seal operations in 1094184us (10053.2 ops/sec): 82.4 MB/s
Note the numbers above run with PMULL off, so the slow GHASH is
dampening the regression. If we test aes_nohw and vpaes paired with
PMULL on, the 20% perf hit becomes a 31% hit. The PMULL-less variant is
more likely to represent a real chip.
This is consistent with upstream's note in the comment, though it is
unclear if 20% is the right order of magnitude: "these results are worse
than scalar compiler-generated code, but it's constant-time and
therefore preferred".
[*] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100458_0301_00_en/lau1442495529696.html
Bug: 246
Change-Id: If1dc87f5131fce742052498295476fbae4628dbf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35026
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2019-02-25 21:47:51 +00:00
|
|
|
vpaes-armv8.${ASM_EXT}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
2018-08-10 16:30:55 +01:00
|
|
|
if(${ARCH} STREQUAL "ppc64le")
|
2017-04-13 19:00:24 +01:00
|
|
|
set(
|
2017-05-26 01:07:29 +01:00
|
|
|
BCM_ASM_SOURCES
|
2017-04-13 19:00:24 +01:00
|
|
|
|
|
|
|
aesp8-ppc.${ASM_EXT}
|
2017-04-13 19:38:40 +01:00
|
|
|
ghashp8-ppc.${ASM_EXT}
|
2017-04-13 19:00:24 +01:00
|
|
|
)
|
|
|
|
endif()
|
|
|
|
|
|
|
|
perlasm(aes-586.${ASM_EXT} aes/asm/aes-586.pl)
|
|
|
|
perlasm(aes-armv4.${ASM_EXT} aes/asm/aes-armv4.pl)
|
2017-04-13 19:38:40 +01:00
|
|
|
perlasm(aesni-gcm-x86_64.${ASM_EXT} modes/asm/aesni-gcm-x86_64.pl)
|
2017-04-13 19:00:24 +01:00
|
|
|
perlasm(aesni-x86_64.${ASM_EXT} aes/asm/aesni-x86_64.pl)
|
|
|
|
perlasm(aesni-x86.${ASM_EXT} aes/asm/aesni-x86.pl)
|
|
|
|
perlasm(aesp8-ppc.${ASM_EXT} aes/asm/aesp8-ppc.pl)
|
|
|
|
perlasm(aesv8-armx.${ASM_EXT} aes/asm/aesv8-armx.pl)
|
|
|
|
perlasm(aes-x86_64.${ASM_EXT} aes/asm/aes-x86_64.pl)
|
2017-04-28 22:47:06 +01:00
|
|
|
perlasm(armv4-mont.${ASM_EXT} bn/asm/armv4-mont.pl)
|
|
|
|
perlasm(armv8-mont.${ASM_EXT} bn/asm/armv8-mont.pl)
|
|
|
|
perlasm(bn-586.${ASM_EXT} bn/asm/bn-586.pl)
|
2017-04-13 19:00:24 +01:00
|
|
|
perlasm(bsaes-armv7.${ASM_EXT} aes/asm/bsaes-armv7.pl)
|
2017-04-28 22:47:06 +01:00
|
|
|
perlasm(co-586.${ASM_EXT} bn/asm/co-586.pl)
|
2017-04-13 19:38:40 +01:00
|
|
|
perlasm(ghash-armv4.${ASM_EXT} modes/asm/ghash-armv4.pl)
|
|
|
|
perlasm(ghashp8-ppc.${ASM_EXT} modes/asm/ghashp8-ppc.pl)
|
|
|
|
perlasm(ghashv8-armx.${ASM_EXT} modes/asm/ghashv8-armx.pl)
|
2019-03-10 05:14:49 +00:00
|
|
|
perlasm(ghash-neon-armv8.${ASM_EXT} modes/asm/ghash-neon-armv8.pl)
|
2019-01-09 03:35:56 +00:00
|
|
|
perlasm(ghash-ssse3-x86_64.${ASM_EXT} modes/asm/ghash-ssse3-x86_64.pl)
|
2019-02-24 06:49:14 +00:00
|
|
|
perlasm(ghash-ssse3-x86.${ASM_EXT} modes/asm/ghash-ssse3-x86.pl)
|
2017-04-13 19:38:40 +01:00
|
|
|
perlasm(ghash-x86_64.${ASM_EXT} modes/asm/ghash-x86_64.pl)
|
|
|
|
perlasm(ghash-x86.${ASM_EXT} modes/asm/ghash-x86.pl)
|
2017-04-04 22:21:43 +01:00
|
|
|
perlasm(md5-586.${ASM_EXT} md5/asm/md5-586.pl)
|
|
|
|
perlasm(md5-x86_64.${ASM_EXT} md5/asm/md5-x86_64.pl)
|
2017-05-02 22:25:39 +01:00
|
|
|
perlasm(p256-x86_64-asm.${ASM_EXT} ec/asm/p256-x86_64-asm.pl)
|
2018-11-06 23:18:56 +00:00
|
|
|
perlasm(p256_beeu-x86_64-asm.${ASM_EXT} ec/asm/p256_beeu-x86_64-asm.pl)
|
2017-04-14 19:16:20 +01:00
|
|
|
perlasm(rdrand-x86_64.${ASM_EXT} rand/asm/rdrand-x86_64.pl)
|
2017-04-28 22:47:06 +01:00
|
|
|
perlasm(rsaz-avx2.${ASM_EXT} bn/asm/rsaz-avx2.pl)
|
2017-04-04 22:21:43 +01:00
|
|
|
perlasm(sha1-586.${ASM_EXT} sha/asm/sha1-586.pl)
|
|
|
|
perlasm(sha1-armv4-large.${ASM_EXT} sha/asm/sha1-armv4-large.pl)
|
|
|
|
perlasm(sha1-armv8.${ASM_EXT} sha/asm/sha1-armv8.pl)
|
|
|
|
perlasm(sha1-x86_64.${ASM_EXT} sha/asm/sha1-x86_64.pl)
|
|
|
|
perlasm(sha256-586.${ASM_EXT} sha/asm/sha256-586.pl)
|
|
|
|
perlasm(sha256-armv4.${ASM_EXT} sha/asm/sha256-armv4.pl)
|
|
|
|
perlasm(sha256-armv8.${ASM_EXT} sha/asm/sha512-armv8.pl)
|
|
|
|
perlasm(sha256-x86_64.${ASM_EXT} sha/asm/sha512-x86_64.pl)
|
|
|
|
perlasm(sha512-586.${ASM_EXT} sha/asm/sha512-586.pl)
|
|
|
|
perlasm(sha512-armv4.${ASM_EXT} sha/asm/sha512-armv4.pl)
|
|
|
|
perlasm(sha512-armv8.${ASM_EXT} sha/asm/sha512-armv8.pl)
|
|
|
|
perlasm(sha512-x86_64.${ASM_EXT} sha/asm/sha512-x86_64.pl)
|
Enable vpaes for aarch64, with CTR optimizations.
This patches vpaes-armv8.pl to add vpaes_ctr32_encrypt_blocks. CTR mode
is by far the most important mode these days. It should have access to
_vpaes_encrypt_2x, which gives a considerable speed boost. Also exclude
vpaes_ecb_* as they're not even used.
For iOS, this change is completely a no-op. iOS ARMv8 always has crypto
extensions, and we already statically drop all other AES
implementations.
Android ARMv8 is *not* required to have crypto extensions, but every
ARMv8 device I've seen has them. For those, it is a no-op
performance-wise and a win on size. vpaes appears to be about 5.6KiB
smaller than the tables. ARMv8 always makes SIMD (NEON) available, so we
can statically drop aes_nohw.
In theory, however, crypto-less Android ARMv8 is possible. Today such
chips get a variable-time AES. This CL fixes this, but the performance
story is complex.
The Raspberry Pi 3 is not Android but has a Cortex-A53 chip
without crypto extensions. (But the official images are 32-bit, so even
this is slightly artificial...) There, vpaes is a performance win.
Raspberry Pi 3, Model B+, Cortex-A53
Before:
Did 265000 AES-128-GCM (16 bytes) seal operations in 1003312us (264125.2 ops/sec): 4.2 MB/s
Did 44000 AES-128-GCM (256 bytes) seal operations in 1002141us (43906.0 ops/sec): 11.2 MB/s
Did 9394 AES-128-GCM (1350 bytes) seal operations in 1032104us (9101.8 ops/sec): 12.3 MB/s
Did 1562 AES-128-GCM (8192 bytes) seal operations in 1008982us (1548.1 ops/sec): 12.7 MB/s
After:
Did 277000 AES-128-GCM (16 bytes) seal operations in 1001884us (276479.1 ops/sec): 4.4 MB/s
Did 52000 AES-128-GCM (256 bytes) seal operations in 1001480us (51923.2 ops/sec): 13.3 MB/s
Did 11000 AES-128-GCM (1350 bytes) seal operations in 1007979us (10912.9 ops/sec): 14.7 MB/s
Did 2013 AES-128-GCM (8192 bytes) seal operations in 1085545us (1854.4 ops/sec): 15.2 MB/s
The Pixel 3 has a Cortex-A75 with crypto extensions, so it would never
run this code. However, artificially ignoring them gives another data
point (ARM documentation[*] suggests the extensions are still optional
on a Cortex-A75.) Sadly, vpaes no longer wins on perf over aes_nohw.
But, it is constant-time:
Pixel 3, AES/PMULL extensions ignored, Cortex-A75:
Before:
Did 2102000 AES-128-GCM (16 bytes) seal operations in 1000378us (2101205.7 ops/sec): 33.6 MB/s
Did 358000 AES-128-GCM (256 bytes) seal operations in 1002658us (357051.0 ops/sec): 91.4 MB/s
Did 75000 AES-128-GCM (1350 bytes) seal operations in 1012830us (74049.9 ops/sec): 100.0 MB/s
Did 13000 AES-128-GCM (8192 bytes) seal operations in 1036524us (12541.9 ops/sec): 102.7 MB/s
After:
Did 1453000 AES-128-GCM (16 bytes) seal operations in 1000213us (1452690.6 ops/sec): 23.2 MB/s
Did 285000 AES-128-GCM (256 bytes) seal operations in 1002227us (284366.7 ops/sec): 72.8 MB/s
Did 60000 AES-128-GCM (1350 bytes) seal operations in 1016106us (59049.0 ops/sec): 79.7 MB/s
Did 11000 AES-128-GCM (8192 bytes) seal operations in 1094184us (10053.2 ops/sec): 82.4 MB/s
Note the numbers above run with PMULL off, so the slow GHASH is
dampening the regression. If we test aes_nohw and vpaes paired with
PMULL on, the 20% perf hit becomes a 31% hit. The PMULL-less variant is
more likely to represent a real chip.
This is consistent with upstream's note in the comment, though it is
unclear if 20% is the right order of magnitude: "these results are worse
than scalar compiler-generated code, but it's constant-time and
therefore preferred".
[*] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100458_0301_00_en/lau1442495529696.html
Bug: 246
Change-Id: If1dc87f5131fce742052498295476fbae4628dbf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/35026
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
2019-02-25 21:47:51 +00:00
|
|
|
perlasm(vpaes-armv8.${ASM_EXT} aes/asm/vpaes-armv8.pl)
|
2017-04-13 19:00:24 +01:00
|
|
|
perlasm(vpaes-x86_64.${ASM_EXT} aes/asm/vpaes-x86_64.pl)
|
|
|
|
perlasm(vpaes-x86.${ASM_EXT} aes/asm/vpaes-x86.pl)
|
2017-04-28 22:47:06 +01:00
|
|
|
perlasm(x86_64-mont5.${ASM_EXT} bn/asm/x86_64-mont5.pl)
|
|
|
|
perlasm(x86_64-mont.${ASM_EXT} bn/asm/x86_64-mont.pl)
|
|
|
|
perlasm(x86-mont.${ASM_EXT} bn/asm/x86-mont.pl)
|
2017-04-04 22:21:43 +01:00
|
|
|
|
2017-05-17 21:05:50 +01:00
|
|
|
if(FIPS_DELOCATE)
|
2018-07-19 18:03:56 +01:00
|
|
|
if(OPENSSL_NO_ASM)
|
|
|
|
# If OPENSSL_NO_ASM was defined then ASM will not have been enabled, but in
|
|
|
|
# FIPS mode we have to have it because the module build requires going via
|
|
|
|
# textual assembly.
|
|
|
|
enable_language(ASM)
|
|
|
|
endif()
|
|
|
|
|
2017-04-04 22:21:43 +01:00
|
|
|
add_library(
|
|
|
|
bcm_c_generated_asm
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
|
|
|
|
bcm.c
|
|
|
|
)
|
|
|
|
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
add_dependencies(bcm_c_generated_asm global_target)
|
|
|
|
|
2017-04-26 23:04:48 +01:00
|
|
|
set_target_properties(bcm_c_generated_asm PROPERTIES COMPILE_OPTIONS "-S")
|
|
|
|
set_target_properties(bcm_c_generated_asm PROPERTIES POSITION_INDEPENDENT_CODE ON)
|
|
|
|
|
2018-09-13 22:37:28 +01:00
|
|
|
go_executable(delocate boringssl.googlesource.com/boringssl/util/fipstools/delocate)
|
2017-04-04 22:21:43 +01:00
|
|
|
add_custom_command(
|
|
|
|
OUTPUT bcm-delocated.S
|
2018-09-13 22:37:28 +01:00
|
|
|
COMMAND ./delocate -a $<TARGET_FILE:bcm_c_generated_asm> -o bcm-delocated.S ${BCM_ASM_SOURCES}
|
|
|
|
DEPENDS bcm_c_generated_asm delocate ${BCM_ASM_SOURCES}
|
|
|
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
bcm_hashunset
|
|
|
|
|
|
|
|
STATIC
|
|
|
|
|
|
|
|
bcm-delocated.S
|
|
|
|
)
|
|
|
|
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
add_dependencies(bcm_hashunset global_target)
|
|
|
|
|
2017-04-04 22:21:43 +01:00
|
|
|
set_target_properties(bcm_hashunset PROPERTIES POSITION_INDEPENDENT_CODE ON)
|
|
|
|
set_target_properties(bcm_hashunset PROPERTIES LINKER_LANGUAGE C)
|
|
|
|
|
2018-09-26 22:21:25 +01:00
|
|
|
go_executable(inject_hash
|
|
|
|
boringssl.googlesource.com/boringssl/util/fipstools/inject_hash)
|
2017-04-04 22:21:43 +01:00
|
|
|
add_custom_command(
|
|
|
|
OUTPUT bcm.o
|
2018-09-26 22:21:25 +01:00
|
|
|
COMMAND ./inject_hash -o bcm.o -in-archive $<TARGET_FILE:bcm_hashunset>
|
|
|
|
DEPENDS bcm_hashunset inject_hash
|
2018-09-13 22:37:28 +01:00
|
|
|
WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
|
2017-04-04 22:21:43 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
# The outputs of add_custom_command cannot be referenced outside of the
|
|
|
|
# CMakeLists.txt that defines it. Thus we have to wrap bcm.o in a custom target
|
|
|
|
# so that crypto can depend on it.
|
|
|
|
add_custom_target(bcm_o_target DEPENDS bcm.o)
|
|
|
|
|
|
|
|
add_library(
|
|
|
|
fipsmodule
|
|
|
|
|
|
|
|
OBJECT
|
|
|
|
|
|
|
|
is_fips.c
|
|
|
|
)
|
|
|
|
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
add_dependencies(fipsmodule global_target)
|
|
|
|
|
2017-04-04 22:21:43 +01:00
|
|
|
set_target_properties(fipsmodule PROPERTIES LINKER_LANGUAGE C)
|
|
|
|
else()
|
|
|
|
add_library(
|
|
|
|
fipsmodule
|
|
|
|
|
|
|
|
OBJECT
|
|
|
|
|
|
|
|
bcm.c
|
|
|
|
is_fips.c
|
|
|
|
|
|
|
|
${BCM_ASM_SOURCES}
|
|
|
|
)
|
Support symbol prefixes
- In base.h, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols.h
- In all .S files, if BORINGSSL_PREFIX is defined, include
boringssl_prefix_symbols_asm.h
- In base.h, BSSL_NAMESPACE_BEGIN and BSSL_NAMESPACE_END are
defined with appropriate values depending on whether
BORINGSSL_PREFIX is defined; these macros are used in place
of 'namespace bssl {' and '}'
- Add util/make_prefix_headers.go, which takes a list of symbols
and auto-generates the header files mentioned above
- In CMakeLists.txt, if BORINGSSL_PREFIX and BORINGSSL_PREFIX_SYMBOLS
are defined, run util/make_prefix_headers.go to generate header
files
- In various CMakeLists.txt files, add "global_target" that all
targets depend on to give us a place to hook logic that must run
before all other targets (in particular, the header file generation
logic)
- Document this in BUILDING.md, including the fact that it is
the caller's responsibility to provide the symbol list and keep it
up to date
- Note that this scheme has not been tested on Windows, and likely
does not work on it; Windows support will need to be added in a
future commit
Change-Id: If66a7157f46b5b66230ef91e15826b910cf979a2
Reviewed-on: https://boringssl-review.googlesource.com/31364
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
Reviewed-by: David Benjamin <davidben@google.com>
2018-08-27 02:53:36 +01:00
|
|
|
|
|
|
|
add_dependencies(fipsmodule global_target)
|
2017-04-04 22:21:43 +01:00
|
|
|
endif()
|