On May 15, 2021, at 11:01, Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On 5/14/21 1:14 PM, Chang S. Bae wrote: >> Key Locker [1][2] is a new security feature available in new Intel CPUs to >> protect data encryption keys for the Advanced Encryption Standard >> algorithm. The protection limits the amount of time an AES key is exposed >> in memory by sealing a key and referencing it with new AES instructions. >> >> The new AES instruction set is a successor of Intel's AES-NI (AES New >> Instruction). Users may switch to the Key Locker version from crypto >> libraries. This series includes a new AES implementation for the Crypto >> API, which was validated through the crypto unit tests. The performance in >> the test cases was measured and found comparable to the AES-NI version. >> >> Key Locker introduces a (CPU-)internal key to encode AES keys. The kernel >> needs to load it and ensure it unchanged as long as CPUs are operational. > > I have high-level questions: > > What is the expected use case? The wrapping key here is only used for new AES instructions. I’m aware of their potential use cases for encrypting file system or disks. > My personal hypothesis, based on various > public Intel slides, is that the actual intended use case was internal > to the ME, and that KL was ported to end-user CPUs more or less > verbatim. No, this is a separate one. The feature has nothing to do with the firmware except that in some situations it merely helps to back up the key in its state. > I certainly understand how KL is valuable in a context where > a verified boot process installs some KL keys that are not subsequently > accessible outside the KL ISA, but Linux does not really work like this. Do you mind elaborating on the concern? I try to understand any issue with PATCH3 [1], specifically. > I'm wondering what people will use it for. Mentioned above. > On a related note, does Intel plan to extend KL with ways to securely > load keys? (E.g. the ability to, in effect, LOADIWKEY from inside an > enclave? Key wrapping/unwrapping operations?) In other words, is > should we look at KL the way we look at MKTME, i.e. the foundation of > something neat but not necessarily very useful as is, or should we > expect that KL is in its more or less final form? All I have is pretty much in the spec. So, I think the latter is the case. I don’t see anything about that LOADIWKEY inside an enclave in the spec. (A relevant section is A.6.1 Key Locker Usage with TEE.) > What is the expected interaction between a KL-using VM guest and the > host VMM? Will there be performance impacts (to context switching, for > example) if a guest enables KL, even if the guest does not subsequently > do anything with it? Should Linux actually enable KL if it detects that > it's a VM guest? Should Linux have use a specific keying method as a guest? First of all, there is an RFC series for KVM [2]. Each CPU has one internal key state so it needs to reload it between guest and host if both are enabled. The proposed approach enables it exclusively; expose it to guests only when disabled in a host. Then, I guess a guest may enable it. Thanks, Chang [1] https://lore.kernel.org/lkml/20210514201508.27967-4-chang.seok.bae@xxxxxxxxx/ [2] https://lore.kernel.org/kvm/1611565580-47718-1-git-send-email-robert.hu@xxxxxxxxxxxxxxx/
