Andy, Your points are entirely valid (as usual!). By using the term IA32, I was trying to avoid discussing any specific product. You are correct that our implementation has no choice but to live within the confines of the existing instruction set. Our big-endian environment is entirely a product of the software.
For what it is worth, I have yet to encounter a commercial product that has reported a problem with endianness. It is certainly open to possibility, as you note. In my experience porting open-source packages, the trouble comes when developers attempt to extract the last bit of performance by dropping into assembly language. Perhaps commercial products aren't that ambitious, or perhaps I just haven't dealt with enough of them. I apologize for jumping to conclusions. It all sounded so familiar. I pretty much assumed the ancient version he was using was subjected to this issue. I should have dug deeper. I will take up the idea of __i386be with our compiler folks. I have not run across that macro before. For the record, Stratus supports many VOS/OpenVOS customers who use OpenSSL (and many other open-source packages) in their daily processing. OpenSSL works very well for them, and on their behalf (and mine), we're all grateful for the work that you and the other developers perform to maintain and enhance it. PG -----Original Message----- From: owner-openssl-...@openssl.org [mailto:owner-openssl-...@openssl.org] On Behalf Of Andy Polyakov Sent: Friday, April 13, 2012 5:32 AM To: openssl-dev@openssl.org Subject: Re: [openssl.org #2789] SHA-256 bug - Big endian arch Paul, > OpenSSL is just one of many open-source packages whose authors have > assumed that all IA32 implementations are little endian. No-no-no. IA is reference to processor architecture and all IA32 implementations *are* little-endian. You emulate big-endian execution environment on little-endian processor, but it doesn't make processor big-endian. This is unlike several families of CPUs that actually can operate in different endiannesses. Some can switch under software control, e.g. PowerPC, some are soldered to specific endianness, e.g. MIPS, when endianness is determined when you place processor on PCB and arrange specific pin to be connected to ground or not (or whatever equivalent). I'd guess SH is of latter kind, i.e. you can build either endian system with it. Then there also are processors that can access data [and data only] in specific byte order, e.g. Itanium, ARMv7, but it's different story. And do you mean that, unlike "authors of open-source packages", developers of commercial software are not prone to make such assumptions? :-) :-) :-) > I discovered > the same problem several years ago when we ported OpenSSL to the > Stratus VOS operating system, which is also big-endian on IA32. What is it you're trying to assert exactly? There that is bug in plain C SHA256 that has everything to do with endianness? But your own experience contradicts it. Indeed, if there was bug, you would suffer from it too. VOS-specific changes simply switch off inline assembler and assumptions of little endianness, but don't change a line of computationally significant code. Basically it's very same source after pre-processing that is fed to your and originator's compiler. > This > issue is so pervasive that when a numeric package fails on my system, > I immediately start looking for C macros of the form "__i386". I believe that we've touched suitability of __i386 on your platform. I'd argue that it shouldn't be even defined on your platform. You could have avoided all the problems (at least with badly authored open-source packages ;-) altogether by pre-defining say __i386be instead... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
