openbsd/src/lib/libcrypto/arch/hppa, branch OPENBSD_7_4A mirror of https://github.com/libressl/openbsd.git
https://git.lua4.win/openbsd/atom?h=OPENBSD_7_42023-01-31T06:17:11+00:00Remove the now empty bn_asm.c.2023-01-31T06:17:11+00:00jsing2023-01-31T06:17:11+00:00urn:sha1:0019a0499b5d8bc46dc5e1e2f3991c796603d31a
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_add2023-01-17T15:04:27+00:00miod2023-01-17T15:04:27+00:00urn:sha1:a7f48cec18a6702191b620e72d8ffa41cd9173bc
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 to2023-01-13T17:11:41+00:00miod2023-01-13T17:11:41+00:00urn:sha1:6f56f28c72618c1e8d79d943e58f0f1c66e73832
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 because2023-01-11T16:25:13+00:00deraadt2023-01-11T16:25:13+00:00urn:sha1:2a7bb7c32bd52d9da45eb627f444f857a5e30e50
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 tagliamonte2022-12-26T07:18:53+00:00jmc2022-12-26T07:18:53+00:00urn:sha1:2eb7e5ff6bb69760f9dd4a43e7e3520ebb930120
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct
ok tb
Remove commented out rc5 bits2019-05-11T13:05:25+00:00tb2019-05-11T13:05:25+00:00urn:sha1:83feb7b0ecfb7abaf7c81a355c94e22c3c5440e9Remove I386_ONLY define. It was only used to prefer a2016-11-04T13:56:05+00:00miod2016-11-04T13:56:05+00:00urn:sha1:098856ba6c9340c7f8061be62dd042763fe233a3
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).2015-06-19T06:05:11+00:00bcook2015-06-19T06:05:11+00:00urn:sha1:1ef7c35782edea8e65610a2d9d6d6d08ea90983c
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 sha2015-03-18T05:26:10+00:00miod2015-03-18T05:26:10+00:00urn:sha1:6b3d8d3164d1b68d078a0cf83583f3dd8bbcb340
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 sha2015-03-05T20:35:28+00:00miod2015-03-05T20:35:28+00:00urn:sha1:edab9f054cd9e7b7c2bb8b5683f63e8a6eaea617
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@