Implement AES backend for riscv64 using Zkned scalar crypto extensions

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.

[silvanshade]

This PR implements AES for riscv64 using the zkned scalar crypto extensions.

Some comments:

This will require nightly to build since the riscv64 intrinsics are unstable. However, it should be enough to just feature-gate on the respective riscv64 extensions, since those are only available on nightly.

Auto-detection of zkne and zknd is currently problematic.

It's possible to detect them (although I haven't tried that it actually works) with std::arch::is_riscv_feature_detected but this requires std and also requires the feature stdsimd (unstable).

The approach used by cpufeatures using libc::getauxval(libc::AT_HWCAP) won't work for riscv64 either. However, there is a new Linux syscall that exposes some riscv64 features: [https://www.kernel.org/doc/Documentation/riscv/hwprobe.rst](riscv_hwprobe).

Unfortunately, it doesn't expose the zkne or zknd features yet, although it looks like it is supposed to eventually, based on this code: https://github.com/clementleger/hwprobe_dump/blob/main/hwprobe.h

Hence, the approach I used here, where the backend is used if target_arch = "riscv64" and zkne and zknd target features are enabled.

I've opted not to add the hazmat module for riscv64 since supporting that is a little more complicated for riscv64 due to how the intrinsics work and how 1, 1.5, or 2 rounds are processed at a time depending on the key length.

Also, I don't have useful benchmarks since I don't have any riscv64 hardware with these extensions. However, the implementation produces the correct output and passes the tests when run with QEMU 8.0.4 on Ubuntu 23.10.

Regarding the CI config, I had some difficulty getting things to build and run properly with cross, and in any case a more recent QEMU is needed for the riscv64 extensions used here, so I used a custom docker image.

EDIT: Marking as draft again since I'm going to try and implement the vector version also.

[tarcieri]

Why did you close this?

[silvanshade]

Oops, I was trying to rename the branch in my local repo and guess it closed this automatically instead of reflecting the update.

I'll just re-open with the new branch though.