summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch/hppa/Makefile.inc (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Replace Makefile based SHA*_ASM defines with HAVE_SHA_* defines.jsing2025-02-141-3/+1
| | | | | | | | | | | | | | | | Currently, SHA{1,256,512}_ASM defines are used to remove the C implementation of sha{1,256,512}_block_data_order() when it is provided by assembly. However, this prevents the C implementation from being used as a fallback. Rename the C sha*_block_data_order() to sha*_block_generic() and provide a sha*_block_data_order() that calls sha*_block_generic(). Replace the Makefile based SHA*_ASM defines with two HAVE_SHA_* defines that allow these functions to be compiled in or removed, such that machine specific verisons can be provided. This should effectively be a no-op on any platform that defined SHA{1,256,512}_ASM. ok tb@
* Provide and use crypto_arch.h.jsing2024-08-111-3/+1
| | | | | | | | 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@
* Always use C functions for AES_{encrypt,decrypt}().jsing2024-03-291-1/+3
| | | | | | | 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-291-3/+1
| | | | These files are now built on all platforms.
* Move aes_core.c to the primary Makefile.jsing2024-03-291-2/+1
| | | | This is now built on all platforms.
* Move wp_block.c to the primary Makefile.jsing2024-03-291-3/+1
| | | | This is now built on all platforms.
* Merge aes_cbc.c into aes.c now that aes_cbc.c is used on all platforms.jsing2024-03-281-2/+2
|
* Move rc4.c to primary Makefile.jsing2024-03-281-3/+1
| | | | This is now built on all platforms.
* Move des sources to primary Makefile.jsing2024-03-281-3/+1
| | | | | Now that all platforms use a C des implementation, move it to the primary Makefile.
* 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-271-2/+2
| | | | Discussed with tb@
* Move bf_enc.c to the primary Makefile.jsing2024-03-271-3/+1
| | | | | Now that all architectures are using bf_enc.c, it does not make sense to have it in every Makefile.inc file.
* Remove the now empty bn_asm.c.jsing2023-01-311-2/+1
| | | | | | 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 non-visible and unused OPENSSL_wipe_cpu and OPENSSL_atomic_addmiod2023-01-171-8/+1
| | | | | | | interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the default empty C fallback will work as good. ok jsing@
* 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@
* 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
* Remove commented out rc5 bitstb2019-05-111-3/+1
|
* 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@
* Add the Cammelia cipher to libcrypto.miod2014-11-171-1/+3
| | | | | | | | | | | | | | | | | | There used to be a strong reluctance to provide this cipher in LibreSSL in the past, because the licence terms under which Cammelia was released by NTT were free-but-not-in-the-corners, by restricting the right to modify the source code, as well retaining the right to enforce their patents against anyone in the future. However, as stated in http://www.ntt.co.jp/news/news06e/0604/060413a.html , NTT changed its mind and made this code truly free. We only wish there had been more visibility of this, for we could have had enabled Cammelia earlier (-: Licence change noticed by deraadt@. General agreement from the usual LibreSSL suspects. Crank libcrypto.so minor version due to the added symbols.
* Revert r1.5 and reenable assembler version of ghash now that it has beenmiod2014-09-271-3/+3
| | | | fixed.
* Disable assembler code for ghash on hppa, causes wrong computations in somemiod2014-09-271-3/+3
| | | | | cases and breaks TLS 1.2; crank libcrypto.so minor version out of safety and to be able to tell broken versions apart easily.
* Correctly enable assembler Montgomery routine.miod2014-05-021-1/+2
|
* Reenable assembler code for SHA384 and SHA512 now that it no longer miscomputesmiod2014-05-021-3/+3
| | | | things. Worth doing as it's twice faster than the C code.
* Disable assembler version of SHA512 for now, it produces wrong results.miod2014-05-021-3/+3
|
* Enable use of assembly code for AES, BN (Montgomery), SHA1, SHA256 and SHA512.miod2014-05-011-0/+50
RC4 assembler code is not used, as it runs about 35% slower than the C code.