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
