I'd suggest to move the discussion to openss-dev, as I unfortunately
don't have time to follow openssl-users.
> I tried using the AES-assembler code for my PowerPC EABI, but
> everytime I start "speed aes" my OS crashes. The 32Bit OS is a custom
> one.
OS crashes? Not application, but OS?
> The first problem was the usage of r13. On Page 3 of the PowerPC EABI
> spec [1], the r13 register is described as a dedicated register. So
> the usage of such a register is delicate.
Other ABI specs are not as categorical about r2 and r13. I was told by
IBM that r2 is used as TLS pointer in 32-bit OSes and r13 in 64-bit
ones. As signal handler is allowed to reference TLS pointer, these
registers were left alone. Referred specification says that *both* r2
and r13 can be dereferenced in signal/exception handler...
> I could not use it because it is forbidden in our startup code. But
> at Line 101 of "crypto/aes/asm/aes-ppc.pl" I found a workaround for
> the 64 bit case, which replaces r13 with r0.
>
> # stay away from TLS pointer
> if ($SIZE_T==8) { die if ($t1 ne "r13"); $t1="r0"; }
> else { die if ($Tbl3 ne "r2"); $Tbl3=$t0; $t0="r0"; }
>
> So in the aes-ppc Perl source I replaced r13 with r0 at line 77,
> which made the line 538
> lwz $t1,4($key)
> execute smoothly.
Presumably this is circumstantial. In sense that it worked solely
because exceptions didn't happed to dereference r2 at times subroutine
in question was executing. In other words, replacing r13 with r0 is not
sufficient, and the only right thing to do is to leave alone *both* r2
and r13. One can off-load $out to stack and use r4 instead of r13.
> The second and much more delicate problem was the "LAES_Te" symbol:
> why do we need this piece of code?
LAES_T[ed] returns pointer to the S-box in position-independent manner
that is not OS-specific. Position-independence is a must for shared
libraries, and OS independence was easier to implement than to make
multiple all 6 OS flavors work and maintain.
> Would it be safe to leave it
> aside? I'm asking because this code (in my case) overwrites r3,
> therefore leaving me without access to the first argument of the
> whole function. Because the value of the link register is saved in
> r3,
Why is r3 concern for *you*? I mean why would you insist on having
access to original value of first argument? By the time it's overwritten
it's "used up" (input is loaded into registers) and you don't need the
value anymore.
> the "out" argument
"out" argument is r4, not r3.
> will point to the .text section,
It's conscious decision. Normally you'd put S-box into a read-only
section such as .const, but .text is as good. Moreover, some compilers
do this all by themselves.
> and thus the
> whole code will crash if the MMU prohibits accesses to this section.
Is it possible to program PPC MMU so that it would allow execution but
prohibit read access? At the very least having S-box in .text segment
was proven to work on all 6 supported OS flavors. If it's possible *and*
if your OS actually does it, then S-box should be placed elsewhere and
pulling its address should be different in your case.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
