`libzt` on `arm`

[aarlt]

I tried compile libzt on an aarch64 linux machine. I'm getting the following errors:

/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h: In member function ‘void ZeroTier::AES::CTR::p_armCrypt(const uint8_t*, uint8_t*, unsigned int)’:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12438:1: error: inlining failed in call to always_inline ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
12438 | vaeseq_u8 (uint8x16_t data, uint8x16_t key)
      | ^~~~~~~~~
/home/alex/libzt/ext/ZeroTierOne/node/AES_armcrypto.cpp:160:18: note: called from here
  160 |     d0 = veorq_u8(vaeseq_u8(d0, k13), k14);
      |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/libzt/ext/ZeroTierOne/node/Constants.hpp:121,
                 from /home/alex/libzt/ext/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12452:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch
12452 | vaesmcq_u8 (uint8x16_t data)
      | ^~~~~~~~~~

Is there an easy way to solve these compilation problems?

[aarlt]

I think those errors are mainly coming from your crypto algorithms. Maybe it would make sense to just replace them with something like Botan.

[joseph-henry]

ZT proper definitely builds on that platform so it's just a matter of updating the libzt build process. I'll try to get you a patch today. We won't be adopting any new crypto libraries at this time however.

[aarlt]

Ah interesting! Thats awesome! Thx!

[aarlt]

Hmm.. just tried with ZF... it seem to have the same problem

[  3%] Building CXX object CMakeFiles/zerotiercore.dir/node/AES_armcrypto.cpp.o
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
                 from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h: In member function ‘void ZeroTier::AES::CTR::p_armCrypt(const uint8_t*, uint8_t*, unsigned int)’:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12438:1: error: inlining failed in call to always_inline ‘uint8x16_t vaeseq_u8(uint8x16_t, uint8x16_t)’: target specific option mismatch
12438 | vaeseq_u8 (uint8x16_t data, uint8x16_t key)
      | ^~~~~~~~~
/home/alex/ZeroTierOne/node/AES_armcrypto.cpp:160:18: note: called from here
  160 |     d0 = veorq_u8(vaeseq_u8(d0, k13), k14);
      |          ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
                 from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:
/usr/lib/gcc/aarch64-linux-gnu/9/include/arm_neon.h:12452:1: error: inlining failed in call to always_inline ‘uint8x16_t vaesmcq_u8(uint8x16_t)’: target specific option mismatch
12452 | vaesmcq_u8 (uint8x16_t data)
      | ^~~~~~~~~~
/home/alex/ZeroTierOne/node/AES_armcrypto.cpp:159:20: note: called from here
  159 |     d0 = vaesmcq_u8(vaeseq_u8(d0, k12));
      |          ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
In file included from /home/alex/ZeroTierOne/node/Constants.hpp:130,
                 from /home/alex/ZeroTierOne/node/AES_armcrypto.cpp:14:

[4h6h]

I am also interested in this issue here. Is there already a patch available? Thx!

[aarlt]

@joseph-henry you where correct. ZeroTier compiles without any problems using make, the compilation just fails if cmake is used. I agree, updating the build system should solve this issue.

[kmahyyg]

Can confirm that #179 fix this issue when cross-compiling against ARM64 on AMD64 Linux.

[glebm]

#179 is wrong because it assumes the optional Armv8A cryptography extension is always available. This extension is optional and isn't available on many CPUs, e.g. Raspberry Pi 4 does not support it and will crash with "illegal instruction" at runtime.

I've filed #205 with more details and a proposal for a different approach.

[joseph-henry]

Closing since solution was merged into upstream ZTO and the submodule was updated in libzt to include that fix. Thanks for your help everyone.