Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons, I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment.
I use CROSS_COMPILE=aarch64-gcc-7.5.0.
It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries, and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A.
I wonder is TF-A going to support MBEDTLS_AESCE_C option?
Thanks
Hi,
Right now, TF-A officially supports mbedTLS 3.3.0. We have not attempted to upgrade to version 3.4.0 yet but we will surely do that before the next TF-A release (which is planned in May).
I am not aware of any plans on Arm side to support mbedTLS's MBEDTLS_AESCE_C config option but we would welcome a contribution to add that support in TF-A!
From what you're saying, this looks more involved than just enabling MBEDTLS_AESCE_C macro inside mbedTLS config file.
Since this feature relies on the Armv8-A Cryptographic Extension, I suspect this might require compiling TF-A with "-march=armv8-a+crypto" option. It should be possible to change that through TF-A build option ARM_ARCH_FEATURE (see [1]). Did you try that? This might solve the issue you're seeing with NEON support.
If it doesn't, I suppose it means that the '+crypto' architectural switch does not play nice with -mgeneral-regs-only, in which case we might have to patch TF-A's build system. I see [2] that -mgeneral-regs-only always gets passed to the compiler so we might have to conditionally omit it when enabling crypto extensions support.
Could you please provide a log of the build failures you're observing, as well as your build command line? I was not able to reproduce it on my side but I might have missed something...
Regards, Sandrine
[1] https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-opt...
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/Makefile#n3...
On 4/7/23 13:32, Chen-Yu Yang via TF-A wrote:
Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons, I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment.
I use CROSS_COMPILE=aarch64-gcc-7.5.0.
It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries, and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A.
I wonder is TF-A going to support MBEDTLS_AESCE_C option?
Thanks
Hi,
On 4/11/23 15:34, Sandrine Bailleux wrote:
Since this feature relies on the Armv8-A Cryptographic Extension, I suspect this might require compiling TF-A with "-march=armv8-a+crypto" option. It should be possible to change that through TF-A build option ARM_ARCH_FEATURE (see [1]). Did you try that? This might solve the issue you're seeing with NEON support.
I got told that enabling MBEDTLS_AESCE_C will automatically enable "-march=armv8-a+crypto" compiler flag for the relevant mbedTLS compilation units. See https://github.com/Mbed-TLS/mbedtls/blob/development/library/aesce.c#L63 for example.
So my earlier suggestion is probably inaccurate.
Also, I got confirmation that this feature requires arm_neon.h like you said, as it uses intrinsics for the implementation. And as you rightly pointed out, TF-A does not use libgcc, which would typically provide these intrinsics (when building for GCC, at least!).
I am not sure how to solve this specific issue... TF-A traditionally uses a subset of compiler-rt library as a substitution for libgcc (see the compiler-rt subdirectory in TF-A tree). Perhaps we could pull in arm_neon.h in there, or maybe the compiler-rt project already has it.
We also had internal discussions as to whether the whole compiler-rt approach is good, or whether we should actually link TF-A against libgcc, which I guess would solve the issue at hand. But that's obviously a bigger piece of work!
Best regards, Sandrine
If it doesn't, I suppose it means that the '+crypto' architectural
switch does not play nice with -mgeneral-regs-only, in which case we might have to patch TF-A's build system. I see [2] that -mgeneral-regs-only always gets passed to the compiler so we might have to conditionally omit it when enabling crypto extensions support.
Could you please provide a log of the build failures you're observing, as well as your build command line? I was not able to reproduce it on my side but I might have missed something...
Regards, Sandrine
[1] https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/build-opt...
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/Makefile#n3...
On 4/7/23 13:32, Chen-Yu Yang via TF-A wrote:
Hi, I'm working in TF-A 2.8 with mbedtls, I notice that mbedtls-3.4.0 starts to support AES crypto extension(MBEDTLS_AESCE_C) for some security reasons, I upgrade mbedtls from 2.28.0 to 3.4.0, and try to enable MBEDTLS_AESCE_C in TF-A. I fail to compile mbedtls aesce.c in TF-A build environment.
I use CROSS_COMPILE=aarch64-gcc-7.5.0.
It seems that AESCE needs some std libraries(e.g. arm_neon.h) supported by aarch64 gcc, while TF-A disables std libraries, and some compile flags(e.g. -mgeneral-regs-only) are conflict with current TF-A.
I wonder is TF-A going to support MBEDTLS_AESCE_C option?
Thanks
tf-a@lists.trustedfirmware.org
-
Chen-Yu Yang -
Sandrine Bailleux