summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
|
* Switch back to bn_mul_mont_int since the bn_mul_mont_fpu64 code isn'tkettenis2020-06-281-3/+3
| | | | | hooked up and the lack of a bn_mul_mont_int implementation results in undefined references.
* Accidentally doubled these files on first commit. Correcting.drahn2020-06-262-194/+1
|
* Intial attempt at powerpc64 libcrypto pieces.drahn2020-06-252-0/+386
| | | | just commit this kettenis@
* Add cpuid support for arm64 so that we can recognize whichpatrick2019-07-021-1/+4
| | | | | | hardware crypto features are available. "no objections" kettenis@
* Remove commented out rc5 bitstb2019-05-117-20/+6
|
* sprinkle a few missing dependencies on perl scripts internal bits.espie2017-08-202-8/+14
| | | | 'it works' deraadt@
* Add support for AArch64.patrick2017-01-112-0/+182
|
* Disable ec assembly for amd64 pending fixes for ssh, and bumpbeck2016-11-111-4/+4
| | | | majors appropriately
* Ride the current major bump and enable assembler code for nist 256p curve,miod2016-11-044-3/+19
| | | | | | | | on amd64 only for now. Stanzas to enable it on arm, i386 and sparc64 are provided but commented out for lack of testing due to the machine room being currently in storage. ok jsing@
* Remove I386_ONLY define. It was only used to prefer amiod2016-11-0411-33/+0
| | | | | | | faster-on-genuine-80386-but-slower-on-80486-onwards innstruction sequence in the SHA512 code, and had not been enabled in years, if at all. ok tom@ bcook@
* Less vax.jsing2016-09-043-614/+0
| | | | ok deraadt@
* remove hppa64 port, which we never got going beyond broken single users.deraadt2016-05-111-157/+0
| | | | | | hppa reverse-stack gives us a valuable test case, but most developers don't have a 2nd one to proceed further with this. ok kettenis
* Pass "openbsd" instead of "openbsd-elf" as the "flavour" to the perl assemblermiod2015-09-111-2/+2
| | | | | machinery. OpenBSD has never been not ELF on amd64, and changing this will actually make -portable life slightly easier in the near future.
* Disable ENGINE_load_dynamic (dynamic engine support).bcook2015-06-1913-13/+0
| | | | | | | We do not build, test or ship any dynamic engines, so we can remove the dynamic engine loader as well. This leaves a stub initialization function in its place. ok beck@, reyk@, miod@
* In the neverending saga of enabling and disabling assembler code for shamiod2015-03-181-5/+1
| | | | | | | | | | | routines on hppa, the cause for sha512-parisc subtly misbehaving has been found: despite having fallback pa1.1 code when running on a 32-bit cpu, the shift constants used in the sigma computations in sha512 are >= 32 and are silently truncated to 5 bits by the assembler, so there is no chance of getting this code to work on a non-pa2.0 processor. However, the pa1.1 fallback code for sha256 is safe, as it never attempts to shift by more than 31, so reenable it again.
* Do not use sha512-parisc for now, as it is subtly bugged - passes the shamiod2015-03-051-1/+3
| | | | | | | | | | | regress tests but causes tls ciphersuite using sha386 to fail; found the hard way by henning@. I can't see anything wrong in the generated assembly code yet, but building a libcrypto with no assembler code but sha512_block_data_order() is enough to trigger Henning's issue, so the bug lies there. No ABI change; ok deraadt@
* Revert to the use of C code for the basic BN routines (bn_add_words,miod2014-12-071-2/+7
| | | | | bn_div_words, bn_mul_add_words, bn_mul_words, bn_sqr_words, bn_sub_words) on sgi, because the generated assembly code isn't R4000-safe.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-25 22:34:45 +0000