Where is it caught?
Addentum: programm caught in different functions: I saw
OPENSSL_Cleanse(), EVP_DigestUpdate(), sha1_something and others.
I provided 'thread apply 1 info reg' only if it get caugth in
sha1_block_data_order_ssse3 ().
The implied question was if program is making
OpenSSL 1.0.1 snaphot 20111211, compiled on Cygwin, no special config options.
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
CPU Code2 Duo E8600
Both
./apps/openssl speed sha1
and
./apps/openssl speed -evp sha1
MAY results in hangup on any stage.
Sometimes speed
OS: SunOS 5.10
Compiler: SunStudio
As requested on the mailing lists today I downloaded
openssl-1.0.1-stable-SNAP-20111209
and tried to compile it on various OS.
It failed on SunOS 5.10 when using Sun's compiler:
cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include
It looks like a bug inopenssl-1.0.0e x86 (Windows, Linux, etc.):
functions BN_mod_mul and BN_mod_mul_mongomery sometimes (very rarely)
yield different results when squaring (multiplication at the same time
works fine).
Compile time options include -DOPENSSL_BN_ASM_MONT, ie the assembler
Here is a list of issues on OpenVMS VAX
1. %CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not
supported issue
cbc128.c
typedef long long i64;
^
%CC-E-NOLONGLONG, In this declaration, 64-bit integral types are not supported
on this
In CVS OPENSSL_1_0_1-stable branch, on a ILP32 target (where
sizeof(long) == 4), the function OPENSSL_ia32cap_loc() is clearing
upper bits of capability vector which disable support for SSE3, AES-NI,
etc...
A user program not reading/writing OPENSSL_ia32cap before using other
encryption,
Specification says that AVX instruction will generate #UD exception if
XCR0 is not set up appropriately.
Which is indeed what happens, and that's the bug in OpenSSL we were
trying to fix. OpenSSL assumed (against the spec) that XSAVE=0 implies
AVX=0, and didn't check whether AVX needed
commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66
Author: Sheng Yang sh...@linux.intel.com
Date: Tue Jun 22 13:49:21 2010 +0800
KVM: x86: Enable AVX for guest
Enable Intel(R) Advanced Vector Extension(AVX) for guest.
The detection of AVX feature includes OSXSAVE bit
No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0 also
implies that AVX flag [as well as FMA and XOP] is 0, which is why is
jumps to 'done' and not 'clear_avx'.
This assertion is unfortunately not true on RHEL-6 guests on AVX capable
CPUs in XEN VM.
Could you spell it for me?
As for XEN, if it in fact masks XSAVE, but not AVX bits, than even
check for XSAVE bit should 'jnc (label(clear_avx));' instead of
done. As well as that x86_64cpuid.pl should test for XSAVE...
That would also work, but it's useless because the spec OTOH says that
you *can* ignore XSAVE (and
No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0 also
implies that AVX flag [as well as FMA and XOP] is 0, which is why is
jumps to 'done' and not 'clear_avx'.
This assertion is unfortunately not true on RHEL-6 guests on AVX capable
CPUs in XEN VM.
Could you spell it for me?
Here is analysis by Paolo Bonzini:
I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the
latter is wrong.
From x86_64cpuid.pl:
mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx
bt \$27,%r9d # check OSXSAVE bit
As some of you may be aware the new Oracle SPARC T4 processor has
hardware crypto support just like its predecessors SPARC T1,T2,T3.
However unlike the prior SPARC T series processors the hardware crypto
is not hyper-privileged but is instead new instructions accessible from
unprivileged
When using the latest 1.0.1 snapshot I get the following errors when
running openssl speed -engine aesni -evp aes-256-cbc.
There is no (and never was) AES-NI engine in 1.0.1. There was one in
development HEAD branch, but it was removed yesterday. support for
AES-NI is integrated directly at EVP
I wish I could give you the info you ask for in your Readme but I can
not even install this which is not what I am reporting.
SunOS 5.9 Generic_122300-60 sun4u sparc SUNW,Sun-Fire-V240
OpenSSL version 1.0.0e which does not install but produces a problem
when I try to config it
The
Openssl1.0.0d contains a typo in a ifndef directive, see transscript
below. This bug pops up in a build on a Tru64 V5.1B system.
DOPENSSL_BN_ASM_MONT -c -o bn_asm.o bn_asm.c
/bin/perl asm/alpha-mont.pl | cc -E - | tee alpha-mont.s /dev/null
cc: Warning: , line 1: indef is an invalid
Could you 'truss -v sigaction,sigprocmask apps/openssl version' and
submit output?
I cannot. My server doesn't run Solaris but Linux/sparc. I just have
seen the same bug a long time ago on Solaris but I don't have any
solaris server anymore.
Then run 'strace -v apps/openssl version'.
Could you 'truss -v sigaction,sigprocmask apps/openssl version' and
submit output?
I cannot. My server doesn't run Solaris but Linux/sparc. I just have
seen the same bug a long time ago on Solaris but I don't have any
solaris server anymore.
Then run 'strace -v apps/openssl version'.
I see a very strange bug in crypto/sparcv9cap.c. OpenSSL 1.0.0d checks
sparc capabilities with SIGILL signal. On sparc64 (both Linux and
solaris, with UltraSPARC III+ and T1 CPU's), SIGILL handler is called
and program terminates with SIGILL in _sparcv9_fmadd_probe:
Hi,
I see a very strange bug in crypto/sparcv9cap.c. OpenSSL 1.0.0d checks
sparc capabilities with SIGILL signal. On sparc64 (both Linux and
solaris, with UltraSPARC III+ and T1 CPU's), SIGILL handler is called
and program terminates with SIGILL in _sparcv9_fmadd_probe:
I see a very strange bug in crypto/sparcv9cap.c. OpenSSL 1.0.0d checks
sparc capabilities with SIGILL signal. On sparc64 (both Linux and
solaris, with UltraSPARC III+ and T1 CPU's), SIGILL handler is called
and program terminates with SIGILL in _sparcv9_fmadd_probe:
I noticed this odd sequence of instructions in cbc.pl, near line 171.
It seems like a bug, but the code hasn't been modified since 1998,
and it seems unlikely this bug would have gone unnoticed for that
long[1]:
set_label(ej3);
movb(HB(ecx), BP(2,$in,,0));
xor(ecx,
First of all, let's ask ourselves how come vanilla openssl build doesn't
fail? I mean download, unpack, './config shared' and 'make'... The
answer is because libcrypto.so is linked with -Bsymbolic. Want to get
rid of the error in your builds? Add -Bsymbolic too... It's more than
appropriate in
On Check-in 20157, it adds #include malloc.h.
http://cvs.openssl.org/chngview?cn=20157
But on FreeBSD /usr/include/malloc.h is following:
% cat /usr/include/malloc.h
/* $FreeBSD: src/include/malloc.h,v 1.5.36.1.4.1 2010/06/14 02:09:06
kensmith Exp $ */
#if __STDC__
#error malloc.h has
Below remark do *not* mean that issue is dismissed, only that using
Sleep(1) probably is not really good programming practice. The
work-around mentioned closer to the end of originating report should
not be considered as work-around, but as *proper solution*.
Problem: While using non-blocking
I'd argue that it's intentional. The original purpose for -out option
appears to be to emit *certificate* itself, not information about it.
Yes, this kind of means that I reckon that -text option should result in
output to STDout, not to one appointed by -out. There also is
inconsistent usage
I used this as a jumping point to investigate and can share some
information about the build on Win98 with mingw. I am also attaching a
patch for you to look at.
Please verify http://cvs.openssl.org/chngview?cn=20153.
It turns out that despite the logs I submitted
to you, unicows wasn't
I've meanwhile checked apps/x509.c, and patching it to send output to
file is trivial (attached); but looking at the other output options
around these lines makes me a bit unsure if these options are intended
to go to STDOUT rather than to honor a file option? However if the later
then I'm
I configured the build using:
./Configure solaris-x86-gcc --prefix=/usr/local
--openssldir=/usr/local/openssl shared
so we can get a 32 bit build on our amd64 Solaris architecture.
It core dumps when running the tests.
This discussed in PROBLEMS file in source tree, search for
As for Doug's suggestion for separate targets. I'd argue against. It's
probably more appropriate to fix it up in ./Configure, e.g. by looking
at 'gcc --target-help' and removing [or adding] -mno-cygwin. A.
http://cvs.openssl.org/chngview?cn=20110. a.
I thought that unicows had to be linked as the first library, so I
manually added -lunicows at the beginning of the LIBRARIES variable in
apps/Makefile, after Configure had completed.
Great! Formally unicows should appear prior whatever it is supposed to
override. For example is doesn't have
In compiling openssl head (tarball from 18 November 2010) for mingw
under cygwin on a Windows98 machine,
I.e. it's linked with msvcrt.dll, right? It also means that non-vendor
linker is involved...
I came across a problem in
crypto/bss_file.c. The code compiles fine on Windows98 and the
i'm not
sure how people are still able to use it from Cygwin; all i get if i do
a simple ./Configure mingw then make is:
gcc: The -mno-cygwin flag has been removed; use a mingw-targeted
cross-compiler.
then it errors out before even compiling the first object.
Not all people unconditionally
yes - that's same issue; I did delete my source tree, and extracted from
MSYS with:
tar xfhz openssl-1.0.0b.tar.gz
Is it correctly understood that in this context 'h' option simply omits
symbolic links? I get a bunch of Cannot create symlink to with
corresponding consequences. Configure then
Hi,
when building updates for Fedora 14 on s390x I've found that openssl
1.0.0b fails to finish its testsuite with at least the BN_sqr test
failing, see [1], [2] for more details. Because I've seen some changes
in crypto/bn/asm/s390x.S between 1.0.0a and 1.0.0b I've tried a build
with these
Could you examine ticket #2273. Can you confirm that it's same issue
discussed at the very end? A.
argh! Now remember we discussed this issue already with last release ...
will asap repack the release archive on Linux and check if that does any
better ...
yes - that's same issue; I did
While building the openssl-1.0.0b for windows (using the mingw
compiler) I get the following build error :
making all in crypto/dso...
make[2]: Entering directory `/cygdrive/f/openssl-1.0.0a/crypto/dso'
gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS -D_MT
-DD
Hi,
OpenSSL 1.0.0b standard test compilation breaks with MingW32 / MSYS:
make[2]: Entering directory `/d/openssl-1.0.0b/test'
( :; LIBDEPS=${LIBDEPS:--L.. -lssl -L.. -lcrypto -lws2_32 -lgdi32
-lcrypt32}; LDCMD=${LDCMD:-gcc};
LDFLAGS=${LDFLAGS:--DOPENSSL_THREADS -D_MT -DDSO_WIN32
Could you please double-check http://cvs.openssl.org/chngview?cn=19935?
A lot of thanks in advance. A.
Hi, was that for me to check?
Yes.
I've done it anyway by patching
x86_64-xlate.pl to 1.25.2.7
http://cvs.openssl.org/fileview?f=openssl/crypto/perlasm/x86_64-xlate.plv=1.25.2.7
With x64 I get warnings when linking applications, both openssl.exe and
test programs like sha1test.exe. A snippet of output from nmake -f
ms\nt.mak:
link /nologo /subsystem:console /opt:ref /debug
/out:out32\openssl.exe @C:\DOCUME~1\FRYKEN~1\LOCALS~1\Temp\nm3B3.tmp
I am also attempting to build OpenSSL 1.0.0a on an antique OSF1
system-name-here V4.0 1530 alpha alpha Tru64 system running Alpha
4.0G. I also get the error about dli not being declared. This is
the last of the compile log where it fails:
cc -I.. -I../.. -I../asn1 -I../evp -I../../include
The issue was fixed earlier in http://cvs.openssl.org/chngview?cn=19501. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Hi,
Current version of nasm is 2.09 and it does not have the nasmw
executable anymore, the correct executable is
nasm and not nasmw. I'm not sure when this happened but it was
long time ago.
Please repair the problem by
* replace calls of nasmw with nasm
OpenSSL checks for availability
In fact it is the copy used by python, located at
http://svn.python.org/projects/external/openssl-1.0.0a
I made a seach for nasmw inside the entire code an discovered that:
/ms/bcb.mak
/ms/nt.mak
/ms/ntdll.mak
All of these files do contain references to 'nasmw', and only.
I observed
... I've applied http://cvs.openssl.org/chngview?cn=19894. Could
you test the HEAD branch? Once you confirm that it works (or some other
issues are addressed), I'll propagate it to 1.0.
it seems to work OK. i just built openssh against it and connected to a few
systems. this segfaulted
What do you mean with the last paragraph in your email?
Do you like to make a fix, in such way that the sun way becomes more similar
to the linux way?
Yes, see http://cvs.openssl.org/chngview?cn=19883. The Linux procedure
was unified to cover remaining hardware platforms supported by
The reproduction provided by you also crashed on my SparcIII machine
if -lmalloc was used.
Which is intended. In sense that libdevinfo is incompatible with
libmalloc not on some particular hardware platform, which would make bug
report more convincing.
A call to mallopt(M_KEEP,0) did not
Why does Solaris 10 on SparcIII not suffer from this problem, is
unclear to me.
Because there is a shortcut. VIS2-capable CPUs are excused from
libdevinfo voodoo and USIII is VIS2-capable CPU. Because all so-far
observed VIS2-capable CPUs has identical qualities from OpenSSL
viewpoint. VIS2
The 32-bit of openSSL 1.0.0a (solaris-sparcv9-cc configuration)
coredumps upon initialization. The stack trace is (of our product
binary):
But you can still copy apps/openssl binary to this old system and
invoke
it, say with 'version' command-line argument... If it doesn't crash,
then the
OpenSSL does not compile anymore as a shared library with Mac OS X
since check-ins #19768 - #19771 by appro. It always fails with the
following error:
making all in engines...
/bin/sh: -c: line 0: unexpected EOF while looking for matching ``'
/bin/sh: -c: line 1: syntax error: unexpected
Hi,
The 32-bit of openSSL 1.0.0a (solaris-sparcv9-cc configuration)
coredumps upon initialization. The stack trace is (of our product
binary):
Does reference to your product binary mean that apps/openssl does not
crash? In other words does 'make test' pass? If so, then the question
is
how
OpenSSL does not compile anymore as a shared library with Mac OS X
since check-ins #19768 - #19771 by appro. It always fails with the
following error:
making all in engines...
/bin/sh: -c: line 0: unexpected EOF while looking for matching ``'
/bin/sh: -c: line 1: syntax error: unexpected
when iv run 'config no-asm' and then run 'make' ,the following
messge tells some mistakes. How can i solve the questions in attachment?
bash-3.00#./config no-asm
bash-3.00#make
...
gcc -I.. -I../.. -I../asn1 -I../evp -I../../include -DOPENSSL_THREADS
-D_REENTRANT
Shall we settle for http://cvs.openssl.org/chngview?cn=19768?
I take it as yes and dismissing the case. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
cURL uses --prefix to find the include files as well and assumes that
the libraries are in prefixdir/lib. Till now, cURL has a
possibility to say where the library reside (with LDFLAGS environment
variable). The problem is (but I'm not 100% sure) that the pkgconfig
dir is also not in a fixed
Shall we settle for http://cvs.openssl.org/chngview?cn=19768? A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Hi,
I noticed that the output directories of any prefixed (--prefix) OpenSSL
build for some Unix 64-bit flavors changed.
In the past (at least with openSSL openssl-0.9.8k), after calling gmake
install, the include files were in prefix/include, the libraries in
prefix/lib.
Due to the
Testing OpenSSL 1.0.0a on MacOSX 10.6, I see that it defaults to
loadable modules using using the .dylib extension. It's my
understanding this is incorrect, as loadable modules on MacOSX are
called either .so (for compability) or .bundle (for native
modules). Dynamically linked
In other words I'd argue that it's more appropriate to modify
MacOS-specific build procedure to link engine modules with .dylib.
As opposite to suggested change to dso_dlfcn.c.
A .dylib is a shared library - not a loadable module (.bundle/.so).
MacOSX treats those differently, so trying to
I do not agree
This is clearly a mistake in interfacing with inline assembly. By explicitly
ising a dual-register type in the output section of an __asm__ statement, but
only passing a 32 bit reference, this is a misuse of the inline
assembly interface guidelines.
If it's misuse, then
There is a lovely potential register mismatch issue, which can be
reproduced easily with the following setup
using gcc 3.3.3 (SuSe linux)
When compiled with gcc –O0 to gcc –O2, register eax is used
When compiled with gcc –O3 and higher, register edx is used
asm volatile(rdtsc:=A
When building OpenSSL we do not succeed in building the NT debug dll
without changing the OpenSSL build files. As can be seen in the dump
below (see error) cl failes to create/open database file
'path\openssl-1.0.0a\tmp32dll\lib.pdb' this is not strange since when
we look in the
The 1.0.0a release will not complete the build because configure
does not copy (several?) files to where they should be. One example
is md2test.c. When make gets there, it is an empty file, and ld
produces an error. I can say 100% sure that the
1.0.0-STABLE-20100331
Please remove the error nasm is an unrecognized ... by applying the
attached patch to VC-32.pl
Addressed in http://cvs.openssl.org/chngview?cn=19691. Thanks for report. A.
__
OpenSSL Project
Recently, mingw64 has chosen to be compatible with MSVC's symbol decoration
conventions, ie no underscore for x64 dll's. The underscore assumption has
been made in one file (afaik), namely:
x86_64-xlate.pl: line 83: if ($flavour eq mingw64) { $gas=1; $elf=0;
$win64=1; $prefix=_; }
There
May be there is another method to check wether a windows
process is a service, without using user32.dll.
As mentioned one can do it with Native NT API, but it's quite
special and belongs rather in [your] application than in
openssl.
Yes and no. As soon as there is any openSSL code, using
I tried to make OpenSSL ver.1.0.0 on MacOSX.
But I failed to 'make test', it said 'Bad cpu type'
Maybe, It is occurred by 'crypto/perlasm/ppc-xlate.pl' .
In 61 lines
$arch = ($flavour=~/64/) ? ppc970-64 : ppc970 if ($arch eq any);
In my environment, $flavour is 'osx32', so $arch
We use the following patch on openSUSE to make sure that openssl
uses non-executable stack by marking the assembler code as
not requiring x-stack.
This was discussed earlier. Adding system specifics to code is not
directly desired for obvious reasons. Suggested alternative is configure
with
I agree that OPENSSL_isservice() cannot be changed,
??? My suggestion for *you* was to modify it to unconditionally
return 1...
Our application can both run in foreground and in service
context. So
simply changing to return 1 is not possible.
If changing to return 1 is not acceptable, how
I agree that OPENSSL_isservice() cannot be changed,
??? My suggestion for *you* was to modify it to unconditionally
return 1...
Our application can both run in foreground and in service context. So
simply changing to return 1 is not possible.
If changing to return 1 is not acceptable, how
I agree that OPENSSL_isservice() cannot be changed,
??? My suggestion for *you* was to modify it to unconditionally return 1...
but you can
decide to log an event always.
... so that messages will be forced to event log.
So all if (OPENSSL_isservice()) can be
removed. Or change it to a
When building openSSL on Windows with:
* CONFIG=VC-WIN64A or CONFIG=VC-WIN32
* no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS
* With Visual Studio 2005
I get dependencies to user32.dll, when using libeay32.lib, e.g:
2libeay32.lib(rand_win.obj) :
The performance benchmark with openssl speed show about 50%
performance gain for 1024 bit private RSA.
The optimization is implemented as an engine named RSAX.
Because x86_64 assembly is used in implementation, the optimization is
only available on x86_64.
More information about the
Trying to build openssl 1.0.0-beta5 with an armv6 crosscompiler in the
linux-armv4 [armv6 is supposed to be compatible with armv5 and armv4...]
config results in
aes-armv4.s: Assembler messages:
aes-armv4.s:981: Error: unaligned opcodes detected in executable segment
make[2]: ***
This is an update to the sources (only) for the CMAC, CCM and GCM code we
donated previously.
Just to denote that alternative GCM implementation is available now,
see http://cvs.openssl.org/rlog?f=openssl/crypto/modes/gcm128.c. It's
initial version and interface is still subject to change.
Moore's Law caught up with us; when doing speed tests on new platforms
(for AES-NI) we found that the calculation of the number of operations
to do was overflowing a 31-bit 'long'.
By switching to 'unsigned long' and re-ordering the calculations a bit,
we can postpone that overflow for a
Earlier this year Number Cruncher already reported a valgrind error in
function AES_cbc_encrypt and included a two-line patch to fix it.
Please see this post for reference:
http://marc.info/?l=openssl-devm=123211846607090w=2
Yesterday I ran into the same valgrind error message using
Tim Hudson via RT wrote:
I kicked off some builds last night as I was curious as to the answer to
the question - 0.9.8d fails in make test, 0.9.8k passes in make test.
No comment on this one.
The 1.0.0 beta 3 fails with the SHA1 asm code and in the AES asm code.
I haven't had a chance to
could you please have a look at the little change I am proposing in my
previous post?
IMHO it is quite clearsimple, it does not harm any existing code and it
does help mingw-w64 users (using 32-bit native compiler)
So would ./Configure mingw -DWIN32_LEAN_AND_MEAN. And it would do better
Since IPv6 support was added, in dgram_write() the size of data-peer
cannot be used for sendto() anymore. The union has the size of
sockaddr_in6 when IPv6 is enabled and therefore sendto() always fails
with Invalid Argument when only IPv4 is used. It should be either the
size of sockaddr_in
The library bufferoverflowu.lib is explicitly added to the command
line on win64 platforms via a few instances of this line in
util/pl/VC-32.pl:
$ex.=' bufferoverflowu.lib' if ($FLAVOR =~ /WIN64/);
This library doesn't exist and is no longer shipped with Visual
Studio 2008.
Addressed in
On a CentOS 5.4 x86_64 system, OpenSSL 0.9.8l builds correctly under
binutils 2.17.50. However, on the same system using binutils 2.20.51
the GNU assembler (as) generates errors in both MD5 and SHA1 assembly
code of the form:
md5-x86_64.s:41: Error: 0xd76aa478 out range of signed 32bit
The latest changes of bss_dgram.c affected the behavior of
BIO_CTRL_DGRAM_GET_PEER, which now requires to preset the expected IP
type before requesting the current peer.
Which was just wrong to assume, my bad. Thanks for report and
suggestion. Slightly modified version is committed as per
In check-in 18896 for openssl/crypto/perlasm/x86_64-xlate.pl in branch
OpenSSL_1_0_0-stable was a typo:
- # in $self-{label}
- $self-{label} =~ s/(?![0-9a-f])(0[x0-9a-f]+)/oct($1)/egi;
+ # in $self-{label}, new gas requires sign extentions...
+ user
The Stratus VOS operating system also has a required executable
extension. OpenSSL handles it properly except in one case. I've
attached a patch.
I am not entirely happy that I had to hard-code in the VOS executable
extension, but I see that's how the existing code works. If there is an
I haven't witnessed any problems like you describe, so maybe the OS I
am using is well behaved.
maybe is not acceptable answer:-) What is it? I *assumed* it was
Linux, but gcc -dumpspecs predefines __CELLOS_LV2__ which doesn't sound
like Linux... The macro doesn't seem to be present in stock
Could you complement back-trace with 'info reg' output?
(gdb) bt
#0 _x86_64_Camellia_encrypt () at cmll-x86_64.s:74
#1 0x77a7a4b4 in Camellia_cbc_encrypt () at cmll-x86_64.s:1686
#2 0x7fffca30 in ?? ()
#3 0x0068e190 in ?? ()
#4 0x in ?? ()
Oops. Should have replied to r...@openssl.org. Sorry about duplicate. A.
Original Message
Subject: Re: [openssl.org #1998] [PATCH] SHA512 ROTR macro fix for
PowerPC using LP32 model
Date: Sat, 12 Sep 2009 18:57:58 +0200
From: Andy Polyakov ap...@fy.chalmers.se
Reply-To:
The build of 32-bit openSSL (openssl-0.9.8k) fails on x64 systems with
the following error (and more similar errors like these):
x86cpuid-elf.s:13: Error: suffix or operands invalid for `push'
This problem can be fixed by adding -m32 to Configure for the linux-elf
configuration, see the
--- a/crypto/aes/asm/aes-x86_64.pl
+++ b/crypto/aes/asm/aes-x86_64.pl
@@ -1994,10 +1994,12 @@ AES_cbc_encrypt:
??? What is it for version you have? In CVS .Lcbc_slow_enc_in_place
resided at line #1974! A.
I use CVS. It's an issue of patch sequence, I put another personal patch
before
I intend to dismiss this case as not our, but for-Debian-to-fix
problem. Naturally with reservation for keeping my eyes open for
possible solution in perlasm. Solution that will work with all supported
platforms but even without -Bsymbolic, just for completeness sake.
Though it will be
There is no assembly support for pe64.
Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules.
There is no support for GNU assembler under Win64, but masm (rather
known as ml64) and nasm are fully supported (though there are
requirements for least supported versions, for
Please merge.
last from this ticket(1753):
- openssl-000-msys-symlink.patch
- openssl-001-SNAP-20081003-mingw.patch
Merged with minor modification in domd
(http://cvs.openssl.org/chngview?cn=17706). a.
__
Fix two bugs in .Lcbc_slow_enc_in_place.
- At end of .Lcbc_slow_enc_in_place, %r10 instead of $_len should be
set to 16.
- In .Lcbc_slow_enc_in_place, %rdi should be initialized before stosb.
Thanks. The problem is addressed but in different way, see
Could you please test the other suggested bn_lcl.h modification? While
you're on it...
I cannot actually test it... I can compile and users may test.
I don't have a win64 machine.
How is it tested? Implicitly by an application being inter-operable with
another? Meaning that only only part
I managed to produce them myself with
mingw-w64-bin_x86-64-linux_20080921.tar.bz2. Modified sha512.c is fine,
Great!
My environment is gcc-4.3.2, binutils-CVS-head, mingw-w64-SVN-head as
20080921 is equipped with gcc-4.4.0 and whatever the rest it is equipped
with.
modified bn_lcl.h
Could you please test the other suggested bn_lcl.h modification? While
you're on it...
I am not fully sure that the crypto/sha/sha512.c is correct, it
simulate the behavior of win64 using Microsoft compiler, using
_rotr64 function as ROTR.
What you should have done instead is to modify macro
There is no assembly support for pe64.
Well, Win64 ABI is fully supported by OpenSSL x86_64 assembler modules.
There is no support for GNU assembler under Win64, but masm (rather
known as ml64) and nasm are fully supported (though there are
requirements for least supported versions, for nasm
Lutz Jaenicke via RT wrote:
Andrew Lamoureux via RT wrote:
Hi, I'd like to report a bug in openssl-0.9.8g compiled with
Visual Studio. OS is Windows XP.
Access violation occurs when BN_rshift() is used on a BIGNUM whose
bit length is less (amount required varies) than the number of
bits
When you try to establish DTLS connection you should use timeouts as said in
RFC. DTLS uses socket's timeouts. Windows sockets have some differences in
timeout API, but DTLS does not consider them. So when you set timeouts
with BIO_ctrl() and BIO_CTRL_DGRAM_SET_RECV_TIMEOUT or
401 - 500 of 768 matches
Mail list logo
