Age | Commit message (Collapse) | Author |
|
"A return statement with an expression shall not appear in a function
whose return type is void."
ok deraadt miod
|
|
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@
|
|
ok jsing
|
|
|
|
Always provide AES_{encrypt,decrypt}() via C functions, which then either
use a C implementation or call the assembly implementation.
ok tb@
|
|
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@
|
|
Should fix windows build.
|
|
|
|
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@
|
|
Discussed with tb@
|
|
The stitched modes have been removed, so having assembly for them is of
little use.
|
|
Replace GETU32 with crypto_load_be32toh() and PUTU32 with
crypto_store_htobe32(). Make the offset handling cleaner at the
same time.
ok beck@ joshua@ tb@
|
|
There are currently three ways in which AES is implemented - all in
assembly (amd64 et al), all in C (aarch64 et al) and, half in C and
half in assembly (hppa and sparc64). The last of these cases currently
makes use of a near duplicate AES_set_{encrypt,decrypt}_key()
implementation that avoids using the AES tables.
Remove the near duplicate version and if only a half assembly version is
implemented, use the same C version of AES_set_{encrypt,decrypt}_key() as
everyone else. This adds around 8KB of rodata to libcrypto on these two
platforms.
Discussed with beck and tb.
|
|
ok tb@
|
|
|
|
|
|
ok tb@
|
|
gcm_{gmult,ghash}_4bit(), aesni_ccm64_decrypt_blocks(), aes_cbc_encrypt(),
and aesni_xts_{en,de}crypt() were overlooked in previous passes.
Found with a diff for ld.lld by kettenis
ok kettenis
|
|
cet.h is needed for other platforms to emit the relevant .gnu.properties
sections that are necessary for them to enable IBT. It also avoids issues
with older toolchains on macOS that explode on encountering endbr64.
based on a diff by kettenis
ok beck kettenis
|
|
needs endbr64
ok kettenis tb
|
|
The public symbols were removed. Some prototypes and in the case of DES
even the implementation remained.
ok jsing
|
|
|
|
Various, ancient ciphers exposed some of their innards via an _options()
API. Apart from openssl version/speed, only some lua thingie in nmap ever
looked at these. Go figure.
hppa testing by miod, i386 testing by sthen. Thanks!
ok jsing
|
|
ok jsing, and kind of tb an earlier version
|
|
"go ahead" jsing
|
|
ok miod
|
|
At least gcc 12 on Fedora is very unhappy about a plain .rodata and throws
Error: unknown pseudo-op: `.rodata'. So add a .section in front of it to
make it happy.
ok deraadt miod
|
|
|
|
Remove remnants of previous PIC handling.
ok miod@
|
|
responsible from getting the proper address of those blocks.
ok tb@ jsing@
|
|
on amd64. no pic handling is neccessary since amd64 has full reach.
ok kettenis
|
|
|
|
fetch them correctly when building PIC. Also drop unused data, and remove
--no-execute-only from linker flags.
ok kettenis@
|
|
fetch them correctly when building PIC. Also drop unused data, and remove
--no-execute-only from linker flags.
ok jsing@ kettenis@
|
|
|
|
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct
ok tb
|
|
|
|
|
|
Not all of them, only those that didn't leak into a public header...
Yes.
|
|
Libcrypto currently has a mess of *_lcl.h, *_locl.h, and *_local.h names
used for internal headers. Move all these headers we inherited from
OpenSSL to *_local.h, reserving the name *_internal.h for our own code.
Similarly, move dtls_locl.h and ssl_locl.h to dtls_local and ssl_local.h.
constant_time_locl.h is moved to constant_time.h since it's special.
Adjust all .c files in libcrypto, libssl and regress.
The diff is mechanical with the exception of tls13_quic.c, where
#include <ssl_locl.h> was fixed manually.
discussed with jsing,
no objection bcook
|
|
The current AES-NI x86_64 assembly does some strange, although valid
things, such as making internal function calls without creating stack
frames. In this case, the return address lands in the red zone (which it
allows for when making use of the stack) and everything works as expected.
However, this trips a false positive in valgrind, which seems to think that
any data saved on the stack prior to the internal function call is now
"undefined" once the function returns.
Avoid this by actually using stack frames - this brings in most of
6a40ebe86b4 from OpenSSL, omitting the unnecessary explicit stack alignment
(which was apparently added so this code could be used in the Linux kernel
with an incorrectly aligned stack).
Valgrind issue reported by Steffen Jaeckel (@sjaeckel), found via
libstrophe unit tests.
ok tb@
|
|
CID 250936 251103
OK beck@ jsing@ millert@ tb@
|
|
non-overlapping *in and *out buffers as we're already implementing
the "in place (un)wrapping" algorithms as given in RFC 3394. This
removes a gratuitous API difference to OpenSSLin these undocumented
functions. Found while working on wycheproof regress tests.
ok beck jsing
|
|
for wrapping and, accordingly, three 64 bit blocks for unwrapping.
That is: we need at least 16 bytes for wrapping and 24 bytes for
unwrapping. This also matches the lower bounds that OpenSSL have
in their CRYPTO_128_{un,}wrap() functions.
In fact, if we pass an input with 'inlen < 8' to AES_unwrap_key(),
this results in a segfault since then inlen -= 8 underflows.
Found while playing with the Wycheproof keywrap test vectors.
ok bcook
|
|
|
|
the assembly code in libcrypto assumes unaligned access is allowed for
ARMv7. Make these paths conditional on __STRICT_ALIGNMENT not being
defined and define __STRICT_ALIGNMENT in arm_arch.h for OpenBSD.
ok tom@
|
|
My read of this: Long time ago (Think Conan, not dinasaurs) during the race
to make speedier processors, a cpu vendor built a pipeline with a bad stall,
and proposed a tremendously hasky workaround. A wizard adopted this into his
perl scroll, and failed to reflect later when no compiler adopted the practice.
This relic remains at the tail end of some functions in OpenSSL as
".byte 0xf3,0xc3". Banish it straight to hell.
ok mlarkin, others also stared blankly
|
|
Move the "internal" BN functions from bn.h to bn_lcl.h and stop exporting
the bn_* symbols. These are documented as only being intended for internal
use, so why they were placed in a public header is beyond me...
This hides 363 previously exported symbols, most of which exist in headers
that are not installed and were never intended to be public. This also
removes a few crusty old things that should have died long ago (like
_ossl_old_des_read_pw). But don't worry... there are still 3451 symbols
exported from the library.
With input and testing from inoguchi@.
ok beck@ inoguchi@
|
|
meaningful constants in a private header file, so that reviewers can actually
get a chance to figure out what the code is attempting to do without knowing
all cpuid bits.
While there, turn it from an array of two 32-bit ints into a properly aligned
64-bit int.
Use of OPENSSL_ia32_P is now restricted to the assembler parts. C code will
now always use OPENSSL_cpu_caps() and check for the proper bits in the
whole 64-bit word it returns.
i386 tests and ok jsing@
|
|
ok deraadt@
|