[openssl-dev] Making assembly language optimizations working on Cortex-M3

[Brian Smith]

Andy Polyakov <appro at openssl.org> wrote:

> > Cortex-M3 and Cortex-M4 processors are -mthumb, -march=armv7-m, which is
> > exactly the problematic configuration, if I understand that comment
> > correctly.
>
> The comment in question applies *exclusively* to cases when you attempt
> to build "universal" binary, one that works on multiple platforms, e.g.
> on ARMv6 and ARMv7.
>

<snip>

OK. Thanks for clarifying things.

> Has anybody started working on this?
>
>
> > If not, my thinking was to refactor the assembly language code so that
> > all the ARM-only (-marm) code is cleanly separated from the unified
> > (-mthumb and -marm) code,
>
> As implied, there are few assembly modules that *can* be compiled for
> Thumb-2 today, namely aes-armv4, bsaes-armv7, sha256-armv4,
> sha512-armv4.


Is there evidence that we can't adhere to this strategy of
> adjusting modules for ARM/Thumb-2 "duality"?


That sounds good to me.


> (BTW, can you confirm that you can get mentioned modules work?)
>

Yes, I am able to compile those modules:

git clone https://github.com/briansmith/openssl arm-openssl
cd arm-openssl
./configure-arm-none-eabi.sh
make depend
make

In particular, see this commit to understand the configuration:
https://github.com/briansmith/openssl/commit/ffa6e0c7a575184bc171b72a7ff3715bde460163

 I am using the toolchain from [1]:

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors)
4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 224288]


I ran out of time this weekend before I could test out the resultant
library though.


> > and recognize two new settings,
> > OPENSSL_NO_ARM_NEON and OPENSSL_ARM_THUMB_ONLY, to accommodate this.
>
> While NO_NEON might make sense, I really see no reason to introduce
> THUMB_ONLY. Because pre-defines set by the compiler driver are
> sufficient.


You mean, using __thumb__ (predefined for both thumb1 and thumb2) and
__thumb2__
(predefined for thumb2 only)?


> Actually, one can argue that even decision to omit NEON code
> can be made based on pre-defines, e.g. __ARM_ARCH_7M__. Well, this
> doesn't exclude possibility to define NO_NEON based on pre-define and
> using NO_NEON in code.


Right. If you are building for Cortex-A (armv7-a) then you may or may not
want the NEON detection, depending on how much you know about the users'
hardware in advance. Consequently, I think having an OPENSSL_ARM_NO_NEON
option is useful.


> A word of warning. When looking at ARM assembly code, you might find
> yourself asking "why isn't this done this way?" It's likely that answer
> to that question is "because old assembler fails to compile it." I mean
> there is certain level of legacy support there and it's not a coincidence.
>

Understood.

I also looked at some of the past commits where thumb2 support was added,
e.g. [2].

So, basically, we just need to (a) understand which modules are thumb2-only
and which aren't, and (b) adjust more modules to work for thumb2. I am
mostly interested in getting the AES-GCM and sha1 assembly language
optimizations working for this configuration. You mentioned in your message
that you already have ghash working for thumb2. Is that right?

[1] https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded
[2]
https://github.com/openssl/openssl/commit/e0202d946d68bd91a3e99f223c66d1fce7db136a

Thanks for your help!

Cheers,
Brian
--
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150809/f3cb0777/attachment-0001.html>