AES support (arm/arm64 vaeseq_u8) about ndk HOT 12 CLOSED

yeah, i've struggled to even explain the problem to the maintainer --- https://sourceforge.net/p/sevenzip/bugs/2383/

i don't think they think armv7 is a real thing.

from ndk.

Closing as it sounds like this is a 7-zip bug, not an NDK bug. If I've misunderstood, just lmk and we can reopen.

from ndk.

this would apply to other projects using AES encryption (not just 7-zip)

from ndk.

(my current workaround is to disable such AES/SHA256 code from compiling when targeting __ANDROID__ arm cpu's)

from ndk.

tho this then introduces a situation where x86 based android devices support AES encryption and arm based android devices do not support AES encryption

from ndk.

this would apply to other projects using AES encryption (not just 7-zip)

But in each case it's the projects that are wrong, right? The problem here is that projects are assuming availability of optional hardware features?

from ndk.

tho this then introduces a situation where x86 based android devices support AES encryption and arm based android devices do not support AES encryption

no, because Android's x86-64 ABI also doesn't include AES. (but again, you may happen to be running on a device that does, given that your x86-64 "device" is likely a modern laptop!) but if your code assumes x86-64 AES, it's still strictly wrong.

look at zlib for an example of how to do this kind of thing correctly.

from ndk.

#define ATTRIB_AES __attribute__((__target__("+crypto")))

This indicates that the code is trying to do the right thing. This attribute should build functions with aes support even if the source file isn't: https://godbolt.org/z/Ts934oox5. Can you check if the attribute is set at the relevant functions (or share a repro)?

how can i determine if support for the vaeseq_u8 intrinsic is actually present on my device

The library would also need to do runtime detection using a cpu-features library (or use ifuncs) to check if crypto is available on the device.

from ndk.

This indicates that the code is trying to do the right thing

well, for armv8 --- my point was that it's broken for armv7: https://sourceforge.net/p/sevenzip/bugs/2383/

from ndk.

well, for armv8 --- my point was that it's broken for armv7: https://sourceforge.net/p/sevenzip/bugs/2383/

Aah, yea, that's correct. @mgood7123 if you're already modifying the library code, use enh's suggested fix - to move the aes functions to a separate file and compile it for armv8.

from ndk.

so to be clear

on "desktop" x86 devices, AES support is (probably?) high

on "android" x86/arm devices, AES support is low (optional but probably only rarely actually supported in the cpu itself, eg one x86 device may have AES support while another x86 device lacks AES support)

would this be right?

from ndk.

on "android" x86/arm devices, AES support is low (optional but probably only rarely actually supported in the cpu itself, eg one x86 device may have AES support while another x86 device lacks AES support)

i don't think "high" or "low" are really the point --- the point is that it's not guaranteed so you need to check at runtime (with if ((getauxval(AT_HWCAP) & HWCAP_AES) != 0) for arm64, say), and then either call the routine that uses the instruction or a routine that doesn't.

lzma tries to do this but (as explained in https://sourceforge.net/p/sevenzip/bugs/2383/) they got it wrong, or at least "don't believe that armv7 still exists".

from ndk.