Intel Posts New Iteration Of Key Locker Support For Linux

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.