[openssl.org #1685] [BUG] OpenSSL 0.9.8h cannot be compiled by GCC 4.3.0 on MinGW
Hello,
I called ms\mingw32.bat and here we are the last console lines:
gcc -o tmp\set_key.o -Ioutinc -Itmp -DL_ENDIAN -DDSO_WIN32
-fomit-frame-pointer -O3 -march=i486 -Wall -DBN_ASM -DMD5_ASM
-DSHA1_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_NO_CAMELLIA
-DOPENSSL_NO_SEED -DOPENSSL_NO_RC5 -DOPENSSL_NO_MDC2
-DOPENSSL_NO_TLSEXT -DOPENSSL_NO_CMS -DOPENSSL_NO_KRB5
-DOPENSSL_NO_DYNAMIC_ENGINE -c .\crypto\des\set_key.c
.\crypto\des\set_key.c:68: error: static declaration of
'_hide_DES_check_key' follows non-static declaration
.\crypto\des\set_key.c:68: error: previous declaration of
'_hide_DES_check_key' was here
mingw32-make: *** [tmp\set_key.o] Error 1
I looked into e_os2.h and found that the macro
OPENSSL_IMPLEMENT_GLOBAL declares a variable both extern and static:
#ifdef OPENSSL_EXPORT_VAR_AS_FUNCTION
# define OPENSSL_IMPLEMENT_GLOBAL(type,name) \
extern type _hide_##name;\
type *_shadow_##name(void) { return _hide_##name; } \
static type _hide_##name
^^^
# define OPENSSL_DECLARE_GLOBAL(type,name) type *_shadow_##name(void)
# define OPENSSL_GLOBAL_REF(name) (*(_shadow_##name()))
#else
# define OPENSSL_IMPLEMENT_GLOBAL(type,name) OPENSSL_GLOBAL type
_shadow_##name
# define OPENSSL_DECLARE_GLOBAL(type,name) OPENSSL_EXPORT type
_shadow_##name
# define OPENSSL_GLOBAL_REF(name) _shadow_##name
#endif
I removed the modifier static marked above and compiled the package
successfully. What did you intend by declaring a variable both extern
and static?
Maybe the GCC 4.3.0 got too picky about such things. I think that you
can remove the modifier because the variable is getting exported
anyway.
I used gcc-4.3.0-20080502-mingw32-alpha-bin on Windows XP.
Cheers,
Ferda Prantl
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: How good a random source is Crypto API?
You may want to see the threads: BUG: CreateToolhelp32Snapshot First (initializing) call to RAND_status() very slow on Win32 An excerpt: Jeffrey Altman Thu, 14 Aug 2003 11:23:38 -0700 The reason that we go to all this trouble to examine alternative sources of randomness other than CryptGetRandom() is that Microsoft has refused to publish the sources of randomness which are used. Therefore, we have no ability to know whether or not the randomness reported by Windows is in fact random. However, it does not mean, that the method should be thread-unsafe and extremely slow under some circumstances... Ferda From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Reddie Sent: Monday, April 04, 2005 7:45 AM To: openssl-dev@openssl.org Subject: How good a random source is Crypto API? The non-thread-safe nature of RAND_poll for Win32 is something I need to address as it's impossible given the use of my library to expect RAND_poll to be called before other threads exist. This leads me to the question of how good a random source is the CryptGenRandom function on Windows. If it is a good enough source, then why bother with everything else that is done inside RAND_poll? The MSDN documentation makes it sound like similar things are being done for their random number seeding as is done in RAND_poll. Regards, Steven __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
First (initializing) call to RAND_status() very slow on Win32
Title: First (initializing) call to RAND_status() very slow on Win32 Hello, I am sorry for the long post, there is a question at the very end :-) (I sent it to the the openssl-users group at first, maybe you the developers are interested rather than users.) We integrate OpenSSL 0.9.6l compiled with standard settings and linked statically on Win32 and used on Windows XP, 2000 and 2003. The initialization of OpenSSL used within an extension module for Microsoft Sharepoint 2003 caused very long delays (15 - 30 seconds) during the first call. The method RAND_poll() called from RAND_status() was identified to cause this. There were more tests performed to ensure the validity of results, here we are typical perfomances of RAND_poll(). Here we are a test result of an unmanaged Win32 executable, of a managed .NET executable and of an extension module for Sharepoint 2003, with the unmodified OpenSSL, only the extended performance logging added (there is number of kernel objects in parentheses and time in milliseconds next to them): --+---+-+-- Win32 EXE .NET EXE SPS DLL Source of entropy WITH HEAPS --+---+-+-- (N/A) 15 (N/A) 16 (N/A) 0 netapi32.dll (NetStatisticsGet) (N/A) 63 (N/A) 15 (N/A) 0 advapi32.dll (CryptoAPI) (256) 16 (471) 297 (1200) 17391 kernel32.dll (Heaps) (51) 0 (45) 0 (44) 15 kernel32.dll (Processes) (509) 15 (506) 16 (676) 203 kernel32.dll (Threads) (13) 0 (45) 0 (169) 47 kernel32.dll (Modules) --+---+-+-- 140 344 17672 The whole RAND_poll(). --+---+-+-- The Sharepoint extension can be unloaded if idle, and server reloads it again if needed. Then happens the reinitialization again, which is painful when it is used in a search engine. The first hit is unacceptably slow then. What happens, when we abandon the heap inspection? What improves in the performance and what we loose in entropy? Here we are a test result of an unmanaged Win32 executable, of a managed .NET executable and of an extension module for Sharepoint 2003, with a modified OpenSSL, where only the heap walking was removed and the extended performance logging added (there is number of kernel objects in parentheses and time in milliseconds next to them): --+---+-+-- Win32 EXE .NET EXE SPS DLL Source of entropy WITHOUT HEAPS --+---+-+-- (N/A) 0 (N/A) 0 (N/A) 0 netapi32.dll (NetStatisticsGet) (N/A) 15 (N/A) 15 (N/A) 31 advapi32.dll (CryptoAPI) (50) 0 (46) 0 (51) 15 kernel32.dll (Processes) (504) 16 (510) 16 (722) 203 kernel32.dll (Threads) (13) 0 (45) 0 (172) 63 kernel32.dll (Modules) --+---+-+-- 31 31 344 The whole RAND_poll(). --+---+-+-- The achieved times are acceptable also on a server, where there are many kernel objects in use. Here we are a comparison, what entropy we achive with the current RAND_poll() without the heap walking: --++--- Bytes in buffer Bytes of entropy Source of entropy INCLUDED --++--- (120 + 68) (45 + 17) netapi32 (NetStatisticsGet + NetApiBufferFree, LanmanWorkstation + LanmanServer) (64 + 64) (64 + 64) advapi32.dll ( + CryptAcquireContextA + CryptGenRandom + CryptReleaseContext, RSA_FULL + INTEL_P5_PRG) 32 1 GlobalMemoryStatus 4 1 GetCurrentProcessId (4 + 20 + 4) (1 + 2 + 1) user32.dll ( + GetForegroundWindow + GetCursorInfo + GetQueueStatus) processes.count * 296 processes.count * 9 kernel32.dll (Processes + threads.count * 28 + threads.count * 6 + Threads + modules.count * 547 + modules.count * 9 + Modules) --++--- An example of an achieved entropy in a process in a Windows XP/2003 session: 10 processes, 500 threads, 10 modules: 196 + 40 * 9 + 500 * 6 + 10 * 9 = 3376 --- These bytes of entropy are still bigger than 1024 bytes, which can be considered an adequately secure random seed. Here we are the entropy, which had added the heap walking: --+-+-- Bytes in buffer Bytes of entropy Source of entropy REMOVED --+-+-- heaps.count * (16 heaps.count * (3 kernel32.dll (Heaps, + entries.count * 36) + entries.count * 5) entries can reach max. 80) --+-+-- An example of a lost entropy in a process in a Windows
RE: First (initializing) call to RAND_status() very slow on Win32
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernhard Froehlich Ferdinand Prantl wrote: Hello, I am sorry for the long post, there is a question at the very end :-) (I sent it to the the openssl-users group at first, maybe you the developers are interested rather than users.) We integrate OpenSSL 0.9.6l compiled with standard settings and linked statically on Win32 and used on Windows XP, 2000 and 2003. The initialization of OpenSSL used within an extension module for Microsoft Sharepoint 2003 caused very long delays (15 - 30 seconds) during the first call. The method RAND_poll() called from RAND_status() was identified to cause this. [...] Just one shot from the hip, can it be possible that you have directories in your PATH which are not acessible or are located on another computer which is currently down? OpenSSL on Win32 tries to load several DLLs on the first call to RAND_poll and therefore Win32 has to go through the PATH to find them. If there are invalid network directories in PATH Win32 needs some time to find out the facts... Thanks for the tip, Ted. I should have written more about the testing system. It is a VMware hosted installation, a cleanly installed Sharepoint 2003 server, where all paths are to the local windows directories and to our application directory. Another machine, where I run the small C++/.NET tests is normal Windows XP with only local directories in PATH. All directories on both systems exist. Sometimes I had 10-20 ms delay in LoadLibrary, when the system was under a bigger load, but... I made an extra crazy logging in a separate file from the whole method with entries for every call to be able to see which call does it. The slowness came directly from the loop where is the heap-walking, other parts were fast. Here is an example: RAND_poll: fopen(perflog_logfile): 0 RAND_poll: GetVersionEx: 0 RAND_poll: 4x LoadLibrary: 0 RAND_poll: 2x GetProcAddress: 0 RAND_poll: 2x netstatget: 16 RAND_poll: FreeLibrary: 0 RAND_poll: All Network: 16 RAND_poll: 3x GetProcAddress: 0 RAND_poll: 2x CryptGenRandom: 15 RAND_poll: LoadLibrary: 0 RAND_poll: All CryptoAPI: 15 RAND_poll: readtimer: 0 RAND_poll: GlobalMemoryStatus: 0 RAND_poll: GetCurrentProcessId: 0 RAND_poll: All Status: 0 RAND_poll: 3x GetProcAddress: 0 RAND_poll: GetForegroundWindow: 0 RAND_poll: GetCursorInfo: 0 RAND_poll: GetQueueStatus: 0 RAND_poll: FreeLibrary: 0 RAND_poll: All Windows: 0 RAND_poll: 12x GetProcAddress: 0 RAND_poll: Heap(471): 297 RAND_poll: Processes(45): 0 RAND_poll: Threads(506): 16 RAND_poll: Modules(45): 0 RAND_poll: ?x CloseHandle: 0 RAND_poll: FreeLibrary: 0 RAND_poll: All Kernel: 313 RAND_poll: All: 344 What is interesting, 471 heap entries takes much more time than 506 thread entries. OK, I can understand the slowness, if many big heaps are present; this code is run the worst count_of_heaps * 80 times: RAND_add(hentry, hentry.dwSize, 5); I myself have never seen such a slow RAND_poll, so I'd think the problem has to be located somwhere on your computer. Neither have I, until now... :-) What is interesting, this extrem slowness occurs only in our testing VMWare host (installed clean from the scratch). A standalone machine behaves cca 10 times faster, but still is the heap walking almost 20x slower as the other ways of computing entropy. Do you think, that the heap-walking gives an amount of entropy worth its performance costs? (Only the thread-walking can give more.) Hope it helps, Ted ;) Well, I solved it for me by patching the openssl in our production as our release draws nearer and nearer. I am attaching the file with the extended logging and the diff to rand_win.c which turns the heap-walking off, if anyone are interested. I can also test it further, should you like to have more information. thank you, Ferda rand_win.c.logging Description: rand_win.c.logging rand_win.c.diff Description: rand_win.c.diff
