briansmith / ring

Safe, fast, small crypto using Rust
Other
3.64k stars 683 forks source link

Implement detection if CPU doesn't support hardware AES crypto. #2046

Closed Arne91 closed 2 months ago

Arne91 commented 2 months ago

Pull request as solution of issue #1858 Illegal instruction on arm-a72

Arne91 commented 2 months ago

Introduces a new check to ensure that the target CPU actually supports AES hardware cryptography. Previously, the Rust compiler might assume that all aarch64 CPUs support AES hardware acceleration, which is not always the case. For instance, devices like the Raspberry Pi 4, despite being aarch64, do not have this capability.

The lack of an explicit check for AES support lead to a runtime errors with "illegal instruction" when cryptographic operations are assumed to be hardware-accelerated but are not. With this update, the code now explicitly verifies the availability of AES hardware cryptography before attempting to use it, enhancing reliability and performance on diverse architectures.

briansmith commented 2 months ago

Are you saying that getauxval indicates that AES instructions are available, even when they aren't?

briansmith commented 2 months ago

. Previously, the Rust compiler might assume that all aarch64 CPUs support AES hardware acceleration, which is not always the case.

Are you sating that the compiler always evaluates cfg!(target_feature = "aes") to true for aarch64-unknown-linux-gnu? Or some other linux target? If it is a different Linux target, what is the target? I am not seeing that using these commands:

$ rustc +1.61.0 --print cfg --target=aarch64-unknown-linux-gnu | grep feature
target_feature="neon"
target_feature="pmuv3"
$ rustc --version
rustc 1.78.0 (9b00956e5 2024-04-29)
$ rustc --print cfg --target=aarch64-unknown-linux-gnu | grep feature
target_feature="neon"
Arne91 commented 2 months ago

. Previously, the Rust compiler might assume that all aarch64 CPUs support AES hardware acceleration, which is not always the case.

Are you sating that the compiler always evaluates cfg!(target_feature = "aes") to true for aarch64-unknown-linux-gnu? Or some other linux target? If it is a different Linux target, what is the target? I am not seeing that using these commands:

$ rustc +1.61.0 --print cfg --target=aarch64-unknown-linux-gnu | grep feature
target_feature="neon"
target_feature="pmuv3"
$ rustc --version
rustc 1.78.0 (9b00956e5 2024-04-29)
$ rustc --print cfg --target=aarch64-unknown-linux-gnu | grep feature
target_feature="neon"

Thanks for your reply.

Yes, when I build with target cpu set to cortex-a72, I get the "aes" feature. Unfortunately I am not at my workstation (rapsberry pi 4 and my work laptop) at the moment. On Monday I will give you more details on what the problem is.

briansmith commented 2 months ago

Yes, when I build with target cpu set to cortex-a72

Thank you. I understand now exactly what the issue is; see https://github.com/briansmith/ring/issues/1858#issuecomment-2093675988. I am going to close this PR because I don't think this PR is on the right track.