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

open-quantum-safe / liboqs

C library for prototyping and experimenting with quantum-resistant cryptography

https://openquantumsafe.org/

Other

1.92k stars 466 forks source link

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

Open fwh-dc opened 2 months ago

fwh-dc commented 2 months ago

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 commented 2 months ago

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

fwh-dc commented 2 months ago

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?

dstebila commented 2 months ago

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

hanno-becker commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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