Show Your Support: This site is primarily supported by advertisements. Ads are what have allowed this site to be maintained on a daily basis for the past 18+ years. We do our best to ensure only clean, relevant ads are shown, when any nasty ads are detected, we work to remove them ASAP. If you would like to view the site without ads while still supporting our work, please consider our ad-free Phoronix Premium.
Intel Key Locker Support Added To LLVM - Confirms Presence With Tiger Lake
Intel Key Locker is a means of encrypting/decrypting data with an AES key without having access to the raw key. Key Locker relies on converting AES keys into handles that are then used in place of the actual key, until revoked by the system. The goal with this feature is for preventing any rogue attackers from obtaining the actual AES keys on the system.
Key Locker brings a number of new CPU instruction set extensions for operation. AESENC128KL, AESENCWIDE128KL, AESDEC128KL, AESDECWIDE128KL, AESENC256KL, AESENCWIDE256KL, AESDEC256KL, and AESDECWIDE256KL instructions are for Key Locker to encrypt/decrypt with various key sizes and block configurations.
Merged this morning is the work done by Intel's compiler engineers on supporting these new Key Locker instructions within the LLVM compiler infrastructure.
The patch does reveal that Key Locker is actually supported by Intel Tiger Lake with both Key Locker (KL) and Wide Key Locker (WKL) This is separate from Tiger Lake also supporting CET as another security feature, but Intel seemingly hasn't talked up Key Locker much in the context of Tiger Lake. It's also surprising that they are only adding this GCC and LLVM toolchain support around Key Locker now considering Tiger Lake laptops are beginning to appear where as usually Intel has their instruction set extensions wired up into the open-source compilers months if not years sometimes ahead of product releases... Control-Flow Enforcement Technology with Tigerlake meanwhile saw Linux patches back in 2017 and continued upbringing since for that security feature. The untimely Key Locker compiler support may well delay the adoption of KL/WKL usage by developers, unfortunately, but we'll see how this feature plays out over the months/years ahead.