| Message ID | 20201216174146.10446-1-chang.seok.bae@intel.com |
|---|---|
| Headers | show |
| Series | x86: Support Intel Key Locker | expand |
On Thu, Dec 17, 2020 at 11:11 AM Eric Biggers <ebiggers@kernel.org> wrote: > > On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote: > > [1] Intel Architecture Instruction Set Extensions Programming Reference: > > https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-$ https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf > > [2] Intel Key Locker Specification: > > https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-speci$ https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-specification.pdf
> On Dec 18, 2020, at 04:10, Eric Biggers <ebiggers@kernel.org> wrote: > > On Wed, Dec 16, 2020 at 09:41:38AM -0800, Chang S. Bae wrote: >> [1] Intel Architecture Instruction Set Extensions Programming Reference: >> https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-$ >> [2] Intel Key Locker Specification: >> https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-speci$ > > Both of these links are broken. Sorry, my bad -- my editor ate some strings with copy & paste. Dan has provided the links already, thank you. Chang
On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae <chang.seok.bae@intel.com> 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
> On Dec 20, 2020, at 03:59, Andy Lutomirski <luto@kernel.org> wrote: > > On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae <chang.seok.bae@intel.com> 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? I saw it took 110-130 cycles without the hardware rand. But about 25K cycles with it. It is not executable in userspace. > 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. It is assumed that all the CPUs need to have the same key loaded (at boot-time). I thought the software wrapping key is simple to be loaded. With hardware rand, the key value is unknown to software. The key needs the backup mechanism to copy it to every CPU. > If we use a random key, we need to figure out what to do about S5 and > hibernation. It was considered to restore the key from the backup before resuming any suspended thread. That’s the case for S3 and S4 (hibernation) sleep states. The system restarts with S5. > No matter what we do, we're going to have some issues with CRIU. It looks like the case as long as the wrapping key is not fully restored by it. > 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? This is one of the options we considered too. > 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. The current use of the wrapping key is only for an AES key. Maybe the feature will be extended in the future. Thanks, Chang
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. The series has three parts: * PATCH1-6: Implement the internal key management * PATCH7: Add AES implementation in Crypto library * PATCH8: Provide the hardware randomization option for the internal key This RFC series has been reviewed by Dan Williams, with an open question of whether to use hardware backup/restore, or to synchronize reinitialize the internal key over suspend / resume to avoid the implications of key restore failures. [1] Intel Architecture Instruction Set Extensions Programming Reference: https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-$ [2] Intel Key Locker Specification: https://software.intel.com/content/dam/develop/external/us/en/documents/343965-intel-key-locker-speci$ Chang S. Bae (8): x86/cpufeature: Enumerate Key Locker feature x86/cpu: Load Key Locker internal key at boot-time x86/msr-index: Add MSRs for Key Locker internal key x86/power: Restore Key Locker internal key from the ACPI S3/4 sleep states x86/cpu: Add a config option and a chicken bit for Key Locker selftests/x86: Test Key Locker internal key maintenance crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions x86/cpu: Support the hardware randomization option for Key Locker internal key .../admin-guide/kernel-parameters.txt | 2 + arch/x86/Kconfig | 14 + arch/x86/crypto/Makefile | 3 + arch/x86/crypto/aeskl-intel_asm.S | 881 ++++++++++++++++++ arch/x86/crypto/aeskl-intel_glue.c | 697 ++++++++++++++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/inst.h | 201 ++++ arch/x86/include/asm/keylocker.h | 41 + arch/x86/include/asm/msr-index.h | 6 + arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 66 +- arch/x86/kernel/cpu/cpuid-deps.c | 1 + arch/x86/kernel/keylocker.c | 147 +++ arch/x86/kernel/smpboot.c | 2 + arch/x86/lib/x86-opcode-map.txt | 2 +- arch/x86/power/cpu.c | 34 + crypto/Kconfig | 28 + drivers/char/random.c | 6 + include/linux/random.h | 2 + tools/arch/x86/lib/x86-opcode-map.txt | 2 +- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/keylocker.c | 177 ++++ 24 files changed, 2321 insertions(+), 5 deletions(-) create mode 100644 arch/x86/crypto/aeskl-intel_asm.S create mode 100644 arch/x86/crypto/aeskl-intel_glue.c create mode 100644 arch/x86/include/asm/keylocker.h create mode 100644 arch/x86/kernel/keylocker.c create mode 100644 tools/testing/selftests/x86/keylocker.c