> That sounded like it was in another asm file. But I didn't go through and > check to see if the resoultion in that report was applied to all ASM other > files.
>Even though it's addressed...it's believed that real culprit is not > OpenSSL, but some other code that incorrectly adds 32-bit value to > segment in question prior OpenSSL 1. I'm not a perl guy, don't even like looking at perl much :) So I wasn't sure if that file actually applied to each asm file, or if it was being used to generate only one asm file. I suppose I could have read more in depth, but since this was only ancilary to my main task at best, and a search for x86_64cpuid.asm and cpuid pulled up nothing relevant, I figured I'd fire off a quick e-mail. I also set my alignment for 16 byte, and searched for align(16) and again found nothing relevant, perhaps I should have tried DWORD or 8...my apologies then if given that information, this is a duplicate. 2. In the reported case, he mentioned he was doing static libs. I don't do static libs. Too much hassle later when upgrading... 3. I ran this through the debugger and upon stepped through found each dll gets a seperate pointer to the segment. OpenSSL's was >64 bytes of NULLs, followed by a misaligned pointer to OPENSSL_cpuid_setup, followed by many more NULLs. I can give you exact counts if you think it would help. Other DLLs sections were completly different/in completly different areas of the virtual address space. The program was only also linked to the standard windows libraries, and my code is all aligned on 16 byte boundries (and I use _aligned_malloc for my heap buffers too!) since I do some SSE stuff, and do not like having to use movdqu over movdqa :) The machine is Windows 7, SP1. Problem existed compiling with Visual Studio 2008 SP1, and Visual Studio 2010. I suppose I should also mention I configured it to include rc5 and md2, as I needed both of those for what I'm doing. (yes, I understand the vulnerabilities :) ) Oh, other pertinent information, this was a debug build, so my C flags relating to the C runtime and optimization included /MDd /Od (Disabled) . Building in release mode actually worked fine. My release mode flags relating to optimization were /MD /Ox /Ob2 /Oi /Ot /Oy /GL. My suspicion is that /Ot, ignoring code size, aligns everything on an 8/16 byte boundry for speed. Though it could have been any of the other options as well. Also of note, openssl.exe, as well as bftest.exe, md2test.exe md5test.exe sha1test.exe and a few more randomly selected test exes produced by the OpenSSL build also crashed on startup with the same problem. 4. I don't really understand the logic of wanting to specify an alignment less than processor word size. Sure generally the worst that should happen is a cache line split, but in this case, since it appears that the MS CRT interprets the section as a processor word size aligned array of pointers (also of processor word size) the worst that can happen is the the full pointer isn't read, and a function call is made to an unmapped section of the virtual address space leading to a crash. I understand code size can be an issue for embedded platforms, however, with the possible exception of windows CE/Mobile/whatever they're calling it these days, I don't think any other platform is going to include a .CRT$XCU in a PE file, so it shouldn't really effect any other platform. Should the windows CE CRT use the same initialization mechanism, I would guess it too needs that section aligned on a machine word size boundry or greater. Again, if the perl file in the referenced bug report applies to each asm file, then sorry for the duplicate, and either way, at worst, hopefully this explains why the problem is in fact an OpenSSL issue. Corry On Thu, May 3, 2012 at 12:08 PM, Andy Polyakov via RT <[email protected]> wrote: >> You're alignment is off on the line readinf .CRT$XCU SEGMENT >> READONLY DWORD. >> You need to set that to at least be ALIGN(8) I would think since x64 >> is 8 byte, but the stack is supposed to be on 16 byte boundries, so in >> mine, I run the configure, then do_win64a, then manually edit the >> generated .asm file. This causes the program to crash on startup. in >> msvcr100d.dll function initterm. You can clearly see the alignment is >> off by pulling up a memory window and putting in pfbegin. You'll see >> half the function pointer in one DQWORD, and part in another. Spent a >> day trying to figure out what I was doing wrong in the build >> process... > > See > http://rt.openssl.org/Ticket/Display.html?id=2620&user=guest&pass=guest. > Even though it's addressed, it's believed that real culprit is not > OpenSSL, but some other code that incorrectly adds 32-bit value to > segment in question prior OpenSSL. When you say "half the function > pointer in one QWORD, and part in another", question is what is just > *before* the splitted pointer? Where does this value come from? Point is > that there are more reasons to fix *that* code. I'm not saying that > there is no reason to fix OpenSSL (it *was* fixed), I'm only saying that > some other code must be even more wrong. > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
