summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch/sparc64 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Support OPENSSL_NO_FILENAMEStb2025-03-091-0/+10
| | | | | | | | | | Some people are concerned that leaking a user name is a privacy issue. Allow disabling the __FILE__ and __LINE__ argument in the error stack to avoid this. This can be improved a bit in tree. From Viktor Szakats in https://github.com/libressl/portable/issues/761 ok bcook jsing
* Replace Makefile based SHA*_ASM defines with HAVE_SHA_* defines.jsing2025-02-142-5/+11
| | | | | | | | | | | | | | | | 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@
* Mop up RC4_INDEX.jsing2025-01-271-7/+0
| | | | | | | | | | | | | The RC4_INDEX define switches between base pointer indexing and per-byte pointer increment. This supposedly made a huge difference to performance on x86 at some point, however compilers have improved somewhat since then. There is no change (or effectively no change) in generated assembly on a the majority of LLVM platforms and even when there is some change (e.g. aarch64), there is no noticable performance difference. Simplify the (still messy) macros/code and mop up RC4_INDEX. ok tb@
* cryptlib.h: adjust header guard for upcoming surgerytb2024-11-051-1/+1
| | | | | | | | It is gross that an internal detail leaked into a public header, but, hey, it's openssl. No hack is too terrible to appear in this library. opensslconf.h needs major pruning but the day that happens is not today. ok jsing
* Remove unused sparc CPU capability detection code.jsing2024-10-191-5/+1
| | | | | | | This has been unused for a long time - it can be found in the attic if someone wants to clean it up and enable it in the future. ok tb@
* Provide and use crypto_arch.h.jsing2024-08-112-3/+29
| | | | | | | | 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
|
* Remove OPENSSL_UNISTD definetb2024-03-281-3/+0
|
* 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.
* 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@
* 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 unused Elliptic Curve code.jsing2023-01-141-5/+1
| | | | | | | | | | | | | 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@
* 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.
* spelling fixes; from paul tagliamontejmc2022-12-261-3/+3
| | | | | | | i removed the arithmetics -> arithmetic changes, as i felt they were not clearly correct ok tb
* Remove commented out rc5 bitstb2019-05-111-3/+1
|
* Ride the current major bump and enable assembler code for nist 256p curve,miod2016-11-041-1/+5
| | | | | | | | 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-041-3/+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@
* Disable ENGINE_load_dynamic (dynamic engine support).bcook2015-06-191-1/+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@
* 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.
* i'm a dumbdumb. fix build.tedu2014-07-111-1/+1
|
* move all the feature settings to a common header.tedu2014-07-111-72/+1
| | | | probably ok beck jsing miod
* Make sure we leave OPENSSL_NO_PSK in the conf files so thingsbeck2014-07-111-0/+1
| | | | | can know... ok jsing@
* Enable assembler code for AES, DES, GCM, SHA1, SHA256 and SHA512.miod2014-05-031-0/+46
| | | | | The sparcv9 BN code is not enabled, as it expects to run on a 32-bit userland and will need to be fixed for 64-bit userland first.
* first round of static config. ok miodtedu2014-04-181-43/+0
|
* The more you remove Chtulhu^WVMS tentacles, the more there aremiod2014-04-151-2/+0
|
* Move build machinery for libcrypto from libssl/crypto to libcrypto, as wellmiod2014-04-111-0/+273
as configuration files; split manpages and .pc files between libcrypto and libssl. No functional change, only there to make engineering easier, and libcrypto sources are still found in libssl/src/crypto at the moment. ok reyk@, also discussed with deraadt@ beck@ and the usual crypto suspects.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-04-27 09:02:00 +0000