summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/arch/i386 (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Remove BF_PTRtb2025-06-111-5/+0
| | | | | | | | | | | | In bf_local.h r1.2, openssl/opensslconf.h was pulled out of the HEADER_BF_LOCL_H header guard, so BF_PTR was never defined from opensslfeatures.h. Thus, alpha, mips64, sparc64 haven't used the path that is supposedly optimized for them. On the M3k the speed gain of bf-cbc with BF_PTR is roughly 5%, so not really great. This is blowfish, so I don't think we want to carry complications for alpha and mips64 only. ok jsing kenjiro
* Move (mostly) MI constants to proper headerstb2025-06-091-32/+0
| | | | | | | | | | | | | | | | | Most of the constants here are only defined if a specific header is in scope. So move the machine-independent macros to those headers and lose the header guards. Most of these should actually be typedefs but let's change this when we're bumping the major since this technically has ABI impact. IDEA_INT RC2_INT and RC4_INT are always unsigned int DES_LONG is always unsigned int except on i386 This preserves the existing situation on OpenBSD. If you're using portable on i386 with a compiler that does not define __i386__, there's an ABI break. ok jsing
* Make OPENSSL_IA32_SSE2 the default for i386 and remove the flag.jsing2025-06-091-2/+1
| | | | | | | | | | | | | | | | | The OPENSSL_IA32_SSE2 flag controls whether a number of the perlasm scripts generate additional implementations that use SSE2 functionality. In all cases except ghash, the code checks OPENSSL_ia32cap_P for SSE2 support, before trying to run SSE2 code. For ghash it generates a CLMUL based implementation in addition to different MMX version (one MMX version hides behind OPENSSL_IA32_SSE2, the other does not), however this does not appear to actually use SSE2. We also disable AES-NI on i386 if OPENSSL_IA32_SSE2. On OpenBSD, we've always defined OPENSSL_IA32_SSE2 so this is effectively a no-op. The only change is that we now check MMX rather than SSE2 for the ghash MMX implementation. ok bcook@ beck@
* Remove ${MULTIPLE_OF_EIGHT}_BIT*tb2025-06-081-12/+0
| | | | | | | | These are unused internally and very few things look at them, none of which should really matter to us, except possibly free pascal on Windows. sizeof has been available since forever... ok jsing
* Garbage collect DES_PTRtb2025-06-081-6/+0
| | | | pointed out by/ok jsing
* Remove DES_RISC*tb2025-06-081-55/+0
| | | | | | | | | | | | | | | codesearch.debian.net only shows some legacy openssl patches plus binkd (a FidoNet mailer) as sole potential user. net-snmp and a strongswan DES plugin bundle some opt-in libdes/openssl legacy things. If this should break any of this, I don't think we need to care. If you're really going to use DES you can also use non bleeding edge libressl. We can remove the big 'default values' block because one of DES_RISC1, DES_RISC2, DES_UNROLL is always defined (you can ignore DES_PTR for this), so this is dead support code for mostly dead platforms. ok kenjiro
* Rename the header guard of des.h with HEADER_DES_Htb2025-06-051-1/+1
| | | | | | libdes is dead, Jim. Only its successors continue to haunt us. discussed with jsing
* Remove preprocessor branching on HEADER_DES_Htb2025-06-051-1/+1
| | | | | | | | This was the header guard for des_old.h introduced in 2002 and removed in 2014. The header guard for des.h is HEADER_NEW_DES_H for the sake of inconsistency (ostensibly due to backward compat concerns with libdes). ok jsing
* opensslconf.h: remove md2 leftoverstb2025-06-051-4/+0
| | | | | | | md2.h left on Apr 15, 2014, along with jpake and seed. In particular, HEADER_MD2_H is never defined. These bits have been dead ever since. ok jsing
* Remove BS-AES and VP-AES from EVP.jsing2025-04-181-3/+1
| | | | | | | | | | | | | | | | | The bitsliced and vector permutation AES implementations were created around 2009, in attempts to speed up AES on Intel hardware. Both require SSSE3 which existed from around 2006. Intel introduced AES-NI in 2008 and a large percentage of Intel/AMD CPUs made in the last 15 years include it. AES-NI is significantly faster and requires less code. Furthermore, the BS-AES and VP-AES implementations are wired directly into EVP (as is AES-NI currently), which means that any consumers of the AES_* API are not able to benefit from acceleration. Removing these greatly simplifies the EVP AES code - if you just happen to have a CPU that supports SSSE3 but not AES-NI, then you'll now use the regular AES assembly implementations instead. ok kettenis@ tb@
* 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@
* Check the correct variable in cpuid().jsing2024-11-121-2/+2
|
* 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 IA32 specific code from cryptlib.c.jsing2024-10-192-3/+10
| | | | | | Move the IA32 specific code to arch/{amd64,i386}/crypto_cpu_caps.c, rather than polluting cryptlib.c with machine dependent code. A stub version of crypto_cpu_caps_ia32() still remains for now.
* Provide crypto_cpu_caps_init() for i386.jsing2024-10-183-10/+120
| | | | | | | This is the same CPU capabilities code that is now used for amd64. Like amd64 we now only populate OPENSSL_ia32cap_P with bits used by perlasm. Discussed with tb@
* Unexport OPENSSL_cpuid_setup and OPENSSL_ia32cap_Ptb2024-08-311-1/+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
* Provide and use crypto_arch.h.jsing2024-08-112-8/+35
| | | | | | | | 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-5/+1
| | | | These files are now built on all platforms.
* Stop building camellia assembly on amd64 and i386.jsing2024-03-291-2/+4
| | | | | | | 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-291-2/+1
| | | | This is now built on all platforms.
* Always use C functions for AES_set_{encrypt,decrypt}_key().jsing2024-03-291-1/+4
| | | | | | | | 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-291-3/+1
| | | | This is now built on all platforms.
* Stop building whirlpool assembly on amd64 and i386.jsing2024-03-291-3/+1
| | | | | | | 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-281-2/+1
|
* Make AES_cbc_encrypt() always be a C function.jsing2024-03-281-1/+3
| | | | | | | | 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-281-3/+0
|
* Move rc4.c to primary Makefile.jsing2024-03-281-2/+1
| | | | This is now built on all platforms.
* Use C functions for RC4 public API.jsing2024-03-281-1/+4
| | | | | | | | | | | | | | 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-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 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@
* 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.
* 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-121-0/+1
| | | | ok tb@
* Stop building GF2m assemblytb2023-04-151-3/+1
| | | | | | | 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
* 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@
* 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@
* 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
* sprinkle a few missing dependencies on perl scripts internal bits.espie2017-08-201-3/+6
| | | | 'it works' deraadt@
* 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@
* miod forgot about fcrypt_b.c being needed, before he went off to get hisderaadt2014-05-071-1/+2
| | | | | beauty sleep. He's probably having a nightmare about this right now.... ok tedu
* Sort CFLAGS, SRC and SSLASM stanzas by the directories they apply to, to makemiod2014-05-061-31/+36
| | | | | these files similar in layout to the other md Makefile.inc; no functional change.
generated by cgit v1.2.3-55-g6feb (git 2.39.1) at 2025-08-27 20:32:02 +0000