summaryrefslogtreecommitdiffstats
path: root/crypto/aes/build.info
AgeCommit message (Collapse)Author
2022-10-12Add vpaes-loongarch64.pl module.zhuchen
Add 128 bit lsx vector expansion optimization code of Loongarch64 architecture to AES. The test result on the 3A5000 improves performance by about 40%~50%. Signed-off-by: zhuchen <zhuchen@loongson.cn> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19364)
2022-09-05add build support for riscv32 aes zknHongren (Zenithal) Zheng
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/18308)
2022-06-10add build support for riscv64 aes zknHongren (Zenithal) Zheng
Signed-off-by: Hongren (Zenithal) Zheng <i@zenithal.me> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/18197)
2022-05-24Rename x86-32 assembly files from .s to .S.Sebastian Andrzej Siewior
Rename x86-32 assembly files from .s to .S. While processing the .S file gcc will use the pre-processor whic will evaluate macros and ifdef. This is turn will be used to enable the endbr32 opcode based on the __CET__ define. Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/18353)
2022-05-19Add AES implementation in generic riscv64 asmHenry Brausen
This implementation is based on the four-table approach, along the same lines as the non-constant-time implementation in aes_core.c The implementation is in perlasm. Utility functions are defined to automatically stack/unstack registers as needed for prologues and epilogues. See riscv-elf-psabi-doc at https://github.com/riscv-non-isa/riscv-elf-psabi-doc/ for ABI details. Reviewed-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Signed-off-by: Henry Brausen <henry.brausen@vrull.eu> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/17640)
2022-03-09Use Perl to generate bsaes-armv8.STom Cosgrove
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14592)
2022-03-09ARM assembly pack: translate bit-sliced AES implementation to AArch64Ben Avison
Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14592)
2021-10-21Add missing define to enable AES-NI usage on x86 platformTomas Mraz
Fixes #16858 Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/16866)
2021-10-01aarch64: support BTI and pointer authentication in assemblyRuss Butler
This change adds optional support for - Armv8.3-A Pointer Authentication (PAuth) and - Armv8.5-A Branch Target Identification (BTI) features to the perl scripts. Both features can be enabled with additional compiler flags. Unless any of these are enabled explicitly there is no code change at all. The extensions are briefly described below. Please read the appropriate chapters of the Arm Architecture Reference Manual for the complete specification. Scope ----- This change only affects generated assembly code. Armv8.3-A Pointer Authentication -------------------------------- Pointer Authentication extension supports the authentication of the contents of registers before they are used for indirect branching or load. PAuth provides a probabilistic method to detect corruption of register values. PAuth signing instructions generate a Pointer Authentication Code (PAC) based on the value of a register, a seed and a key. The generated PAC is inserted into the original value in the register. A PAuth authentication instruction recomputes the PAC, and if it matches the PAC in the register, restores its original value. In case of a mismatch, an architecturally unmapped address is generated instead. With PAuth, mitigation against ROP (Return-oriented Programming) attacks can be implemented. This is achieved by signing the contents of the link-register (LR) before it is pushed to stack. Once LR is popped, it is authenticated. This way a stack corruption which overwrites the LR on the stack is detectable. The PAuth extension adds several new instructions, some of which are not recognized by older hardware. To support a single codebase for both pre Armv8.3-A targets and newer ones, only NOP-space instructions are added by this patch. These instructions are treated as NOPs on hardware which does not support Armv8.3-A. Furthermore, this patch only considers cases where LR is saved to the stack and then restored before branching to its content. There are cases in the code where LR is pushed to stack but it is not used later. We do not address these cases as they are not affected by PAuth. There are two keys available to sign an instruction address: A and B. PACIASP and PACIBSP only differ in the used keys: A and B, respectively. The keys are typically managed by the operating system. To enable generating code for PAuth compile with -mbranch-protection=<mode>: - standard or pac-ret: add PACIASP and AUTIASP, also enables BTI (read below) - pac-ret+b-key: add PACIBSP and AUTIBSP Armv8.5-A Branch Target Identification -------------------------------------- Branch Target Identification features some new instructions which protect the execution of instructions on guarded pages which are not intended branch targets. If Armv8.5-A is supported by the hardware, execution of an instruction changes the value of PSTATE.BTYPE field. If an indirect branch lands on a guarded page the target instruction must be one of the BTI <jc> flavors, or in case of a direct call or jump it can be any other instruction. If the target instruction is not compatible with the value of PSTATE.BTYPE a Branch Target Exception is generated. In short, indirect jumps are compatible with BTI <j> and <jc> while indirect calls are compatible with BTI <c> and <jc>. Please refer to the specification for the details. Armv8.3-A PACIASP and PACIBSP are implicit branch target identification instructions which are equivalent with BTI c or BTI jc depending on system register configuration. BTI is used to mitigate JOP (Jump-oriented Programming) attacks by limiting the set of instructions which can be jumped to. BTI requires active linker support to mark the pages with BTI-enabled code as guarded. For ELF64 files BTI compatibility is recorded in the .note.gnu.property section. For a shared object or static binary it is required that all linked units support BTI. This means that even a single assembly file without the required note section turns-off BTI for the whole binary or shared object. The new BTI instructions are treated as NOPs on hardware which does not support Armv8.5-A or on pages which are not guarded. To insert this new and optional instruction compile with -mbranch-protection=standard (also enables PAuth) or +bti. When targeting a guarded page from a non-guarded page, weaker compatibility restrictions apply to maintain compatibility between legacy and new code. For detailed rules please refer to the Arm ARM. Compiler support ---------------- Compiler support requires understanding '-mbranch-protection=<mode>' and emitting the appropriate feature macros (__ARM_FEATURE_BTI_DEFAULT and __ARM_FEATURE_PAC_DEFAULT). The current state is the following: ------------------------------------------------------- | Compiler | -mbranch-protection | Feature macros | +----------+---------------------+--------------------+ | clang | 9.0.0 | 11.0.0 | +----------+---------------------+--------------------+ | gcc | 9 | expected in 10.1+ | ------------------------------------------------------- Available Platforms ------------------ Arm Fast Model and QEMU support both extensions. https://developer.arm.com/tools-and-software/simulation-models/fast-models https://www.qemu.org/ Implementation Notes -------------------- This change adds BTI landing pads even to assembly functions which are likely to be directly called only. In these cases, landing pads might be superfluous depending on what code the linker generates. Code size and performance impact for these cases would be negligible. Interaction with C code ----------------------- Pointer Authentication is a per-frame protection while Branch Target Identification can be turned on and off only for all code pages of a whole shared object or static binary. Because of these properties if C/C++ code is compiled without any of the above features but assembly files support any of them unconditionally there is no incompatibility between the two. Useful Links ------------ To fully understand the details of both PAuth and BTI it is advised to read the related chapters of the Arm Architecture Reference Manual (Arm ARM): https://developer.arm.com/documentation/ddi0487/latest/ Additional materials: "Providing protection for complex software" https://developer.arm.com/architectures/learn-the-architecture/providing-protection-for-complex-software Arm Compiler Reference Guide Version 6.14: -mbranch-protection https://developer.arm.com/documentation/101754/0614/armclang-Reference/armclang-Command-line-Options/-mbranch-protection?lang=en Arm C Language Extensions (ACLE) https://developer.arm.com/docs/101028/latest Addional Notes -------------- This patch is a copy of the work done by Tamas Petz in boringssl. It contains the changes from the following commits: aarch64: support BTI and pointer authentication in assembly Change-Id: I4335f92e2ccc8e209c7d68a0a79f1acdf3aeb791 URL: https://boringssl-review.googlesource.com/c/boringssl/+/42084 aarch64: Improve conditional compilation Change-Id: I14902a64e5f403c2b6a117bc9f5fb1a4f4611ebf URL: https://boringssl-review.googlesource.com/c/boringssl/+/43524 aarch64: Fix name of gnu property note section Change-Id: I6c432d1c852129e9c273f6469a8b60e3983671ec URL: https://boringssl-review.googlesource.com/c/boringssl/+/44024 Change-Id: I2d95ebc5e4aeb5610d3b226f9754ee80cf74a9af Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/16674)
2021-05-20Revert "ARM assembly pack: translate bit-sliced AES implementation to AArch64"Pauli
This reverts commit da51566b256e0c0536d5b986e676863b0526bf5e. Fixes #15321 Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15364)
2021-05-14Fix provider library build wrt. AESJuergen Christ
Commit c7978e506b2d1300accd9e696656f9cc94196e6d ("Fix missing $CPUIDDEF in libdefault.a") revealed another problem in the build system on s390. The build of the provider libraries includes the AES system without the proper defines. This causes a build error on s390 now since the CPUIDDEF is present but the prototypes for various AES functions implemented in assembler are missing due to missing preprocessor defines. Fix this by adding the missing defines to all provider libraries. Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15244)
2021-05-14ARM assembly pack: translate bit-sliced AES implementation to AArch64Ben Avison
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/14592)
2021-05-13Add $AESDEF in libdefault.a to fix aes regressionXiaofei Bai
We recently noticed AES algorithms(like aes-xxx-ctr, aes-xxx-gcm,.etc) have significant performance regression on x86_64 platform, and it is because of the missing AES_ASM macro. This PR is to fix it by applying $AESDEF to libdefault.a. Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15225)
2021-05-07Drop libimplementations.aRichard Levitte
libimplementations.a was a nice idea, but had a few flaws: 1. The idea to have common code in libimplementations.a and FIPS sensitive helper functions in libfips.a / libnonfips.a didn't catch on, and we saw full implementation ending up in them instead and not appearing in libimplementations.a at all. 2. Because more or less ALL algorithm implementations were included in libimplementations.a (the idea being that the appropriate objects from it would be selected automatically by the linker when building the shared libraries), it's very hard to find only the implementation source that should go into the FIPS module, with the result that the FIPS checksum mechanism include source files that it shouldn't To mitigate, we drop libimplementations.a, but retain the idea of collecting implementations in static libraries. With that, we not have: libfips.a Includes all implementations that should become part of the FIPS provider. liblegacy.a Includes all implementations that should become part of the legacy provider. libdefault.a Includes all implementations that should become part of the default and base providers. With this, libnonfips.a becomes irrelevant and is dropped. libcommon.a is retained to include common provider code that can be used uniformly by all providers. Fixes #15157 Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15171)
2020-04-16Use build.info, not ifdef for crypto modulesRich Salz
Don't wrap conditionally-compiled files in global ifndef tests. Instead, test if the feature is disabled and, if so, do not compile it. Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org> Reviewed-by: Paul Dale <paul.dale@oracle.com> Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/11263)
2020-01-06Add AES_CBC_HMAC_SHA ciphers to providers.Shane Lontis
Also Add ability for providers to dynamically exclude cipher algorithms. Cipher algorithms are only returned from providers if their capable() method is either NULL, or the method returns 1. This is mainly required for ciphers that only have hardware implementations. If there is no hardware support, then the algorithm needs to be not available. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10146)
2019-10-16Fix missing Assembler definesShane Lontis
Implementations are now spread across several libraries, so the assembler related defines need to be applied to all affected libraries and modules. AES_ASM define was missing from libimplementations.a which disabled AESNI aarch64 changes were made by xkqian. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10180)
2019-10-10Rework how our providers are builtRichard Levitte
We put almost everything in these internal static libraries: libcommon Block building code that can be used by all our implementations, legacy and non-legacy alike. libimplementations All non-legacy algorithm implementations and only them. All the code that ends up here is agnostic to the definitions of FIPS_MODE. liblegacy All legacy implementations. libnonfips Support code for the algorithm implementations. Built with FIPS_MODE undefined. Any code that checks that FIPS_MODE isn't defined must end up in this library. libfips Support code for the algorithm implementations. Built with FIPS_MODE defined. Any code that checks that FIPS_MODE is defined must end up in this library. The FIPS provider module is built from providers/fips/*.c and linked with libimplementations, libcommon and libfips. The Legacy provider module is built from providers/legacy/*.c and linked with liblegacy, libcommon and libcrypto. If module building is disabled, the object files from liblegacy and libcommon are added to libcrypto and the Legacy provider becomes a built-in provider. The Default provider module is built-in, so it ends up being linked with libimplementations, libcommon and libnonfips. For libcrypto in form of static library, the object files from those other libraries are simply being added to libcrypto. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/10088)
2019-09-16build.info: For all assembler generators, remove all argumentsRichard Levitte
Since the arguments are now generated in the build file templates, they should be removed from the build.info files. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9884)
2019-06-18crypto/aes/build.info: Fix AES assembler specsRichard Levitte
Two mistakes were made: 1. AES_ASM for x86 was misplaced 2. sse2 isn't applicable for x86_64 code Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9177)
2019-06-17Move aes_asm_src file information to build.info filesRichard Levitte
Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
2019-06-15Use variables in build.info files where it's worth the whileRichard Levitte
Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9144)
2019-06-03Make basic AES ciphers available from within the FIPS providersMatt Caswell
These ciphers were already provider aware, and were available from the default provider. We move them into the FIPS provider too. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9038)
2019-01-31Build: Remove BEGINRAW / ENDRAW / OVERRIDERichard Levitte
It was an ugly hack to avoid certain problems that are no more. Also added GENERATE lines for perlasm scripts that didn't have that explicitly. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8125)
2018-02-14Harmonize the make variables across all known platforms familiesRichard Levitte
The make variables LIB_CFLAGS, DSO_CFLAGS and so on were used in addition to CFLAGS and so on. This works without problem on Unix and Windows, where options with different purposes (such as -D and -I) can appear anywhere on the command line and get accumulated as they come. This is not necessarely so on VMS. For example, macros must all be collected and given through one /DEFINE, and the same goes for inclusion directories (/INCLUDE). So, to harmonize all platforms, we repurpose make variables starting with LIB_, DSO_ and BIN_ to be all encompassing variables that collects the corresponding values from CFLAGS, CPPFLAGS, DEFINES, INCLUDES and so on together with possible config target values specific for libraries DSOs and programs, and use them instead of the general ones everywhere. This will, for example, allow VMS to use the exact same generators for generated files that go through cpp as all other platforms, something that has been impossible to do safely before now. Reviewed-by: Andy Polyakov <appro@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5357)
2018-01-28Processing GNU-style "make variables" - separate CPP flags from C flagsRichard Levitte
C preprocessor flags get separated from C flags, which has the advantage that we don't get loads of macro definitions and inclusion directory specs when linking shared libraries, DSOs and programs. This is a step to add support for "make variables" when configuring. Reviewed-by: Tim Hudson <tjh@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org> (Merged from https://github.com/openssl/openssl/pull/5177)
2017-10-30s390x assembly pack: extend s390x capability vector.Patrick Steuer
Extend the s390x capability vector to store the longer facility list available from z13 onwards. The bits indicating the vector extensions are set to zero, if the kernel does not enable the vector facility. Also add capability bits returned by the crypto instructions' query functions. Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Andy Polyakov <appro@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org> (Merged from https://github.com/openssl/openssl/pull/4542)
2016-09-02MIPS assembly pack: adapt it for MIPS[32|64]R6.Andy Polyakov
MIPS[32|64]R6 is binary and source incompatible with previous MIPS ISA specifications. Fortunately it's still possible to resolve differences in source code with standard pre-processor and switching to trap-free version of addition and subtraction instructions. Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-04-20Add AES assembly module for Fujitsu SPARC64 X/X+.Andy Polyakov
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-13Add $(LIB_CFLAGS) for any build.info generator that uses $(CFLAGS)Richard Levitte
The reason to do so is that some of the generators detect PIC flags like -fPIC and -KPIC, and those are normally delivered in LD_CFLAGS. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-11crypto/*/build.info: make it work on ARM platforms.Andy Polyakov
Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-03-10Add include directory options for assembler files that include from crypto/Richard Levitte
A few were missed in the previous commit. Closes RT#4412 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-10Add include directory options for assembler files that include from crypto/Richard Levitte
Closes RT#4406 Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-03-09Unified - adapt the generation of aes assembler to use GENERATERichard Levitte
This gets rid of the BEGINRAW..ENDRAW sections in crypto/aes/build.info. This also moves the assembler generating perl scripts to take the output file name as last command line argument, where necessary. Reviewed-by: Andy Polyakov <appro@openssl.org>
2016-03-08SPARCv9 assembly pack: unify build rules and argument handling.Andy Polyakov
Make all scripts produce .S, make interpretation of $(CFLAGS) pre-processor's responsibility, start accepting $(PERLASM_SCHEME). [$(PERLASM_SCHEME) is redundant in this case, because there are no deviataions between Solaris and Linux assemblers. This is purely to unify .pl->.S handling across all targets.] Reviewed-by: Richard Levitte <levitte@openssl.org>
2016-02-13Pass $(CC) to perlasm scripts via the environmentRichard Levitte
It seems that on some platforms, the perlasm scripts call the C compiler for certain checks. These scripts need the environment variable CC to have the C compiler command. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-10unified build scheme: add a "unified" template for Unix MakefileRichard Levitte
This also adds all the raw sections needed for some files. Reviewed-by: Rich Salz <rsalz@openssl.org>
2016-02-01unified build scheme: add build.info filesRichard Levitte
Now that we have the foundation for the "unified" build scheme in place, we add build.info files. They have been generated from the Makefiles in the same directories. Things that are platform specific will appear in later commits. Reviewed-by: Andy Polyakov <appro@openssl.org>