On May 15, 2021, at 11:01, Andy Lutomirski [off-list ref] wrote:

On 5/14/21 1:14 PM, Chang S. Bae wrote:

quoted

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@intel.com/ (local)
[2] https://lore.kernel.org/kvm/1611565580-47718-1-git-send-email-robert.hu@linux.intel.com/ (local)