2009/9/23 Victor B. Wagner <vi...@cryptocom.ru>: > Mingw does. It have header except.h, which defines __try1 and __except1 > which do some assembler black magic. > > Unfortunately I don't know windows internals enough to tell from the > glance if this magic correct or not. So, I haven't tried to use > them in RAND_poll.c. If somebody would provide me a test program which > reproducibly generates a SEH, I would give it a try.
Hm. simplest route would be forcing a NULL pointer dereference (or better yet: write access) to see if gcc/mingw would catch that at run-time; something like char *s = NULL; *s = 'a'; /* bang! */ might need to do it in a more circumspect way to shut up the analyzer in gcc, which is probably smart enough to yack about this one, but char *s = get_me_a_pointer(); *s = 'a'; would probably do it. (where get_me_a_pointer() would produce a NULL pointer or some other nasty address value casted to a 'char *'. > Really, mingw compiling for Win32 have some advantages and it is no > a good idea to drop mingw support entirely (which is effectively done > with this "fix"). No worries, hold your horses. the fix as it was doesn't 'drop' support for mingw; yes, it removes one of the (multiple, all Win32 specific) possible randomness sources from the list for non-MSVC builds, but that's all. > 1. You don't need windows to build something with mingw. If you are > developing cross-platform applications, you can compile for all > platforms on the same machine. Zen-time. ... Okay. The code that's impacted by the fix is extremely Win32/64 specific. Cross-platform builds, on the other hand and irrespective of setup (mingw or other), mean quite different code sections of RAND_poll et al will be enabled (sometimes different source files even): non-Windows platforms execute very different code sections in there, which logically don't contain a single Win32 call so don't ever get to see the __try/__except section anyways, much the same way as me and my MSVC never get to hit any /dev/egd device code (situated in rand_unix.c). A cross-platform build with, say, a UNIX target, while compiled and build on a Windows platform, collects and compiles code which is suitable for the target platform; the issue is irrelevant for anybody outside the Windows /target platforms/, no matter what system was used to produce the binaries. Then there's also big differences between various Windows platforms in there too: scan the code for WinCE versus desktop Windows2000-and-above and other windows platforms in the precompiler conditionals. The whole point is: grab entropy where you may find some, as much and in as many places as you can think of, with the only condition that crashing the application while doing so is extremely undesirable. Here was/is a bit of entropy gathering code which has a noted risk of crashing the application, hard, unless you've got some very peculiar countermeasures in place. Anyway, the major news here is that mingw has something that smells like it, might even feel like it, so let's have a look and see if it works like it. When it turns out as a 'yes', then it'd be great to have it included in there. Can't ever have enough entropy input. >> So unless someone can teach me the error of my current ways regarding >> SEH and gcc on Win32/64, I'd say that __try/__except encased section > > Really, mingw have define SEHNOOP, which makes __try and __except empty. > But it is not a good thing, because it doesn't actually catch an > exception. But for now I use it for my mingw cross-builds. Eek. Let's go for those __try1/__except1 boys you mentioned instead and see if they deliver. I think a little test program which just does an NULL-address write like the two lines I wrote above, wrapped in that __try1/__except1 stuff and a few printf()s to see where the run-time passed through, should give a good enough answer whether we've got something usable here, or not. Can you help me out by trying that? (I don't have mingw around here; corporate directive.) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
