Adds sha3 to arm compile options which is needed for ios compilation.

[fwh-dc]

Fixes #1933

• Does this PR change the input/output behaviour of a cryptographic algorithm (i.e., does it change known answer test values)? (If so, a version bump will be required from x.y.z to x.(y+1).0.)
• Does this PR change the list of algorithms available -- either adding, removing, or renaming? Does this PR otherwise change an API? (If so, PRs in fully supported downstream projects dependent on these, i.e., oqs-provider will also need to be ready for review and merge by the time this is merged.)

[Martyrshot]

Thanks for the contribution! How would this behave on arm platforms that do not have the sha3 extensions?

[fwh-dc]

Thanks for the contribution! How would this behave on arm platforms that do not have the sha3 extensions?

TBH I don't know and I've trouble finding documentation on these flags. Perhabs you have some suggestions on where to look?

[baentsch]

Why is this not guarded/if'd by reference to ios ("APPLE"?) if it's indeed a problem only there?

[fwh-dc]

I don't know if it is Apple specific. As I stated in my previous comment I wasn't able to find any documentation on the flags. Do you know where to find the documentation? Maybe this affects other vendors than Apple?

[baentsch]

Do you know where to find the documentation?

Nope -- I'm out of my depth with ARM64.

[fwh-dc]

I'll take this one back to draft and have a look at your suggestion in the related issue. Maybe I can get it to work with the toolchain file of this project.

[cothan]

Hi @fwh-dc , this PR makes compilation on Cortex-A53 (as you can see in CI) failed. It does not have SHA3 extension.

[dstebila]

Tagging @hanno-becker to see if he has any insights on ARM compilation flags.

[hanno-becker]

I would recommend only using the sha3-flag if one is certain that the target platform supports it. Even if the SHA3-instruction-based Keccak implementation is not actually called, there is risk that a clever compiler will leverage general-purpose instructions such as eor3 in (auto-)vectorized code, leading to an invalid instruction abort at runtime.

How does one detect/convey more details about the target in CMake?

In addition, feat.S should unconditionally guard the code by __ARM_FEATURE_SHA3 (even on Apple).

[vincentvbh]

I would recommend only using the sha3-flag if one is certain that the target platform supports it. Even if the SHA3-instruction-based Keccak implementation is not actually called, there is risk that a clever compiler will leverage general-purpose instructions such as eor3 in (auto-)vectorized code, leading to an invalid instruction abort at runtime.

How does one detect/convey more details about the target in CMake?

In addition, feat.S should unconditionally guard the code by __ARM_FEATURE_SHA3 (even on Apple).

On my Apple M1, __ARM_FEATURE_SHA3 is not defined by default (it will be defined if one compiles with -march=armv8-a+sha3). So I agree with Hanno that currently by default we should compile with -march=armv8-a. A feature detection is recommended to pass +sha3 conditionally.

[vincentvbh]

Thanks for the contribution! How would this behave on arm platforms that do not have the sha3 extensions?

TBH I don't know and I've trouble finding documentation on these flags. Perhabs you have some suggestions on where to look?

The testing macros can be found here: https://developer.arm.com/documentation/101028/0012/5--Feature-test-macros. As hardware varies, you might want to test your target platforms yourself.

[fwh-dc]

Nice thanks. I'll see when I can find the time to have a look at it.