Re: [RFC PATCH v2 00/11] x86: Support Intel Key Locker

[Bae, Chang Seok]

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/