Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Andy Polyakov appro at openssl.org writes: I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. As mentioned [in another reply], I was under impression that x64 code is always position-independent, i.e. I'd expect x64 to work even if relocated. Oh well... Closer look revealed that .text segment, code itself, *is* indeed position-independent, but not .rdata, which is also fingerprinted. In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev at openssl.org Automated List Manager majordomo at openssl.org I am facing same issue when I built x64 version of FIPS object module (1.2.3)and openSSL 0.9.8.u on Windows 7 with Visual Studio 2010. As suggested in this thread, I have edited the openssl-0.9.8u\ms\ntdll.mak and added /FIXED flag in LFLAGS as below. LFLAGS=/FIXED /nologo /subsystem:console /opt:ref Now, out32dll/fips_test_suite.exe running successfully after compiling with /FIXED linker option. However, my sample application which is linking dynamically with libeay32.dll is returning same finger print mismatch error.Sample application also links with /FIXED linker option. dumpbin shows no randomization code in DLL characteristics for both libeay32.dll and sample application. Here is the link lines for libeay32.dll: perl util\fipslink.pl /FIXED /nologo /subsystem:console /opt:ref /dll /map /base:0xFB0 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\VIMOL_~1\AppData\Local\Temp\nm9209.tmp Value of DLL characteristics from dumpbin: 100 DLL characteristics NX compatible Is the above value of link line and DLL characteristics correct? Or did I miss anything? Or is OS forcefully loading the libeay32.DLL at randomized address? Thanks, -Vimol __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2789] SHA-256 bug - Big endian arch
HI, You are right, the optimalisations are the issue. When I compile it with O0 then it's OK. I also found that problem occurs in macros Siga0,1 Maj, ... Wth O0 there are correct valus but with O2 there are incorrect values. Compiler must have some problem there. ( I also test to modify variables declaration to volatile and that helps too. ) So definetly we could close this issue with result broken compiler. ( which really makes me unhappy) Many thanks for your time. Best regars Pavel __ Od: Andy Polyakov via RT Komu: Datum: 14.04.2012 10:41 P?edm?t: Re: [openssl.org #2789] SHA-256 bug - Big endian arch We have been using older version of Openssl (0.9.8c) and this one has same problem. Even though 0.9.8c is more sensitive to endianness (sha256_block function accepts additional 'host' flag, which caller can get wrong), it should have worked as long as -DB_ENDIAN is passed. Later versions work even without [LB]_ENDIAN. But in either case endianness was always taken into account and code was actually tested on both big- and little-endian platforms. Used compiler is not perfect and often has prolem with O3 so i already tried Os (doesn't work) and O2 - thats work ok. So I suppose that optimalisations are not the issue. You don't know that till you pass -O0. Please do test. I tested both SMALL FOOTPRINT and normal code and both has same problem. I also have own SHA256 implementation ( implemented as defined in standard ) from another project. So when I replace the core of SHA256 computation (sha256 hash update ) with my implementation it works ok. Then all tests (make tests) passed without errors. So it's not exactly endian problem, but SHA256 implementation on SH architecture. Does it mean that we agree that it looks more like compiler problem than problem with OpenSSL source code? Our implementation is using rotation as defined in standart but Openssl uses opposite. I find it hard to believe that rotation direction is responsible. SH3 architecture in Big endian is not so common so there could be some unexpected bahaviour in compiler. SH processors are capable of operating in either endianness. So that formally you can't say SH *architecture* is big-endian, you can only say this particular SH-based system is big-endian. As far as I understand endianness is determined by logical level fed to specific CPU pin at power-up. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Compile error with MinGW-w64
On 14/04/2012 12:50 AM, Andy Polyakov wrote: What happens if you add wait; at the very end of crypto/asm/sha1-x86_64.pl? It just hangs. Regards, Jonathan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
Andy Polyakov appro at openssl.org writes: I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. As mentioned [in another reply], I was under impression that x64 code is always position-independent, i.e. I'd expect x64 to work even if relocated. Oh well... Closer look revealed that .text segment, code itself, *is* indeed position-independent, but not .rdata, which is also fingerprinted. In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev at openssl.org Automated List Manager majordomo at openssl.org I am facing same issue when I built x64 version of FIPS object module (1.2.3)and openSSL 0.9.8.u on Windows 7 with Visual Studio 2010. As suggested in this thread, I have edited the openssl-0.9.8u\ms\ntdll.mak and added /FIXED flag in LFLAGS as below. LFLAGS=/FIXED /nologo /subsystem:console /opt:ref Now, out32dll/fips_test_suite.exe running successfully after compiling with /FIXED linker option. However, my sample application which is linking dynamically with libeay32.dll is returning same finger print mismatch error.Sample application also links with /FIXED linker option. dumpbin shows no randomization code in DLL characteristics for both libeay32.dll and sample application. Here is the link lines for libeay32.dll: perl util\fipslink.pl /FIXED /nologo /subsystem:console /opt:ref /dll /map /base:0xFB0 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\VIMOL_~1\AppData\Local\Temp\nm9209.tmp Value of DLL characteristics from dumpbin: 100 DLL characteristics NX compatible Is the above value of link line and DLL characteristics correct? Or did I miss anything? Or is OS forcefully loading the libeay32.DLL at randomized address? Thanks, -Vimol __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2791] [PATCH] fix -DOPENSSL_NO_SOCK on sunos
Hi, This patch compiles out BIO_socket_nbio() and the body of BIO_new_ssl_connect() if OPENSSL_NO_SOCK is set. * BIO_socket_nbio() looks like its author forgot to put it in the #ifndef block. * BIO_new_ssl_connect() calls BIO_s_connect() which is compiled out by OPENSSL_NO_SOCK. It makes the linker on Solaris error out. I would appreciate it if you could land this patch. Thanks, Ben Noordhuis 0001-fix-DOPENSSL_NO_SOCK-on-sunos.patch Description: Binary data
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On Sun, Apr 15, 2012, Vimol Kshetrimayum wrote: Andy Polyakov appro at openssl.org writes: I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. As mentioned [in another reply], I was under impression that x64 code is always position-independent, i.e. I'd expect x64 to work even if relocated. Oh well... Closer look revealed that .text segment, code itself, *is* indeed position-independent, but not .rdata, which is also fingerprinted. In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev at openssl.org Automated List Manager majordomo at openssl.org I am facing same issue when I built x64 version of FIPS object module (1.2.3)and openSSL 0.9.8.u on Windows 7 with Visual Studio 2010. As suggested in this thread, I have edited the openssl-0.9.8u\ms\ntdll.mak and added /FIXED flag in LFLAGS as below. LFLAGS=/FIXED /nologo /subsystem:console /opt:ref Now, out32dll/fips_test_suite.exe running successfully after compiling with /FIXED linker option. However, my sample application which is linking dynamically with libeay32.dll is returning same finger print mismatch error.Sample application also links with /FIXED linker option. dumpbin shows no randomization code in DLL characteristics for both libeay32.dll and sample application. Here is the link lines for libeay32.dll: perl util\fipslink.pl /FIXED /nologo /subsystem:console /opt:ref /dll /map /base:0xFB0 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\VIMOL_~1\AppData\Local\Temp\nm9209.tmp Value of DLL characteristics from dumpbin: 100 DLL characteristics NX compatible Is the above value of link line and DLL characteristics correct? Or did I miss anything? Or is OS forcefully loading the libeay32.DLL at randomized address? Try adding: /fixed explicitly to the linker rule for libeay32.dll, it is the section beginning: $(O_CRYPTO): ... Alternatively you can add it to the MLFLAGS line in the makefile but that will affect ssleay32.dll too. If that doesn't work try /dynamicbase:no /fixed Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2778] [BUG:] OpenSSL 1.0.1 x86_64: d1_pkt.c(444): OpenSSL internal error, assertion failed: t = 0
http://cvs.openssl.org/chngview?cn=22334 is interim solution, proper solution will be provided at later point (if found appropriate). Thanks, this circumvents the DTLS issue. The TLS empty fragments issue remains, http://cvs.openssl.org/chngview?cn=22390 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
Here is an experimental patch I wrote that implements the 1/n-1
record splitting technique for OpenSSL. I am sending it here for
consideration by OpenSSL upstream developers.
By default the 0/n split is used but in case the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first
record with 1/n-1.
What would you [and others] say about this alternative? Non-committed,
relative to HEAD...
Index: ssl/s3_pkt.c
===
RCS file: /e/openssl/cvs/openssl/ssl/s3_pkt.c,v
retrieving revision 1.94
diff -u -w -r1.94 s3_pkt.c
--- ssl/s3_pkt.c15 Apr 2012 14:14:22 - 1.94
+++ ssl/s3_pkt.c15 Apr 2012 14:41:08 -
@@ -685,13 +685,14 @@
/* countermeasure against known-IV weakness in CBC ciphersuites
* (see http://www.openssl.org/~bodo/tls-cbc.txt) */
- if (s-s3-need_empty_fragments type ==
SSL3_RT_APPLICATION_DATA)
+ if (s-s3-need_empty_fragments type ==
SSL3_RT_APPLICATION_DATA len1)
{
/* recursive function call with 'create_empty_fragment'
set;
* this prepares and buffers the data for an empty
fragment
* (these 'prefix_len' bytes are sent out later
* together with the actual payload) */
- prefix_len = do_ssl3_write(s, type, buf, 0, 1);
+ prefix_len = do_ssl3_write(s, type, buf, 1, 1);
+ buf++, len--;
if (prefix_len = 0)
goto err;
@@ -827,6 +828,10 @@
*/
return wr-length;
}
+ else if (prefix_len)
+ {
+ buf--, len++;
+ }
/* now let's set up wb */
wb-left = prefix_len + wr-length;
Re: Compile error with MinGW-w64
What happens if you add wait; at the very end of crypto/asm/sha1-x86_64.pl? It just hangs. 'which perl'? If not /bin/perl, i.e. non-MSYS perl, then I'd suggest to complement MSYS installation with MSYS perl. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2781]
Leandro Santiago via RT wrote: I also tested with mingw64:gcc and mingw:gcc. The results were the same in the three machines. And I'm using a no-patched openssl downloaded from openssl.org. Where :gcc come from? As Roumen mentioned, it's mingw [or mingw64], not mingw:gcc, mingw32:gcc, nor ming64:gcc. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
