Stabilize keylocker

[sayantn]

This PR stabilizes the feature flag keylocker_x86 (tracking issue #134813).

Public API

The 2 x86 target features kl and widekl, and the associated intrinsics in stdarch.

These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 11 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.

Also, these were added way back in LLVM12, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!

Associated PRs

• Add kl and widekl target features, and the feature gate #134814
• Add keylocker (kl and widekl) intrinsics and runtime feature detection stdarch#1706
• Update stdarch #136831 (stdarch submodule update)
• Stabilize keylocker intrinsics and runtime detection stdarch#1795 (stabilizing the runtime detection and intrinsics)

As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.

cc @rust-lang/lang
cc @rust-lang/libs-api for the intrinsics and runtime detection

I don't think anyone else worked on this feature, so no one else to ping, maybe cc @Amanieu. I will send the reference pr soon.

Do not merge now, contains a temporary fix to make the tests pass until the stdarch stabilization PR is merged.

[rustbot]

⚠️ Warning ⚠️

• Some commits in this PR modify submodules.

[traviscross]

Stabilizing target features are somewhat minimal as far as stabilizations go, but still, this is going to need something more in the way of a stabilization report in the description of this PR. We need some narrative about what we're stabilizing here and a review of the evidence about why it's OK for us to stabilize this now. Have a look at our new template for this in rust-lang/rustc-dev-guide#2219.

Please think too about who else in the Project has worked on this or related things and who might therefore be interested in this, and please ping those people here.

This will also need a PR to the Reference documenting the change, and that should be linked from the stabilization report as well.

@rustbot labels +S-waiting-on-documentation

Please renominate when the stabilization report is available.

[sayantn]

@rustbot label I-lang-nominated
cc @traviscross

[traviscross]

cc @oli-obk @RalfJung @workingjubilee

[traviscross]

Just leaving a note so we remember to pull out this "do not merge" commit.

[traviscross]

Suggested change

	(accepted, keylocker_x86, "1.86.0", Some(134813)),
	(accepted, keylocker_x86, "CURRENT_RUSTC_VERSION", Some(134813)),

[sayantn]

Ah, forgot changing it, will update

[traviscross]

@sayantn, are these kl and widekl names semi-standard elsewhere, or how did we pick these? What does the Linux kernel show in /proc/cpuinfo?

[sayantn]

These names are used by both gcc and llvm, but Intel uses the names KEYLOCKER and KEYLOCKER_WIDE, so we can do some bikeshedding here, although I would say following the convention of the C compilers would be better (this has been the common convention in Rust for quite some time, another example off the top of my head will be avx512ifma, intel uses AVX512_IFMA52)

[RalfJung]

They don't have any nontrivial interaction with the ABI

Beyond ABI, is there any possibility for trouble when mixing code built with and without these target features?

[sayantn]

They don't have any nontrivial interaction with the ABI

Beyond ABI, is there any possibility for trouble when mixing code built with and without these target features?

The only job of these target features is enabling the use of those 11 intrinsics, or equivalently, 11 instructions. They don't affect normal codegen in any way, so I don't think it will be problematic mixing code built with and without them.

The only nontrivial thing I can think of about these is that the encodekey instructions don't have any output registers, they just clobber xmm{0..=7} (or xmm{0..=5} for encodekey128). But llvm knows about this, and generates appropriate instructions for it, so it should have no problems.

[traviscross]

What does the Linux kernel show in /proc/cpuinfo?

It looks like the kernel uses aes_keylocker and aes_keylocker_wide. From here:

# Leaf 19H
# Intel Key Locker enumeration

      0x19,         0,  eax,       0,    kl_cpl0_only           , CPL0-only key Locker restriction supported
      0x19,         0,  eax,       1,    kl_no_encrypt          , No-encrypt key locker restriction supported
      0x19,         0,  eax,       2,    kl_no_decrypt          , No-decrypt key locker restriction supported
      0x19,         0,  ebx,       0,    aes_keylocker          , AES key locker instructions supported
      0x19,         0,  ebx,       2,    aes_keylocker_wide     , AES wide key locker instructions supported
      0x19,         0,  ebx,       4,    kl_msr_iwkey           , Key locker MSRs and IWKEY backups supported
      0x19,         0,  ecx,       0,    loadiwkey_no_backup    , LOADIWKEY NoBackup parameter supported
      0x19,         0,  ecx,       1,    iwkey_rand             , IWKEY randomization (KeySource encoding 1) supported

This follows the nomenclature from a project for exhaustively documenting and tracking this CPUID data:

https://x86-cpuid.org/

In comparing it with the features that we support, most but not all of these match.

Here's the LLVM list:

https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td

These names are used by both gcc and llvm, but Intel uses the names KEYLOCKER and KEYLOCKER_WIDE, so we can do some bikeshedding here, although I would say following the convention of the C compilers would be better

Yes, I suppose I'm happy enough to follow LLVM here.

[traviscross]

This sounds OK to me, so let's propose to do it.

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.