Stabilize RISC-V Zk and Zb intrinsics

[TechnoPorg]

Stabilization report

Summary

These intrinsics allow using instructions from the RISC-V ratified scalar crypto extensions and bit manipulation extensions. This includes:

• The AES block cipher extensions Zkne and Zknd
• The SHA-2 extension Zknh
• The bit manipulation extension Zbkb
• The carry-less multiply extension Zbkc
• The cross-bar permutation extension Zbkx
• The SM4 block cipher extension Zksed
• The SM3 hash function extension Zksh

These have the potential to significantly accelerate cryptographic operations on both RV32 and RV64 devices.

Tracking:

• Tracking Issue for RISC-V Ratified Extensions Intrinsics rust#114544

What isn't stabilized

Other RISC-V ratified extension intrinsics, such as the packed SIMD extension P.

Design

Answers to unresolved questions

From the tracking issue:

Use usize for riscv32 or riscv64 specific intrinsics or use u32 and u64 respectively?

The conclusion in rust-lang/rust#114544 from the libs team is that for this set of intrinsics, u32/u64 are preferable. This matches the way they are used by current nightly consumers and feels more appropriate given that these operate on data and not addresses.

Feedback

Nightly use

• The sha2 crate uses these intrinsics for a nightly-only Zknh backend.
• https://github.com/nazar-pc/abundance uses these intrinsics for bit manipulation operations.
• https://github.com/sayantn/aes uses these intrinsics for an AES implementation.

In all of these, u32/u64 are more ergonomic than usize.

Breaking changes

None.

History

• Implement RISC-V Zk intrinsics #1453 implemented the Zk intrinsics
• Implement RISC-V Zb intrinsics  #1461 implemented the Zb intrinsics

Acknowledgments

• @coastalwhite for the implementation

Open items

• Requires Make RISC-V bit manip intrinsics use u32/u64 instead of usize #2247
• Requires Remove rustc_legacy_const_generics from unstable intrinsics #2254
• Requires fuzz testing for intrinsics
• Tracking Issue for RISC-V Ratified Extensions Intrinsics rust#114544 (comment): do we want to add intrinsics for patterns that can be expressed in normal Rust code? cc @Amanieu as someone who has previously opposed this idea

---

No LLMs were used to write this PR.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project has assigned @sayantn (or someone else) to review your changes, you should hear from them (or someone else) within the next two weeks.

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn
• @Amanieu, @adamgemmell, @davidtwco, @folkertdev, @sayantn expanded to Amanieu, adamgemmell, davidtwco, folkertdev, sayantn
• Random selection from Amanieu, adamgemmell, davidtwco, folkertdev, sayantn

[TechnoPorg]

Whoops meant to open this against my fork... let me quickly write a stabilization report!

[rustbot]

Error: The feature shortcut is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[tgross35]

Also yes, this should be removed from stabilized intrinsics rust-lang/rust#149654. You could also put up a separate PR removing them from all RISC-V stdarch, if interested. (Or even more if there are arches aside from arm, aarch64, and x86 that use it).

View changes since the review

[TechnoPorg]

Opened #2254

[sayantn]

#2255

@rustbot reroll

[tgross35]

@rustbot blocked

Based on rust-lang/rust#114544 (comment), we'd like to change to match the C API first. We should make sure there is fuzz testing against C intrinsics as mentioned in #2221 (comment).

[rustbot]

Error: The feature shortcut is not enabled in this repository.
To enable it add its section in the triagebot.toml in the root of the repository.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.

[TechnoPorg]

Based on rust-lang/rust#114544 (comment), we'd like to change to match the C API first.

I've just updated #2247 to match the C API.

We should make sure there is fuzz testing against C intrinsics as mentioned in #2221 (comment).

That seems reasonable. I can start on a branch for it now, but I'd ideally like to wait until #2247 and #2254 are merged so as to not be stuck in an endless cycle of rebases.

Error: The feature shortcut is not enabled in this repository.

I tried the same thing 😂