summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Provide crypto_cpu_caps_init() for amd64.jsing2024-10-183-10/+120
| | | | | | | | | | | This is a CPU capability detection implementation in C, with minimal inline assembly (for cpuid and xgetbv). This replaces the assembly mess generated by x86_64cpuid.pl. Rather than populating OPENSSL_ia32cap_P directly with CPUID output, just set the bits that the remaining perlasm checks (namely AESNI, AVX, FXSR, INTEL, HT, MMX, PCLMUL, SSE, SSE2 and SSSE3). ok joshua@ tb@
* Unexport OPENSSL_cpuid_setup and OPENSSL_ia32cap_Ptb2024-08-312-2/+0
| | | | | | | | | This allows us in particular to get rid of the MD Symbols.list which were needed on amd64 and i386 for llvm 16 a while back. OPENSSL_ia32cap_P was never properly exported since the symbols were marked .hidden in the asm. ok beck jsing
* repair bizzare indents; ok tbderaadt2024-08-292-4/+12
|
* Provide and use crypto_arch.h.jsing2024-08-1119-31/+336
| | | | | | | | Provide a per architecture crypto_arch.h - this will be used in a similar manner to bn_arch.h and will allow for architecture specific #defines and static inline functions. Move the HAVE_AES_* and HAVE_RC4_* defines here. ok tb@
* enable -fret-clean on amd64, for libc libcrypto ld.so kernel, and all thederaadt2024-06-041-1/+3
| | | | | ssh tools. The dynamic objects are entirely ret-clean, static binaries will contain a blend of cleaning and non-cleaning callers.
* Always use C functions for AES_{encrypt,decrypt}().jsing2024-03-296-5/+17
| | | | | | | Always provide AES_{encrypt,decrypt}() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Move camellia to primary Makefile.jsing2024-03-2911-40/+10
| | | | These files are now built on all platforms.
* Stop building camellia assembly on amd64 and i386.jsing2024-03-292-5/+8
| | | | | | | This is a legacy algorithm and the assembly is only marginally faster than the C code. Discussed with beck@ and tb@
* Move aes_core.c to the primary Makefile.jsing2024-03-2911-30/+10
| | | | This is now built on all platforms.
* Always use C functions for AES_set_{encrypt,decrypt}_key().jsing2024-03-294-3/+15
| | | | | | | | Always include aes_core.c and provide AES_set_{encrypt,decrypt}_key() via C functions, which then either use a C implementation or call the assembly implementation. ok tb@
* Move wp_block.c to the primary Makefile.jsing2024-03-2911-33/+10
| | | | This is now built on all platforms.
* Stop building whirlpool assembly on amd64 and i386.jsing2024-03-292-6/+3
| | | | | | | This is a legacy algorithm and the assembly is only marginally faster than the C code. Discussed with beck@ and tb@
* Merge aes_cbc.c into aes.c now that aes_cbc.c is used on all platforms.jsing2024-03-2811-21/+16
|
* Make AES_cbc_encrypt() always be a C function.jsing2024-03-282-2/+6
| | | | | | | | Rename the assembly generated functions from AES_cbc_encrypt() to aes_cbc_encrypt_internal(). Always include aes_cbc.c and change it to use defines that are similar to those used in BN. ok tb@
* Remove OPENSSL_UNISTD definetb2024-03-2813-39/+0
|
* Move rc4.c to primary Makefile.jsing2024-03-2811-31/+10
| | | | This is now built on all platforms.
* Use C functions for RC4 public API.jsing2024-03-282-2/+8
| | | | | | | | | | | | | | Rather than having public API switch between C and assembly, always use C functions as entry points, which then call an assembly implementation (if available). This makes it significantly easier to deal with symbol aliasing/namespaces and it also means we benefit from vulnerability prevention provided by the C compiler. Rename the assembly generated functions from RC4() to rc4_internal() and RC4_set_key() to rc4_set_key_internal(). Always include rc4.c and change it to use defines that are similar to those used in BN. ok beck@ joshua@ tb@
* Move des sources to primary Makefile.jsing2024-03-2811-34/+10
| | | | | Now that all platforms use a C des implementation, move it to the primary Makefile.
* Stop building the assembly implementation of des on sparc64.jsing2024-03-281-6/+2
| | | | | | This one was hiding behind an m4 script. Build tested by tb@
* Stop building the assembly implementation of des and ripemd on i386.jsing2024-03-281-6/+2
| | | | | | | | This is the only architecture that has an assembly implementation for these algorithms. There is little to gain from accelerating legacy algorithms on a legacy architecture. Discussed with beck@ and tb@
* Remove unused rc4 parisc assembly.jsing2024-03-271-5/+1
| | | | This is already disabled since it is "about 35% slower than C code".
* Consolidate rc4 code.jsing2024-03-279-18/+17
| | | | Discussed with tb@
* Remove assembly for stitched modes.jsing2024-03-271-4/+1
| | | | | The stitched modes have been removed, so having assembly for them is of little use.
* Move bf_enc.c to the primary Makefile.jsing2024-03-2711-33/+10
| | | | | Now that all architectures are using bf_enc.c, it does not make sense to have it in every Makefile.inc file.
* Stop building the assembly implementation of blowfish on i386.jsing2024-03-271-3/+2
| | | | | | | | This is the only architecture that has an assembly implementation. There is little to gain from accelerating a legacy algorithm on a legacy architecture. ok beck@ tb@
* split the Symbols.list up so that arch specific symbols do not end up everywhererobert2023-11-122-0/+2
| | | | ok tb@
* zap a stray spacetb2023-08-251-2/+2
|
* Remove constructor attribute for OPENSSL_cpuid_setup() on arm/aarch64.jsing2023-07-262-10/+2
| | | | | | | | OPENSSL_cpuid_setup() is invoked via OPENSSL_init_crypto(), whihc is triggered by various entry points to the library. As such, we do not need to invoke it as a constructor. ok tb@
* Provide a libcrypto Makefile.inc for riscv64.jsing2023-07-071-0/+26
| | | | | | | This is currently no different from the existing behaviour and just pulls in the C code that would have previously been built. However, it means that OPENSSL_NO_ASM is no longer being defined by the main libcrypto Makefile, which in turn will allow us to implement assembly optimisations.
* Stop building GF2m assemblytb2023-04-153-8/+2
| | | | | | | GF2m support will be removed shortly. In the interim drop some of this unused code already and let it fall back to the C implementation. ok jsing
* Sprinkle a few BTI instructions into the arm64 assembly files and passkettenis2023-04-052-1/+8
| | | | | | -mmark-bti-property to indicate those now have BTI support. ok jsing@, deraadt@
* Replace bn_sub_part_words() with bn_sub().jsing2023-02-221-2/+1
| | | | | | | | Now that bn_sub() handles word arrays with potentially different lengths, we no longer need bn_sub_part_words() - call bn_sub() instead. This allows us to entirely remove the unnecessarily complex bn_sub_part_words() code. ok tb@
* Enable s2n-bignum word_clz() on amd64.jsing2023-02-161-1/+2
| | | | | | | | | The BN_num_bits_word() function is a hot path, being called more than 80 million times during a libcrypto regress run. The word_clz() implementation uses five instructions to do the same as the generic code that uses more than 60 instructions. Discussed with tb@
* Remove the now empty bn_asm.c.jsing2023-01-316-11/+5
| | | | | | This rather misnamed file (bn_asm.c) previously contained the C code that was needed to build libcrypto bignum on platforms that did not have assembly implementations of the functions it contained.
* Remove sparc related files from libcrypto.jsing2023-01-312-181/+0
| | | | | | | | The sparc platform got retired a while back, however some parts remained hiding in libcrypto. Mop these up (along with the bn_arch.h that I introduced). Spotted by and ok tb@
* Use s2n-bignum assembly implementations for libcrypto bignum on amd64.jsing2023-01-291-2/+11
| | | | | | | This switches the core bignum assembly implementations from x86_64-gcc.c to s2n-bignum for amd64. ok miod@ tb@
* Provide an implementation of bn_sqr() that calls s2n-bignum's bignum_sqr().jsing2023-01-211-1/+6
| | | | ok tb@
* Replace BN_DIV3W with HAVE_BN_DIV_3_WORDS (in bn_arch.h).jsing2023-01-201-2/+1
| | | | ok tb@
* Remove non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_addmiod2023-01-175-124/+6
| | | | | | | interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good. ok jsing@
* Remove unused Elliptic Curve code.jsing2023-01-144-19/+3
| | | | | | | | | | | | | For various reasons, the ecp_nistp* and ecp_nistz* code is unused. While ecp_nistp* was being compiled, it is disabled due to OPENSSL_NO_EC_NISTP_64_GCC_128 being defined. On the other hand, ecp_nistz* was not even being built. We will bring in new versions or alternative versions of such code, if we end up enabling it in the future. For now it is just causing complexity (and grep noise) while trying to improve the EC code. Discussed with tb@
* Move all data tables from .text section to .rodata, and update the code tomiod2023-01-131-3/+1
| | | | | | | fetch them correctly when building PIC. Also drop unused data, and remove --no-execute-only from linker flags. ok kettenis@
* Move all data tables from .text section to .rodata, and update the code tomiod2023-01-131-3/+1
| | | | | | | fetch them correctly when building PIC. Also drop unused data, and remove --no-execute-only from linker flags. ok jsing@ kettenis@
* based upon inspection of obj/*.S ...deraadt2023-01-111-1/+3
| | | | | | | | temporarily force sparc64 libcrypto to be built --no-execute-only because perlasm is still putting tables (intended to be rodata) into text. This will help dynamic executables, but static executables won't be saved by this. But this is temporary because we hope the perlasm problem is fixed soon.
* temporarily force hppa libcrypto to be built --no-execute-only becausederaadt2023-01-111-1/+3
| | | | | | | | perlasm is still putting tables (intended to be rodata) into text. This will help dynamic executables, but static executables won't be saved by this. But this is temporary because we hope the perlasm problem is fixed soon. ok miod
* spelling fixes; from paul tagliamontejmc2022-12-2614-40/+40
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* use the new CPU_ID_AA64ISAR0 sysctl to determine CPU features on arm64robert2022-03-251-5/+55
| | | | ok tb@, deraadt@, kettenis@
* Start disentangling armv7 and aarch64 codetb2022-03-237-2/+508
| | | | | | | | | arm_arch.h and armcap.c are shared between armv7 and aarch64 which results in an inscrutable #ifdef maze. Move copies of these files into arch/{arm,aarch64}/ with appropriate names and some trivial minor adjustments. ok deraadt inoguchi kettenis
* riscv64 openssl configdrahn2021-05-021-0/+154
| | | | | copied from other 64 bit arch ok jsg@
* Retire OpenBSD/sgi.visa2021-05-011-5/+1
| | | | OK deraadt@
* Disable assembly code for powerpc64; more work is needed to make it work.kettenis2020-06-291-8/+9
|