| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
ok tb@
|
|
|
|
| |
ok tb@
|
|
|
|
|
|
|
| |
interfaces, and remove empty assembly OPENSSL_cpuid_setup routines - the
default empty C fallback will work as good.
ok jsing@
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
i removed the arithmetics -> arithmetic changes, as i felt they
were not clearly correct
ok tb
|
|
|
|
| |
ok tb@, deraadt@, kettenis@
|
|
|
|
|
|
|
|
|
| |
arm_arch.h and armcap.c are shared between armv7 and aarch64 which
results in an inscrutable #ifdef maze. Move copies of these files
into arch/{arm,aarch64}/ with appropriate names and some trivial
minor adjustments.
ok deraadt inoguchi kettenis
|
|
|
|
|
| |
copied from other 64 bit arch
ok jsg@
|
|
|
|
| |
OK deraadt@
|
| |
|
|
|
|
|
| |
hooked up and the lack of a bn_mul_mont_int implementation results in
undefined references.
|
| |
|
|
|
|
| |
just commit this kettenis@
|
|
|
|
|
|
| |
hardware crypto features are available.
"no objections" kettenis@
|
| |
|
|
|
|
| |
'it works' deraadt@
|
| |
|
|
|
|
| |
majors appropriately
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
| |
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@
|
|
|
|
| |
ok deraadt@
|
|
|
|
|
|
| |
hppa reverse-stack gives us a valuable test case, but most developers don't
have a 2nd one to proceed further with this.
ok kettenis
|
|
|
|
|
| |
machinery. OpenBSD has never been not ELF on amd64, and changing this will
actually make -portable life slightly easier in the near future.
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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@
|
|
|
|
|
| |
bn_div_words, bn_mul_add_words, bn_mul_words, bn_sqr_words, bn_sub_words)
on sgi, because the generated assembly code isn't R4000-safe.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
fixed.
|
|
|
|
|
| |
cases and breaks TLS 1.2; crank libcrypto.so minor version out of safety and
to be able to tell broken versions apart easily.
|
|
|
|
|
|
|
|
|
| |
Most assembly blocks remain inactive if OPENSSL_NO_ASM is not defined,
only enabling inline assembly, but the RSA / RC4-5 blocks (used only in
amd64 systems) turn on implicitly. Guard these two as well.
This simplifies enabling just inline ASM in portable, no effective
change in OpenBSD.
|
| |
|
|
|
|
| |
probably ok beck jsing miod
|
|
|
|
|
| |
can know...
ok jsing@
|
|
|
|
|
|
| |
opensslconf.h is just a dummy, we're lightyears away from working userspace.
ok deraadt@
|
|
|
|
|
| |
beauty sleep. He's probably having a nightmare about this right now....
ok tedu
|
|
|
|
|
| |
these files similar in layout to the other md Makefile.inc; no functional
change.
|
|
|
|
|
| |
uses the `umul' and `udiv' instructions directly, which are not supported
on v7 processors.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Note that GCM128 Neon code is currently not built (and thus not tested), as
the current toolchain does not support Neon instructions.
|
| |
|
|
|
|
| |
Assembler bits for AES remain commented out as they run slower than the C code.
|
| |
|
| |
|