[openssl.org #1130] [PATCH] OpenSSL 0.9.8 general patches for Stratus VOS

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[openssl.org #1130] [PATCH] OpenSSL 0.9.8 general patches for Stratus VOS

Rich Salz via RT

These changes, together with the changes to the Configure script found
in ticket #1129, constitute the total set of changes needed to get
OpenSSL 0.9.8-beta5 to build and run its self-tests on the Stratus V
Series (Intel IA32) platform.  They are not needed for the Stratus
Continuum (PA-RISC) platform.  I tested these changes on a V400
running VOS Release 15.1.0ah.  I also successfully tested the same
changes on an Intel Pentium III running RedHat Fedora Core 1 (a native
little-endian IA32 platform), just to have some confidence that I had
not messed-up the underlying platform and endian independence.

Based on previous correspondence with the OpenSSL maintainers, I
realize that I may be stirring up some controversy with these changes.
I seem to be the only vendor who has a Big Endian IA32 environment.  
It is a true IA32 environment in all other respects (Xeon P4, 4-way,
HT, 1.6/2.8/3.0 GHz clocks).  We elected to implement a big-endian
programming model so that our customers would have a very simple job
converting from PA-RISC to Intel.

As an editorial comment, I would like to respectfully suggest that in
the future, platform tests (#ifdef __IA32__) be used to establish
attributes or qualities, and that the mainline source code test the
attributes or qualities.  The current source code tests __IA32__ and
related macros for several different reasons (e.g., instruction set,
endianness, alignment requirements, etc.)  Having it test attribute or
quality names would have been much more transparent.

I hope that these changes can be reviewed, modified if necessary, and
merged into 0.9.8 at some point.

Thanks
PG
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [openssl.org #1130] [PATCH] OpenSSL 0.9.8 general patches for Stratus VOS

Andy Polyakov
> These changes, together with the changes to the Configure script found
> in ticket #1129, constitute the total set of changes needed to get
> OpenSSL 0.9.8-beta5 to build and run its self-tests on the Stratus V
> Series (Intel IA32) platform.  They are not needed for the Stratus
> Continuum (PA-RISC) platform.  I tested these changes on a V400
> running VOS Release 15.1.0ah.  I also successfully tested the same
> changes on an Intel Pentium III running RedHat Fedora Core 1 (a native
> little-endian IA32 platform), just to have some confidence that I had
> not messed-up the underlying platform and endian independence.

Quoting sha_local.h before suggested change:

# ifdef SHA1_ASM
#  if defined(__i386) || ...
     ...
#  elif defined(__ia64) || ...
     ...
#  endif
# endif

and after applying submitted patch:

# ifdef SHA1_ASM
#  if !defined(B_ENDIAN)
#   if defined(__i386) || ...
      ...
#   elif defined(__ia64) || ...
      ...
#   endif
#  endif
# endif

If IA32 was the only one being tested, why was IA64 affected by the
suggested change? For reference, [all] our IA64 modules are maintained
endian-neutral. Furthermore. Note that this is protected by #ifdef
SHA1_ASM, which is *not* defined on VOS, meaning that suggested change
was never actually tested on the target platform. If so, why it was
called "patches *for* Stratus VOS":-) Same applies to corresponding #if
[MD5|RMD160]_ASM clauses...

Another fishy thing. In md32_common.h you suggested to add #ifndef
B_ENDIAN in DATA_ORDER_IS_LITTEL_ENDIAN part, but not in
DATA_ORDER_IS_BIG_ENDIAN. I wonder how come the latter didn't break on
your platform? As you mentioned yourself VOS gcc supports inline
assembler and neither OPENSSL_NO_ASM nor OPENSSL_NO_INLINE_ASM gets
defined by default... In otder words it should have break... Can you
shed some light?



Richard Levitte via RT wrote:

>>As an editorial comment, I would like to respectfully suggest that in
>>the future, platform tests (#ifdef __IA32__) be used to establish
>>attributes or qualities, and that the mainline source code test the
>>attributes or qualities.  The current source code tests __IA32__ and
>>related macros for several different reasons (e.g., instruction set,
>>endianness, alignment requirements, etc.)  Having it test attribute or
>>quality names would have been much more transparent.
>
> We do some tests like that, but using OpenSSL specific macros generated
> from the system name field in the configuration strings.  This is
> because we (or at least I) have run into trouble where different
> compilers support differents sets of flag macros for the same kind of
> function.  It kind of gets out of hand...

... because it takes too much discipline. We don't need to go far for
example. Take just posted "[PATCH] OpenSSL for Windows Mobile 2003" for
example, where we can read

-#if ... !defined(OPENSSL_SYS_WINCE)
+#if ... !defined(OPENSSL_SYS_WINCE) && !defined(PPC2003)

As far as I understand PPC2003 runs Windows CE... Yes, we can blaim them
for "not having the discipline(*)" to see the obvious and demand that
they define OPENSSL_SYS_WINCE... Or we could we have relied on
pre-defined _WIN32_WCE and use the remaining energy on being
creative/productive elsewhere. Note that it's perfectly safe to rely on
_WIN32_WCE here, because the first "if" is _MSC_VER.

As for #ifdef __i386. Trouble is that there're just too many
IA32/gcc-based platforms (not to mention that they *all* are
little-endian:-), which naturaly requires a lot of [synergy] discipline
to maintain multivalue OS/CPU matrix if we choose to totally switch to
own macros. And we would have to accept that own macros limits and makes
it hard/trickier to reuse code in alternative context.

In other words my position is that if vendor [or widely-accepted
de-facto standard] pre-defines are reliable enough to identify 99% of
platform, I wouln't hesitate to prefer them and spare productivity for
something else. Cheers. A.

(*) Please! Note that the expression "not having the discipline" is used
*solely* to clarify/emphasize the meaning of "discipline" mentioned in
the beginning of the rant and should not be taken literally.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [hidden email]
Automated List Manager                           [hidden email]