Re: [RFC PATCH 0/8] x86: Support Intel Key Locker

[Andy Lutomirski]

On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae <chang.seok.bae@xxxxxxxxx> 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.

I think some fundamental issues need to be worked out before we can
enable key locker upstream at all.

First, how fast is LOADIWKEY?  Does it depend on the mode?  Is it
credible to context switch the wrapping key?

First, on bare metal, we need to decide whether to use a wrapping key
or a software-provided wrapping key.  Both choices have pros and cons,
and it's not clear to me whether Linux should have a boot-time
parameter, a runtime control, a fixed value, or something else.  If we
use a random key, we need to figure out what to do about S5 and
hibernation.  No matter what we do, we're going to have some issues
with CRIU.

We also need to understand the virtualization situation.  What do we
expect hypervisors to do with Key Locker?  The only obviously
performant way I can see for VMMs to support migration is to use the
same wrapping key fleetwide.  (This is also the only way I can see for
VMMs to manage the wrapping key in a way that a side channel can't
extract it from hypervisor memory.)  But VMMs can't do this without
some degree of cooperation from the guest.  Perhaps we should disable
KL if CPUID.HYPERVISOR is set for now?

It's a shame that the spec seems to have some holes in the key
management mechanisms.  It would be very nice if there was a way to
load IWKey from an SGX enclave, and it would also be nice if there was
a way to load an IWKey that is wrapped by a different key.  Also, for
non-random IWKey values, there doesn't seem to be a way for software
(in an enclave or otherwise) to confirm that it's wrapping an AES key
against a particular wrapping key, which seems to severely limit the
ability to safely provision a new wrapped key at runtime.

--Andy