Intel Posts New Iteration Of Key Locker Support For Linux

Written by Michael Larabel in Intel on 24 November 2021 at 03:46 PM EST. 3 Comments
With Intel Tiger Lake mobile processors introduced last year there has been good open-source support going back to launch, but a few of the more niche features have seen slower than normal handling for getting the features supported by the upstream Linux kernel. The latest patch series being revived now is for Intel Key Locker support.

Just a few days ago I talked about Intel pursuing a new Indirect Branch Tracking (IBT) patch series as part of their Control-Flow Enforcement Technology (CET) introduced on Tiger Lake. After months of silence, another Tiger Lake feature is seeing revised kernel patches emerge this week and that is for Key Locker.

Intel Key Locker allows encrypting/decrypting data without the raw AES key but instead making use of a key handle that is in place until revoked by the system. The key when loaded is effectively sealed and then accessed by new Intel Key Locker instructions (AESENC128KL, AESENCWIDE128KL, AESDEC128KL, AESDECWIDE128KL, AESENC256KL, AESENCWIDE256KL, AESDEC256KL, and AESDECWIDE256KL) to reference the handle to a particular AES key. Intel Key Locker aims to protect AES keys by keeping the raw keys exposed for a minimal amount of time to reduce the chances they are compromised by rogue attackers.

Intel Key Locker

Since late 2020 there was open-source enablement work for Key Locker on Linux. There was also the LLVM and GCC compiler side work that was promptly merged for dealing with the new instructions. But the Key Locker kernel patches were slow to spark interest among kernel developers and evidently not much of a priority for Intel engineers.

Today marks the third iteration of the Intel Key Locker patches being posted for the Linux kernel. With this new patch series they acknowledge Key Locker usage can result in ~5x slower performance than raw AES-NI usage, but they are aiming Key Locker for dealing with disk encryption. In disk encryption scenarios, the disk throughput performance is more likely to be a bottleneck than Key Locker itself.

Besides tailoring the patches now for a disk encryption use-case, the new patches have other documentation improvements, avoids publishing the "keylocker" indicator to user-space via /proc/cpuinfo, limiting the usage to bare metal only (no VMs), renaming some of the MSRs, and other updates. This is also the first version not carrying the "request for comments" (RFC) designation.

The patch series implementing this new "aes-kl" driver is around 2.5k lines of new code.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week