#
ed0f79c7 |
| 01-Feb-2024 |
Richard Levitte |
Fix a few incorrect paths in some build.info files The following files referred to ../liblegacy.a when they should have referred to ../../liblegacy.a. This cause the creation of a myste
Fix a few incorrect paths in some build.info files The following files referred to ../liblegacy.a when they should have referred to ../../liblegacy.a. This cause the creation of a mysterious directory 'crypto/providers', and because of an increased strictness with regards to where directories are created, configuration failure on some platforms. Fixes #23436 Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com> (Merged from https://github.com/openssl/openssl/pull/23452) (cherry picked from commit 667b45454a47959ce2934b74c899662e686993de)
show more ...
|
#
69d4d528 |
| 16-Nov-2023 |
Tomas Mraz |
keccak1600-armv4.pl: Further fix for the DigestSqueeze() support Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Hugo La
keccak1600-armv4.pl: Further fix for the DigestSqueeze() support Reviewed-by: Matt Caswell <matt@openssl.org> Reviewed-by: Shane Lontis <shane.lontis@oracle.com> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/22750)
show more ...
|
#
837f7df8 |
| 07-Sep-2023 |
Phoebe Chen |
riscv: Support SHA-512 family on platforms with vlen >= 128. This patch supports SHA-512, SHA-512/224, SHA-512/256 on platforms with vlen greater than 128, Signed-off-by: Phoebe
riscv: Support SHA-512 family on platforms with vlen >= 128. This patch supports SHA-512, SHA-512/224, SHA-512/256 on platforms with vlen greater than 128, Signed-off-by: Phoebe Chen <phoebe.chen@sifive.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21923)
show more ...
|
#
a1668660 |
| 07-Sep-2023 |
Phoebe Chen |
riscv: Code optimization for SHA-256. Keep SHA-256 constant values in registers to save the loading time. Move the constant loading for sha256 into a separate subroutine. By cre
riscv: Code optimization for SHA-256. Keep SHA-256 constant values in registers to save the loading time. Move the constant loading for sha256 into a separate subroutine. By creating a dedicated sub routine for loading sha256 constants, the code can be made more modular and easier to modify in the future. Relaxing the SHA256 constraint, zvknhb also supports SHA256. Simplify the H and mask initialization flows. Signed-off-by: Phoebe Chen <phoebe.chen@sifive.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21923)
show more ...
|
#
9c22a240 |
| 26-Jan-2023 |
Charalampos Mitrodimas |
riscv: sha512: Provide a Zvknhb-based implementation The upcoming RISC-V vector crypto extensions feature a Zvknhb extension, that provides sha512-specific istructions. This patch pr
riscv: sha512: Provide a Zvknhb-based implementation The upcoming RISC-V vector crypto extensions feature a Zvknhb extension, that provides sha512-specific istructions. This patch provides an implementation that utilizes this extension if available. Tested on QEMU and no regressions observed. Signed-off-by: Charalampos Mitrodimas <charalampos.mitrodimas@vrull.eu> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21923)
show more ...
|
#
17073066 |
| 26-Jan-2023 |
Charalampos Mitrodimas |
riscv: sha256: Provide a Zvknha-based implementation The upcoming RISC-V vector crypto extensions feature a Zvknha extension, that provides sha256-specific instructions. This patch p
riscv: sha256: Provide a Zvknha-based implementation The upcoming RISC-V vector crypto extensions feature a Zvknha extension, that provides sha256-specific instructions. This patch provides an implementation that utilizes this extension if available. Tested on QEMU and no regressions observed. Signed-off-by: Charalampos Mitrodimas <charalampos.mitrodimas@vrull.eu> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Paul Dale <pauli@openssl.org> Reviewed-by: Hugo Landau <hlandau@openssl.org> (Merged from https://github.com/openssl/openssl/pull/21923)
show more ...
|
#
a8b238f0 |
| 07-Jul-2022 |
Juergen Christ |
Fix SHA, SHAKE, and KECCAK ASM flag passing Flags for ASM implementations of SHA, SHAKE, and KECCAK were only passed to the FIPS provider and not to the default or legacy provider. This
Fix SHA, SHAKE, and KECCAK ASM flag passing Flags for ASM implementations of SHA, SHAKE, and KECCAK were only passed to the FIPS provider and not to the default or legacy provider. This left some potential for optimization. Pass the correct flags also to these providers. Signed-off-by: Juergen Christ <jchrist@linux.ibm.com> Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Patrick Steuer <patrick.steuer@de.ibm.com> Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/18747)
show more ...
|
#
9968c775 |
| 19-May-2022 |
Sebastian Andrzej Siewior |
Rename x86-32 assembly files from .s to .S. 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. T
Rename x86-32 assembly files from .s to .S. 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)
show more ...
|
#
19e277dd |
| 28-Aug-2021 |
Russ Butler |
aarch64: support BTI and pointer authentication in assembly This change adds optional support for - Armv8.3-A Pointer Authentication (PAuth) and - Armv8.5-A Branch Target Identificat
aarch64: support BTI and pointer authentication in assembly 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)
show more ...
|
#
3d178db7 |
| 18-Jun-2021 |
Tomas Mraz |
ppccap.c: Split out algorithm-specific functions Fixes #13336 Reviewed-by: Paul Dale <pauli@openssl.org> (Merged from https://github.com/openssl/openssl/pull/15828)
|
Revision tags: openssl-3.0.0-alpha17, openssl-3.0.0-alpha16 |
|
#
848af5e8 |
| 06-May-2021 |
Richard Levitte |
Drop libimplementations.a 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 funct
Drop libimplementations.a 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)
show more ...
|
Revision tags: openssl-3.0.0-alpha15, openssl-3.0.0-alpha14, OpenSSL_1_1_1k, openssl-3.0.0-alpha13, openssl-3.0.0-alpha12, OpenSSL_1_1_1j, openssl-3.0.0-alpha11, openssl-3.0.0-alpha10, OpenSSL_1_1_1i, openssl-3.0.0-alpha9, openssl-3.0.0-alpha8, openssl-3.0.0-alpha7, OpenSSL_1_1_1h, openssl-3.0.0-alpha6, openssl-3.0.0-alpha5, openssl-3.0.0-alpha4, openssl-3.0.0-alpha3, openssl-3.0.0-alpha2, openssl-3.0.0-alpha1, OpenSSL_1_1_1g, OpenSSL_1_1_1f, OpenSSL_1_1_1e, OpenSSL_1_0_2u |
|
#
64fd90fb |
| 15-Oct-2019 |
Shane Lontis |
Fix missing Assembler defines Implementations are now spread across several libraries, so the assembler related defines need to be applied to all affected libraries and modules.
Fix missing Assembler defines 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)
show more ...
|
#
dec95d75 |
| 03-Oct-2019 |
Richard Levitte |
Rework how our providers are built We put almost everything in these internal static libraries: libcommon Block building code that can be used by all
Rework how our providers are built 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)
show more ...
|
#
a1c8befd |
| 12-Sep-2019 |
Richard Levitte |
build.info: For all assembler generators, remove all arguments Since the arguments are now generated in the build file templates, they should be removed from the build.info files.
build.info: For all assembler generators, remove all arguments 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)
show more ...
|
Revision tags: OpenSSL_1_0_2t, OpenSSL_1_1_0l, OpenSSL_1_1_1d |
|
#
8c0098a8 |
| 16-Jun-2019 |
Richard Levitte |
Move keccak1600_asm_src file information to build.info files Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
|
#
edc7851a |
| 16-Jun-2019 |
Richard Levitte |
Move sha1_asm_src file information to build.info files Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/9166)
|
#
07c244f0 |
| 12-Jun-2019 |
Richard Levitte |
Use variables in build.info files where it's worth the while Reviewed-by: Shane Lontis <shane.lontis@oracle.com> (Merged from https://github.com/openssl/openssl/pull/9144)
|
Revision tags: OpenSSL_1_1_1c, OpenSSL_1_1_0k, OpenSSL_1_0_2s |
|
#
d5e5e2ff |
| 11-Apr-2019 |
Shane Lontis |
Move digests to providers Move digest code into the relevant providers (fips, default, legacy). The headers are temporarily moved to be internal, and will be moved into providers aft
Move digests to providers Move digest code into the relevant providers (fips, default, legacy). The headers are temporarily moved to be internal, and will be moved into providers after all external references are resolved. The deprecated digest code can not be removed until EVP_PKEY (signing) is supported by providers. EVP_MD data can also not yet be cleaned up for the same reasons. Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8763)
show more ...
|
#
9efa0ae0 |
| 20-Mar-2019 |
Matt Caswell |
Create a FIPS provider and put SHA256 in it Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/8537)
|
Revision tags: OpenSSL_1_0_2r, OpenSSL_1_1_1b |
|
#
77adb75e |
| 30-Jan-2019 |
Richard Levitte |
Build: Remove BEGINRAW / ENDRAW / OVERRIDE 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 ex
Build: Remove BEGINRAW / ENDRAW / OVERRIDE 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)
show more ...
|
Revision tags: OpenSSL_1_0_2q, OpenSSL_1_1_0j, OpenSSL_1_1_1a, OpenSSL_1_1_1, OpenSSL_1_1_1-pre9, OpenSSL_1_0_2p, OpenSSL_1_1_0i, OpenSSL_1_1_1-pre8, OpenSSL_1_1_1-pre7, OpenSSL_1_1_1-pre6 |
|
#
40ab6b85 |
| 22-Apr-2018 |
Andy Polyakov |
00-base-templates.conf: wire keccak1600-armv4 module. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6042)
|
#
35710695 |
| 22-Apr-2018 |
Andy Polyakov |
00-base-templates.conf: wire keccak1600-ppc64 module. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6042)
|
#
fe46035d |
| 22-Apr-2018 |
Andy Polyakov |
00-base-templates.conf: wire keccak1600-s390x module. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6042)
|
#
eefc485b |
| 22-Apr-2018 |
Andy Polyakov |
00-base-templates.conf: wire keccak1600-armv8 module. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6042)
|
#
1018a725 |
| 22-Apr-2018 |
Andy Polyakov |
00-base-templates.conf: wire keccak1600-x86_64 module. Reviewed-by: Richard Levitte <levitte@openssl.org> (Merged from https://github.com/openssl/openssl/pull/6042)
|