* [PATCH v5 01/12] Documentation/x86: Document Key Locker [not found] <20220112211258.21115-1-chang.seok.bae@intel.com> @ 2022-01-12 21:12 ` Chang S. Bae 2023-06-05 10:52 ` Bagas Sanjaya 2022-01-12 21:12 ` [PATCH v5 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230410225936.8940-1-chang.seok.bae@intel.com> 2 siblings, 1 reply; 14+ messages in thread From: Chang S. Bae @ 2022-01-12 21:12 UTC (permalink / raw) To: linux-crypto, dm-devel, herbert, ebiggers, ardb, x86, luto, tglx, bp, dave.hansen, mingo Cc: linux-kernel, dan.j.williams, charishma1.gairuboyina, kumar.n.dwarakanath, ravi.v.shankar, chang.seok.bae, linux-doc Document the overview of the feature along with relevant consideration when provisioning dm-crypt volumes with AES-KL instead of AES-NI. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from RFC v2: * Add as a new patch. --- Documentation/x86/index.rst | 1 + Documentation/x86/keylocker.rst | 98 +++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 Documentation/x86/keylocker.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..bbea47ea10f6 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -38,3 +38,4 @@ x86-specific Documentation features elf_auxvec xstate + keylocker diff --git a/Documentation/x86/keylocker.rst b/Documentation/x86/keylocker.rst new file mode 100644 index 000000000000..e65d936ef199 --- /dev/null +++ b/Documentation/x86/keylocker.rst @@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +x86 Key Locker +============== + +Introduction +============ + +Key Locker is a CPU feature feature to reduce key exfiltration +opportunities while maintaining a programming interface similar to AES-NI. +It converts the AES key into an encoded form, called the 'key handle'. The +key handle is a wrapped version of the clear-text key where the wrapping +key has limited exposure. Once converted, all subsequent data encryption +using new AES instructions (AES-KL) uses this key handle, reducing the +exposure of private key material in memory. + +Internal Wrapping Key (IWKey) +============================= + +The CPU-internal wrapping key is an entity in a software-invisible CPU +state. On every system boot, a new key is loaded. So the key handle that +was encoded by the old wrapping key is no longer usable on system shutdown +or reboot. + +And the key may be lost on the following exceptional situation upon wakeup: + +IWKey Restore Failure +--------------------- + +The CPU state is volatile with the ACPI S3/4 sleep states. When the system +supports those states, the key has to be backed up so that it is restored +on wake up. The kernel saves the key in non-volatile media. + +The event of an IWKey restore failure upon resume from suspend, all +established key handles become invalid. In flight dm-crypt operations +receive error results from pending operations. In the likely scenario that +dm-crypt is hosting the root filesystem the recovery is identical to if a +storage controller failed to resume from suspend, reboot. If the volume +impacted by an IWKey restore failure is a data-volume then it is possible +that I/O errors on that volume do not bring down the rest of the system. +However, a reboot is still required because the kernel will have +soft-disabled Key Locker. Upon the failure, the crypto library code will +return -ENODEV on every AES-KL function call. The Key Locker implementation +only loads a new IWKey at initial boot, not any time after like resume from +suspend. + +Use Case and Non-use Cases +========================== + +Bare metal disk encryption is the only intended use case. + +Userspace usage is not supported because there is no ABI provided to +communicate and coordinate wrapping-key restore failure to userspace. For +now, key restore failures are only coordinated with kernel users. But the +kernel can not prevent userspace from using the feature's AES instructions +('AES-KL') when the feature has been enabled. So, the lack of userspace +support is only documented, not actively enforced. + +Key Locker is not expected to be advertised to guest VMs and the kernel +implementation ignores it even if the VMM enumerates the capability. The +expectation is that a guest VM wants private IWKey state, but the +architecture does not provide that. An emulation of that capability, by +caching per VM IWKeys in memory, defeats the purpose of Key Locker. The +backup / restore facility is also not performant enough to be suitable for +guest VM context switches. + +AES Instruction Set +=================== + +The feature accompanies a new AES instruction set. This instruction set is +analogous to AES-NI. A set of AES-NI instructions can be mapped to an +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds +of transformation, which is equivalent to nine times AESENC and one +AESENCLAST in AES-NI. + +But they have some notable differences: + +* AES-KL provides a secure data transformation using an encrypted key. + +* If an invalid key handle is provided, e.g. a corrupted one or a handle + restriction failure, the instruction fails with setting RFLAGS.ZF. The + crypto library implementation includes the flag check to return an error + code. Note that the flag is also set when the internal wrapping key is + changed because of missing backup. + +* AES-KL implements support for 128-bit and 256-bit keys, but there is no + AES-KL instruction to process an 192-bit key. But there is no AES-KL + instruction to process a 192-bit key. The AES-KL cipher implementation + logs a warning message with a 192-bit key and then falls back to AES-NI. + So, this 192-bit key-size limitation is only documented, not enforced. It + means the key will remain in clear-text in memory. This is to meet Linux + crypto-cipher expectation that each implementation must support all the + AES-compliant key sizes. + +* Some AES-KL hardware implementation may have noticeable performance + overhead when compared with AES-NI instructions. + -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v5 01/12] Documentation/x86: Document Key Locker 2022-01-12 21:12 ` [PATCH v5 01/12] Documentation/x86: Document Key Locker Chang S. Bae @ 2023-06-05 10:52 ` Bagas Sanjaya 0 siblings, 0 replies; 14+ messages in thread From: Bagas Sanjaya @ 2023-06-05 10:52 UTC (permalink / raw) To: Chang S. Bae, linux-crypto, dm-devel, herbert, ebiggers, ardb, x86, luto, tglx, bp, dave.hansen, mingo Cc: linux-kernel, dan.j.williams, charishma1.gairuboyina, kumar.n.dwarakanath, ravi.v.shankar, linux-doc On 1/13/22 04:12, Chang S. Bae wrote: > +============== > +x86 Key Locker > +============== > + > +Introduction > +============ > + > +Key Locker is a CPU feature feature to reduce key exfiltration > +opportunities while maintaining a programming interface similar to AES-NI. > +It converts the AES key into an encoded form, called the 'key handle'. The > +key handle is a wrapped version of the clear-text key where the wrapping > +key has limited exposure. Once converted, all subsequent data encryption > +using new AES instructions (AES-KL) uses this key handle, reducing the > +exposure of private key material in memory. > + > +Internal Wrapping Key (IWKey) > +============================= > + > +The CPU-internal wrapping key is an entity in a software-invisible CPU > +state. On every system boot, a new key is loaded. So the key handle that > +was encoded by the old wrapping key is no longer usable on system shutdown > +or reboot. > + > +And the key may be lost on the following exceptional situation upon wakeup: > + > +IWKey Restore Failure > +--------------------- > + > +The CPU state is volatile with the ACPI S3/4 sleep states. When the system > +supports those states, the key has to be backed up so that it is restored > +on wake up. The kernel saves the key in non-volatile media. > + > +The event of an IWKey restore failure upon resume from suspend, all > +established key handles become invalid. In flight dm-crypt operations > +receive error results from pending operations. In the likely scenario that > +dm-crypt is hosting the root filesystem the recovery is identical to if a > +storage controller failed to resume from suspend, reboot. If the volume "suspend and reboot"? > +impacted by an IWKey restore failure is a data-volume then it is possible > +that I/O errors on that volume do not bring down the rest of the system. > +However, a reboot is still required because the kernel will have > +soft-disabled Key Locker. Upon the failure, the crypto library code will > +return -ENODEV on every AES-KL function call. The Key Locker implementation > +only loads a new IWKey at initial boot, not any time after like resume from > +suspend. > + > +Use Case and Non-use Cases > +========================== > + > +Bare metal disk encryption is the only intended use case. > + > +Userspace usage is not supported because there is no ABI provided to > +communicate and coordinate wrapping-key restore failure to userspace. For > +now, key restore failures are only coordinated with kernel users. But the > +kernel can not prevent userspace from using the feature's AES instructions > +('AES-KL') when the feature has been enabled. So, the lack of userspace > +support is only documented, not actively enforced. > + > +Key Locker is not expected to be advertised to guest VMs and the kernel > +implementation ignores it even if the VMM enumerates the capability. The > +expectation is that a guest VM wants private IWKey state, but the > +architecture does not provide that. An emulation of that capability, by > +caching per VM IWKeys in memory, defeats the purpose of Key Locker. The > +backup / restore facility is also not performant enough to be suitable for > +guest VM context switches. > + > +AES Instruction Set > +=================== > + > +The feature accompanies a new AES instruction set. This instruction set is > +analogous to AES-NI. A set of AES-NI instructions can be mapped to an > +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds > +of transformation, which is equivalent to nine times AESENC and one > +AESENCLAST in AES-NI. > + > +But they have some notable differences: > + > +* AES-KL provides a secure data transformation using an encrypted key. > + > +* If an invalid key handle is provided, e.g. a corrupted one or a handle > + restriction failure, the instruction fails with setting RFLAGS.ZF. The > + crypto library implementation includes the flag check to return an error > + code. Note that the flag is also set when the internal wrapping key is > + changed because of missing backup. > + > +* AES-KL implements support for 128-bit and 256-bit keys, but there is no > + AES-KL instruction to process an 192-bit key. But there is no AES-KL > + instruction to process a 192-bit key. The AES-KL cipher implementation > + logs a warning message with a 192-bit key and then falls back to AES-NI. > + So, this 192-bit key-size limitation is only documented, not enforced. It > + means the key will remain in clear-text in memory. This is to meet Linux > + crypto-cipher expectation that each implementation must support all the > + AES-compliant key sizes. > + > +* Some AES-KL hardware implementation may have noticeable performance > + overhead when compared with AES-NI instructions. > + The rest is LGTM. -- An old man doll... just what I always wanted! - Clara ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v5 09/12] x86/cpu: Add a configuration and command line option for Key Locker [not found] <20220112211258.21115-1-chang.seok.bae@intel.com> 2022-01-12 21:12 ` [PATCH v5 01/12] Documentation/x86: Document Key Locker Chang S. Bae @ 2022-01-12 21:12 ` Chang S. Bae [not found] ` <20230410225936.8940-1-chang.seok.bae@intel.com> 2 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2022-01-12 21:12 UTC (permalink / raw) To: linux-crypto, dm-devel, herbert, ebiggers, ardb, x86, luto, tglx, bp, dave.hansen, mingo Cc: linux-kernel, dan.j.williams, charishma1.gairuboyina, kumar.n.dwarakanath, ravi.v.shankar, chang.seok.bae, linux-doc Add CONFIG_X86_KEYLOCKER to gate whether Key Locker is initialized at boot. The option is selected by the Key Locker cipher module CRYPTO_AES_KL (to be added in a later patch). Add a new command line option "nokeylocker" to optionally override the default CONFIG_X86_KEYLOCKER=y behavior. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from RFC v2: * Make the option selected by CRYPTO_AES_KL. (Dan Williams) * Massage the changelog and the config option description. --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/Kconfig | 3 +++ arch/x86/kernel/cpu/common.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 2fba82431efb..30ed18fbdea3 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3405,6 +3405,8 @@ nohugevmalloc [PPC] Disable kernel huge vmalloc mappings. + nokeylocker [X86] Disable Key Locker hardware feature. + nosmt [KNL,S390] Disable symmetric multithreading (SMT). Equivalent to smt=1. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5c2ccb85f2ef..191bd4a941eb 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1864,6 +1864,9 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS If unsure, say y. +config X86_KEYLOCKER + bool + choice prompt "TSX enable mode" depends on CPU_SUP_INTEL diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 23b4aa437c1e..db1fc9ff0fe3 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -364,6 +364,22 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c) /* These bits should not change their value after CPU init is finished. */ static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | X86_CR4_FSGSBASE; + +static __init int x86_nokeylocker_setup(char *arg) +{ + /* Expect an exact match without trailing characters. */ + if (strlen(arg)) + return 0; + + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) + return 1; + + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); + pr_info("x86/keylocker: Disabled by kernel command line.\n"); + return 1; +} +__setup("nokeylocker", x86_nokeylocker_setup); + static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <20230410225936.8940-1-chang.seok.bae@intel.com>]
* [PATCH v6 01/12] Documentation/x86: Document Key Locker [not found] ` <20230410225936.8940-1-chang.seok.bae@intel.com> @ 2023-04-10 22:59 ` Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230524165717.14062-1-chang.seok.bae@intel.com> 2 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-04-10 22:59 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, chang.seok.bae, Ingo Molnar, Borislav Petkov, H. Peter Anvin, Jonathan Corbet, linux-doc Document the overview of the feature along with relevant consideration when provisioning dm-crypt volumes with AES-KL instead of AES-NI. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from v5: * Fix a typo: 'feature feature' -> 'feature' Changes from RFC v2: * Add as a new patch. The preview is available here: https://htmlpreview.github.io/?https://github.com/intel-staging/keylocker/kdoc/x86/keylocker.html --- Documentation/x86/index.rst | 1 + Documentation/x86/keylocker.rst | 98 +++++++++++++++++++++++++++++++++ 2 files changed, 99 insertions(+) create mode 100644 Documentation/x86/keylocker.rst diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 8ac64d7de4dc..669c239c009f 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -43,3 +43,4 @@ x86-specific Documentation features elf_auxvec xstate + keylocker diff --git a/Documentation/x86/keylocker.rst b/Documentation/x86/keylocker.rst new file mode 100644 index 000000000000..3b405fade7d8 --- /dev/null +++ b/Documentation/x86/keylocker.rst @@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +x86 Key Locker +============== + +Introduction +============ + +Key Locker is a CPU feature to reduce key exfiltration opportunities +while maintaining a programming interface similar to AES-NI. It +converts the AES key into an encoded form, called the 'key handle'. +The key handle is a wrapped version of the clear-text key where the +wrapping key has limited exposure. Once converted, all subsequent data +encryption using new AES instructions (AES-KL) uses this key handle, +reducing the exposure of private key material in memory. + +Internal Wrapping Key (IWKey) +============================= + +The CPU-internal wrapping key is an entity in a software-invisible CPU +state. On every system boot, a new key is loaded. So the key handle that +was encoded by the old wrapping key is no longer usable on system shutdown +or reboot. + +And the key may be lost on the following exceptional situation upon wakeup: + +IWKey Restore Failure +--------------------- + +The CPU state is volatile with the ACPI S3/4 sleep states. When the system +supports those states, the key has to be backed up so that it is restored +on wake up. The kernel saves the key in non-volatile media. + +The event of an IWKey restore failure upon resume from suspend, all +established key handles become invalid. In flight dm-crypt operations +receive error results from pending operations. In the likely scenario that +dm-crypt is hosting the root filesystem the recovery is identical to if a +storage controller failed to resume from suspend, reboot. If the volume +impacted by an IWKey restore failure is a data-volume then it is possible +that I/O errors on that volume do not bring down the rest of the system. +However, a reboot is still required because the kernel will have +soft-disabled Key Locker. Upon the failure, the crypto library code will +return -ENODEV on every AES-KL function call. The Key Locker implementation +only loads a new IWKey at initial boot, not any time after like resume from +suspend. + +Use Case and Non-use Cases +========================== + +Bare metal disk encryption is the only intended use case. + +Userspace usage is not supported because there is no ABI provided to +communicate and coordinate wrapping-key restore failure to userspace. For +now, key restore failures are only coordinated with kernel users. But the +kernel can not prevent userspace from using the feature's AES instructions +('AES-KL') when the feature has been enabled. So, the lack of userspace +support is only documented, not actively enforced. + +Key Locker is not expected to be advertised to guest VMs and the kernel +implementation ignores it even if the VMM enumerates the capability. The +expectation is that a guest VM wants private IWKey state, but the +architecture does not provide that. An emulation of that capability, by +caching per VM IWKeys in memory, defeats the purpose of Key Locker. The +backup / restore facility is also not performant enough to be suitable for +guest VM context switches. + +AES Instruction Set +=================== + +The feature accompanies a new AES instruction set. This instruction set is +analogous to AES-NI. A set of AES-NI instructions can be mapped to an +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds +of transformation, which is equivalent to nine times AESENC and one +AESENCLAST in AES-NI. + +But they have some notable differences: + +* AES-KL provides a secure data transformation using an encrypted key. + +* If an invalid key handle is provided, e.g. a corrupted one or a handle + restriction failure, the instruction fails with setting RFLAGS.ZF. The + crypto library implementation includes the flag check to return an error + code. Note that the flag is also set when the internal wrapping key is + changed because of missing backup. + +* AES-KL implements support for 128-bit and 256-bit keys, but there is no + AES-KL instruction to process an 192-bit key. But there is no AES-KL + instruction to process a 192-bit key. The AES-KL cipher implementation + logs a warning message with a 192-bit key and then falls back to AES-NI. + So, this 192-bit key-size limitation is only documented, not enforced. It + means the key will remain in clear-text in memory. This is to meet Linux + crypto-cipher expectation that each implementation must support all the + AES-compliant key sizes. + +* Some AES-KL hardware implementation may have noticeable performance + overhead when compared with AES-NI instructions. + -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v6 09/12] x86/cpu: Add a configuration and command line option for Key Locker [not found] ` <20230410225936.8940-1-chang.seok.bae@intel.com> 2023-04-10 22:59 ` [PATCH v6 01/12] Documentation/x86: Document " Chang S. Bae @ 2023-04-10 22:59 ` Chang S. Bae [not found] ` <20230524165717.14062-1-chang.seok.bae@intel.com> 2 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-04-10 22:59 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, chang.seok.bae, Jonathan Corbet, Ingo Molnar, Borislav Petkov, H. Peter Anvin, linux-doc Add CONFIG_X86_KEYLOCKER to gate whether Key Locker is initialized at boot. The option is selected by the Key Locker cipher module CRYPTO_AES_KL (to be added in a later patch). Add a new command line option "nokeylocker" to optionally override the default CONFIG_X86_KEYLOCKER=y behavior. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from RFC v2: * Make the option selected by CRYPTO_AES_KL. (Dan Williams) * Massage the changelog and the config option description. --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/Kconfig | 3 +++ arch/x86/kernel/cpu/common.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 5f2ec4b0f927..6534e6217e56 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3655,6 +3655,8 @@ nohugevmalloc [KNL,X86,PPC,ARM64] Disable kernel huge vmalloc mappings. + nokeylocker [X86] Disable Key Locker hardware feature. + nosmt [KNL,S390] Disable symmetric multithreading (SMT). Equivalent to smt=1. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index c94297369448..91f2063ab283 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1894,6 +1894,9 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS If unsure, say y. +config X86_KEYLOCKER + bool + choice prompt "TSX enable mode" depends on CPU_SUP_INTEL diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index a1edd5997e0a..c5550b8f030d 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -419,6 +419,22 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c) static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | X86_CR4_FSGSBASE | X86_CR4_CET; + +static __init int x86_nokeylocker_setup(char *arg) +{ + /* Expect an exact match without trailing characters. */ + if (strlen(arg)) + return 0; + + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) + return 1; + + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); + pr_info("x86/keylocker: Disabled by kernel command line.\n"); + return 1; +} +__setup("nokeylocker", x86_nokeylocker_setup); + static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <20230524165717.14062-1-chang.seok.bae@intel.com>]
* [PATCH v7 01/12] Documentation/x86: Document Key Locker [not found] ` <20230524165717.14062-1-chang.seok.bae@intel.com> @ 2023-05-24 16:57 ` Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230603152227.12335-1-chang.seok.bae@intel.com> 2 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-05-24 16:57 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, chang.seok.bae, Ingo Molnar, H. Peter Anvin, Jonathan Corbet, linux-doc Document the overview of the feature along with relevant consideration when provisioning dm-crypt volumes with AES-KL instead of AES-NI. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from v6: * Rebase on the upstream -- commit ff61f0791ce9 ("docs: move x86 documentation into Documentation/arch/"). (Nathan Huckleberry) * Remove a duplicated sentence -- 'But there is no AES-KL instruction to process a 192-bit key.' * Update the text for clarity and readability: - Clarify the error code and exemplify the backup failure - Use 'wrapping key' instead of less readable 'IWKey' Changes from v5: * Fix a typo: 'feature feature' -> 'feature' Changes from RFC v2: * Add as a new patch. The preview is available here: https://htmlpreview.github.io/?https://github.com/intel-staging/keylocker/kdoc/arch/x86/keylocker.html --- Documentation/arch/x86/index.rst | 1 + Documentation/arch/x86/keylocker.rst | 97 ++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+) create mode 100644 Documentation/arch/x86/keylocker.rst diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/index.rst index c73d133fd37c..256359c24669 100644 --- a/Documentation/arch/x86/index.rst +++ b/Documentation/arch/x86/index.rst @@ -42,3 +42,4 @@ x86-specific Documentation features elf_auxvec xstate + keylocker diff --git a/Documentation/arch/x86/keylocker.rst b/Documentation/arch/x86/keylocker.rst new file mode 100644 index 000000000000..5557b8d0659a --- /dev/null +++ b/Documentation/arch/x86/keylocker.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +x86 Key Locker +============== + +Introduction +============ + +Key Locker is a CPU feature to reduce key exfiltration opportunities +while maintaining a programming interface similar to AES-NI. It +converts the AES key into an encoded form, called the 'key handle'. +The key handle is a wrapped version of the clear-text key where the +wrapping key has limited exposure. Once converted, all subsequent data +encryption using new AES instructions (AES-KL) uses this key handle, +reducing the exposure of private key material in memory. + +CPU-internal Wrapping Key +========================= + +The CPU-internal wrapping key is an entity in a software-invisible CPU +state. On every system boot, a new key is loaded. So the key handle that +was encoded by the old wrapping key is no longer usable on system shutdown +or reboot. + +And the key may be lost on the following exceptional situation upon wakeup: + +Wrapping Key Restore Failure +---------------------------- + +The CPU state is volatile with the ACPI S3/4 sleep states. When the system +supports those states, the key has to be backed up so that it is restored +on wake up. The kernel saves the key in non-volatile media. + +The event of a wrapping key restore failure upon resume from suspend, all +established key handles become invalid. In flight dm-crypt operations +receive error results from pending operations. In the likely scenario that +dm-crypt is hosting the root filesystem the recovery is identical to if a +storage controller failed to resume from suspend, reboot. If the volume +impacted by a wrapping key restore failure is a data-volume then it is +possible that I/O errors on that volume do not bring down the rest of the +system. However, a reboot is still required because the kernel will have +soft-disabled Key Locker. Upon the failure, the crypto library code will +return -ENODEV on every AES-KL function call. The Key Locker implementation +only loads a new wrapping key at initial boot, not any time after like +resume from suspend. + +Use Case and Non-use Cases +========================== + +Bare metal disk encryption is the only intended use case. + +Userspace usage is not supported because there is no ABI provided to +communicate and coordinate wrapping-key restore failure to userspace. For +now, key restore failures are only coordinated with kernel users. But the +kernel can not prevent userspace from using the feature's AES instructions +('AES-KL') when the feature has been enabled. So, the lack of userspace +support is only documented, not actively enforced. + +Key Locker is not expected to be advertised to guest VMs and the kernel +implementation ignores it even if the VMM enumerates the capability. The +expectation is that a guest VM wants private wrapping key state, but the +architecture does not provide that. An emulation of that capability, by +caching per-VM wrapping keys in memory, defeats the purpose of Key Locker. +The backup / restore facility is also not performant enough to be suitable +for guest VM context switches. + +AES Instruction Set +=================== + +The feature accompanies a new AES instruction set. This instruction set is +analogous to AES-NI. A set of AES-NI instructions can be mapped to an +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds +of transformation, which is equivalent to nine times AESENC and one +AESENCLAST in AES-NI. + +But they have some notable differences: + +* AES-KL provides a secure data transformation using an encrypted key. + +* If an invalid key handle is provided, e.g. a corrupted one or a handle + restriction failure, the instruction fails with setting RFLAGS.ZF. The + crypto library implementation includes the flag check to return -EINVAL. + Note that this flag is also set if the wrapping key is changed, e.g., + because of the backup error. + +* AES-KL implements support for 128-bit and 256-bit keys, but there is no + AES-KL instruction to process an 192-bit key. The AES-KL cipher + implementation logs a warning message with a 192-bit key and then falls + back to AES-NI. So, this 192-bit key-size limitation is only documented, + not enforced. It means the key will remain in clear-text in memory. This + is to meet Linux crypto-cipher expectation that each implementation must + support all the AES-compliant key sizes. + +* Some AES-KL hardware implementation may have noticeable performance + overhead when compared with AES-NI instructions. + -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v7 09/12] x86/cpu: Add a configuration and command line option for Key Locker [not found] ` <20230524165717.14062-1-chang.seok.bae@intel.com> 2023-05-24 16:57 ` [PATCH v7 01/12] Documentation/x86: Document " Chang S. Bae @ 2023-05-24 16:57 ` Chang S. Bae [not found] ` <20230603152227.12335-1-chang.seok.bae@intel.com> 2 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-05-24 16:57 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, chang.seok.bae, Jonathan Corbet, Ingo Molnar, H. Peter Anvin, linux-doc Add CONFIG_X86_KEYLOCKER to gate whether Key Locker is initialized at boot. The option is selected by the Key Locker cipher module CRYPTO_AES_KL (to be added in a later patch). Add a new command line option "nokeylocker" to optionally override the default CONFIG_X86_KEYLOCKER=y behavior. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from v6: * Rebase on the upstream: commit a894a8a56b57 ("Documentation: kernel-parameters: sort all "no..." parameters") Changes from RFC v2: * Make the option selected by CRYPTO_AES_KL. (Dan Williams) * Massage the changelog and the config option description. --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/Kconfig | 3 +++ arch/x86/kernel/cpu/common.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c1247ec4589a..b42fc53cbcf9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3749,6 +3749,8 @@ kernel and module base offset ASLR (Address Space Layout Randomization). + nokeylocker [X86] Disable Key Locker hardware feature. + no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page fault handling. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a98c5f82be48..f9788b477db1 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1879,6 +1879,9 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS If unsure, say y. +config X86_KEYLOCKER + bool + choice prompt "TSX enable mode" depends on CPU_SUP_INTEL diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 5882ff6e3c6b..718ff1b1d6dd 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -402,6 +402,22 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c) static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | X86_CR4_FSGSBASE | X86_CR4_CET; + +static __init int x86_nokeylocker_setup(char *arg) +{ + /* Expect an exact match without trailing characters. */ + if (strlen(arg)) + return 0; + + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) + return 1; + + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); + pr_info("x86/keylocker: Disabled by kernel command line.\n"); + return 1; +} +__setup("nokeylocker", x86_nokeylocker_setup); + static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <20230603152227.12335-1-chang.seok.bae@intel.com>]
* [PATCH v8 01/12] Documentation/x86: Document Key Locker [not found] ` <20230603152227.12335-1-chang.seok.bae@intel.com> @ 2023-06-03 15:22 ` Chang S. Bae 2023-06-05 10:54 ` Bagas Sanjaya 2023-06-06 2:17 ` Randy Dunlap 2023-06-03 15:22 ` [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae 1 sibling, 2 replies; 14+ messages in thread From: Chang S. Bae @ 2023-06-03 15:22 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, chang.seok.bae, Ingo Molnar, H. Peter Anvin, Jonathan Corbet, linux-doc Document the overview of the feature along with relevant consideration when provisioning dm-crypt volumes with AES-KL instead of AES-NI. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: x86@kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from v6: * Rebase on the upstream -- commit ff61f0791ce9 ("docs: move x86 documentation into Documentation/arch/"). (Nathan Huckleberry) * Remove a duplicated sentence -- 'But there is no AES-KL instruction to process a 192-bit key.' * Update the text for clarity and readability: - Clarify the error code and exemplify the backup failure - Use 'wrapping key' instead of less readable 'IWKey' Changes from v5: * Fix a typo: 'feature feature' -> 'feature' Changes from RFC v2: * Add as a new patch. The preview is available here: https://htmlpreview.github.io/?https://github.com/intel-staging/keylocker/kdoc/arch/x86/keylocker.html --- Documentation/arch/x86/index.rst | 1 + Documentation/arch/x86/keylocker.rst | 97 ++++++++++++++++++++++++++++ 2 files changed, 98 insertions(+) create mode 100644 Documentation/arch/x86/keylocker.rst diff --git a/Documentation/arch/x86/index.rst b/Documentation/arch/x86/index.rst index c73d133fd37c..256359c24669 100644 --- a/Documentation/arch/x86/index.rst +++ b/Documentation/arch/x86/index.rst @@ -42,3 +42,4 @@ x86-specific Documentation features elf_auxvec xstate + keylocker diff --git a/Documentation/arch/x86/keylocker.rst b/Documentation/arch/x86/keylocker.rst new file mode 100644 index 000000000000..5557b8d0659a --- /dev/null +++ b/Documentation/arch/x86/keylocker.rst @@ -0,0 +1,97 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============== +x86 Key Locker +============== + +Introduction +============ + +Key Locker is a CPU feature to reduce key exfiltration opportunities +while maintaining a programming interface similar to AES-NI. It +converts the AES key into an encoded form, called the 'key handle'. +The key handle is a wrapped version of the clear-text key where the +wrapping key has limited exposure. Once converted, all subsequent data +encryption using new AES instructions (AES-KL) uses this key handle, +reducing the exposure of private key material in memory. + +CPU-internal Wrapping Key +========================= + +The CPU-internal wrapping key is an entity in a software-invisible CPU +state. On every system boot, a new key is loaded. So the key handle that +was encoded by the old wrapping key is no longer usable on system shutdown +or reboot. + +And the key may be lost on the following exceptional situation upon wakeup: + +Wrapping Key Restore Failure +---------------------------- + +The CPU state is volatile with the ACPI S3/4 sleep states. When the system +supports those states, the key has to be backed up so that it is restored +on wake up. The kernel saves the key in non-volatile media. + +The event of a wrapping key restore failure upon resume from suspend, all +established key handles become invalid. In flight dm-crypt operations +receive error results from pending operations. In the likely scenario that +dm-crypt is hosting the root filesystem the recovery is identical to if a +storage controller failed to resume from suspend, reboot. If the volume +impacted by a wrapping key restore failure is a data-volume then it is +possible that I/O errors on that volume do not bring down the rest of the +system. However, a reboot is still required because the kernel will have +soft-disabled Key Locker. Upon the failure, the crypto library code will +return -ENODEV on every AES-KL function call. The Key Locker implementation +only loads a new wrapping key at initial boot, not any time after like +resume from suspend. + +Use Case and Non-use Cases +========================== + +Bare metal disk encryption is the only intended use case. + +Userspace usage is not supported because there is no ABI provided to +communicate and coordinate wrapping-key restore failure to userspace. For +now, key restore failures are only coordinated with kernel users. But the +kernel can not prevent userspace from using the feature's AES instructions +('AES-KL') when the feature has been enabled. So, the lack of userspace +support is only documented, not actively enforced. + +Key Locker is not expected to be advertised to guest VMs and the kernel +implementation ignores it even if the VMM enumerates the capability. The +expectation is that a guest VM wants private wrapping key state, but the +architecture does not provide that. An emulation of that capability, by +caching per-VM wrapping keys in memory, defeats the purpose of Key Locker. +The backup / restore facility is also not performant enough to be suitable +for guest VM context switches. + +AES Instruction Set +=================== + +The feature accompanies a new AES instruction set. This instruction set is +analogous to AES-NI. A set of AES-NI instructions can be mapped to an +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds +of transformation, which is equivalent to nine times AESENC and one +AESENCLAST in AES-NI. + +But they have some notable differences: + +* AES-KL provides a secure data transformation using an encrypted key. + +* If an invalid key handle is provided, e.g. a corrupted one or a handle + restriction failure, the instruction fails with setting RFLAGS.ZF. The + crypto library implementation includes the flag check to return -EINVAL. + Note that this flag is also set if the wrapping key is changed, e.g., + because of the backup error. + +* AES-KL implements support for 128-bit and 256-bit keys, but there is no + AES-KL instruction to process an 192-bit key. The AES-KL cipher + implementation logs a warning message with a 192-bit key and then falls + back to AES-NI. So, this 192-bit key-size limitation is only documented, + not enforced. It means the key will remain in clear-text in memory. This + is to meet Linux crypto-cipher expectation that each implementation must + support all the AES-compliant key sizes. + +* Some AES-KL hardware implementation may have noticeable performance + overhead when compared with AES-NI instructions. + -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v8 01/12] Documentation/x86: Document Key Locker 2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae @ 2023-06-05 10:54 ` Bagas Sanjaya 2023-06-06 2:17 ` Randy Dunlap 1 sibling, 0 replies; 14+ messages in thread From: Bagas Sanjaya @ 2023-06-05 10:54 UTC (permalink / raw) To: Chang S. Bae, linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, Ingo Molnar, H. Peter Anvin, Jonathan Corbet, linux-doc On 6/3/23 22:22, Chang S. Bae wrote: > +============== > +x86 Key Locker > +============== > + > +Introduction > +============ > + > +Key Locker is a CPU feature to reduce key exfiltration opportunities > +while maintaining a programming interface similar to AES-NI. It > +converts the AES key into an encoded form, called the 'key handle'. > +The key handle is a wrapped version of the clear-text key where the > +wrapping key has limited exposure. Once converted, all subsequent data > +encryption using new AES instructions (AES-KL) uses this key handle, > +reducing the exposure of private key material in memory. > + > +CPU-internal Wrapping Key > +========================= > + > +The CPU-internal wrapping key is an entity in a software-invisible CPU > +state. On every system boot, a new key is loaded. So the key handle that > +was encoded by the old wrapping key is no longer usable on system shutdown > +or reboot. > + > +And the key may be lost on the following exceptional situation upon wakeup: > + > +Wrapping Key Restore Failure > +---------------------------- > + > +The CPU state is volatile with the ACPI S3/4 sleep states. When the system > +supports those states, the key has to be backed up so that it is restored > +on wake up. The kernel saves the key in non-volatile media. > + > +The event of a wrapping key restore failure upon resume from suspend, all > +established key handles become invalid. In flight dm-crypt operations > +receive error results from pending operations. In the likely scenario that > +dm-crypt is hosting the root filesystem the recovery is identical to if a > +storage controller failed to resume from suspend, reboot. If the volume "... resume from suspend or reboot." > +impacted by a wrapping key restore failure is a data-volume then it is > +possible that I/O errors on that volume do not bring down the rest of the > +system. However, a reboot is still required because the kernel will have > +soft-disabled Key Locker. Upon the failure, the crypto library code will > +return -ENODEV on every AES-KL function call. The Key Locker implementation > +only loads a new wrapping key at initial boot, not any time after like > +resume from suspend. > + > +Use Case and Non-use Cases > +========================== > + > +Bare metal disk encryption is the only intended use case. > + > +Userspace usage is not supported because there is no ABI provided to > +communicate and coordinate wrapping-key restore failure to userspace. For > +now, key restore failures are only coordinated with kernel users. But the > +kernel can not prevent userspace from using the feature's AES instructions > +('AES-KL') when the feature has been enabled. So, the lack of userspace > +support is only documented, not actively enforced. > + > +Key Locker is not expected to be advertised to guest VMs and the kernel > +implementation ignores it even if the VMM enumerates the capability. The > +expectation is that a guest VM wants private wrapping key state, but the > +architecture does not provide that. An emulation of that capability, by > +caching per-VM wrapping keys in memory, defeats the purpose of Key Locker. > +The backup / restore facility is also not performant enough to be suitable > +for guest VM context switches. > + > +AES Instruction Set > +=================== > + > +The feature accompanies a new AES instruction set. This instruction set is > +analogous to AES-NI. A set of AES-NI instructions can be mapped to an > +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds > +of transformation, which is equivalent to nine times AESENC and one > +AESENCLAST in AES-NI. > + > +But they have some notable differences: > + > +* AES-KL provides a secure data transformation using an encrypted key. > + > +* If an invalid key handle is provided, e.g. a corrupted one or a handle > + restriction failure, the instruction fails with setting RFLAGS.ZF. The > + crypto library implementation includes the flag check to return -EINVAL. > + Note that this flag is also set if the wrapping key is changed, e.g., > + because of the backup error. > + > +* AES-KL implements support for 128-bit and 256-bit keys, but there is no > + AES-KL instruction to process an 192-bit key. The AES-KL cipher > + implementation logs a warning message with a 192-bit key and then falls > + back to AES-NI. So, this 192-bit key-size limitation is only documented, > + not enforced. It means the key will remain in clear-text in memory. This > + is to meet Linux crypto-cipher expectation that each implementation must > + support all the AES-compliant key sizes. > + > +* Some AES-KL hardware implementation may have noticeable performance > + overhead when compared with AES-NI instructions. > + The rest is LGTM, thanks! Anyway, Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> -- An old man doll... just what I always wanted! - Clara ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 01/12] Documentation/x86: Document Key Locker 2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae 2023-06-05 10:54 ` Bagas Sanjaya @ 2023-06-06 2:17 ` Randy Dunlap 2023-06-06 4:18 ` Chang S. Bae 1 sibling, 1 reply; 14+ messages in thread From: Randy Dunlap @ 2023-06-06 2:17 UTC (permalink / raw) To: Chang S. Bae, linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, Ingo Molnar, H. Peter Anvin, Jonathan Corbet, linux-doc On 6/3/23 08:22, Chang S. Bae wrote: > Document the overview of the feature along with relevant consideration > when provisioning dm-crypt volumes with AES-KL instead of AES-NI. > > --- > --- > Documentation/arch/x86/index.rst | 1 + > Documentation/arch/x86/keylocker.rst | 97 ++++++++++++++++++++++++++++ > 2 files changed, 98 insertions(+) > create mode 100644 Documentation/arch/x86/keylocker.rst > > diff --git a/Documentation/arch/x86/keylocker.rst b/Documentation/arch/x86/keylocker.rst > new file mode 100644 > index 000000000000..5557b8d0659a > --- /dev/null > +++ b/Documentation/arch/x86/keylocker.rst > @@ -0,0 +1,97 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +============== > +x86 Key Locker > +============== > + > +Introduction > +============ > + > +Key Locker is a CPU feature to reduce key exfiltration opportunities > +while maintaining a programming interface similar to AES-NI. It > +converts the AES key into an encoded form, called the 'key handle'. > +The key handle is a wrapped version of the clear-text key where the > +wrapping key has limited exposure. Once converted, all subsequent data > +encryption using new AES instructions (AES-KL) uses this key handle, > +reducing the exposure of private key material in memory. > + > +CPU-internal Wrapping Key > +========================= > + > +The CPU-internal wrapping key is an entity in a software-invisible CPU > +state. On every system boot, a new key is loaded. So the key handle that > +was encoded by the old wrapping key is no longer usable on system shutdown > +or reboot. > + > +And the key may be lost on the following exceptional situation upon wakeup: > + > +Wrapping Key Restore Failure > +---------------------------- > + > +The CPU state is volatile with the ACPI S3/4 sleep states. When the system > +supports those states, the key has to be backed up so that it is restored > +on wake up. The kernel saves the key in non-volatile media. > + > +The event of a wrapping key restore failure upon resume from suspend, all Upon the event of a ... > +established key handles become invalid. In flight dm-crypt operations > +receive error results from pending operations. In the likely scenario that > +dm-crypt is hosting the root filesystem the recovery is identical to if a > +storage controller failed to resume from suspend, reboot. If the volume > +impacted by a wrapping key restore failure is a data-volume then it is data volume > +possible that I/O errors on that volume do not bring down the rest of the > +system. However, a reboot is still required because the kernel will have > +soft-disabled Key Locker. Upon the failure, the crypto library code will > +return -ENODEV on every AES-KL function call. The Key Locker implementation > +only loads a new wrapping key at initial boot, not any time after like > +resume from suspend. > + > +Use Case and Non-use Cases > +========================== > + > +Bare metal disk encryption is the only intended use case. > + > +Userspace usage is not supported because there is no ABI provided to > +communicate and coordinate wrapping-key restore failure to userspace. For > +now, key restore failures are only coordinated with kernel users. But the > +kernel can not prevent userspace from using the feature's AES instructions > +('AES-KL') when the feature has been enabled. So, the lack of userspace > +support is only documented, not actively enforced. > + > +Key Locker is not expected to be advertised to guest VMs and the kernel > +implementation ignores it even if the VMM enumerates the capability. The > +expectation is that a guest VM wants private wrapping key state, but the > +architecture does not provide that. An emulation of that capability, by > +caching per-VM wrapping keys in memory, defeats the purpose of Key Locker. > +The backup / restore facility is also not performant enough to be suitable > +for guest VM context switches. > + > +AES Instruction Set > +=================== > + > +The feature accompanies a new AES instruction set. This instruction set is > +analogous to AES-NI. A set of AES-NI instructions can be mapped to an > +AES-KL instruction. For example, AESENC128KL is responsible for ten rounds > +of transformation, which is equivalent to nine times AESENC and one > +AESENCLAST in AES-NI. > + > +But they have some notable differences: > + > +* AES-KL provides a secure data transformation using an encrypted key. > + > +* If an invalid key handle is provided, e.g. a corrupted one or a handle > + restriction failure, the instruction fails with setting RFLAGS.ZF. The > + crypto library implementation includes the flag check to return -EINVAL. > + Note that this flag is also set if the wrapping key is changed, e.g., > + because of the backup error. > + > +* AES-KL implements support for 128-bit and 256-bit keys, but there is no > + AES-KL instruction to process an 192-bit key. The AES-KL cipher > + implementation logs a warning message with a 192-bit key and then falls > + back to AES-NI. So, this 192-bit key-size limitation is only documented, Is it logged anywhere? i.e., a kernel log message? > + not enforced. It means the key will remain in clear-text in memory. This > + is to meet Linux crypto-cipher expectation that each implementation must > + support all the AES-compliant key sizes. > + > +* Some AES-KL hardware implementation may have noticeable performance > + overhead when compared with AES-NI instructions. > + -- ~Randy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 01/12] Documentation/x86: Document Key Locker 2023-06-06 2:17 ` Randy Dunlap @ 2023-06-06 4:18 ` Chang S. Bae 0 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-06-06 4:18 UTC (permalink / raw) To: Randy Dunlap, linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, Ingo Molnar, H. Peter Anvin, Jonathan Corbet, linux-doc On 6/5/2023 7:17 PM, Randy Dunlap wrote: > On 6/3/23 08:22, Chang S. Bae wrote: >> + >> +* AES-KL implements support for 128-bit and 256-bit keys, but there is no >> + AES-KL instruction to process an 192-bit key. The AES-KL cipher >> + implementation logs a warning message with a 192-bit key and then falls >> + back to AES-NI. So, this 192-bit key-size limitation is only documented, > > Is it logged anywhere? i.e., a kernel log message? Yes, this is the relevant change in the last patch: > +static int aeskl_setkey(struct crypto_tfm *tfm, void *raw_ctx, const u8 *in_key, > + unsigned int keylen) > +{ ... > + if (unlikely(keylen == AES_KEYSIZE_192)) { > + pr_warn_once("AES-KL does not support 192-bit key. Use AES-NI.\n"); ... > +} Thanks, Chang ^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for Key Locker [not found] ` <20230603152227.12335-1-chang.seok.bae@intel.com> 2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae @ 2023-06-03 15:22 ` Chang S. Bae 2023-06-03 16:37 ` Borislav Petkov 1 sibling, 1 reply; 14+ messages in thread From: Chang S. Bae @ 2023-06-03 15:22 UTC (permalink / raw) To: linux-kernel, linux-crypto, dm-devel Cc: ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, bp, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, chang.seok.bae, Jonathan Corbet, Ingo Molnar, H. Peter Anvin, linux-doc Add CONFIG_X86_KEYLOCKER to gate whether Key Locker is initialized at boot. The option is selected by the Key Locker cipher module CRYPTO_AES_KL (to be added in a later patch). Add a new command line option "nokeylocker" to optionally override the default CONFIG_X86_KEYLOCKER=y behavior. Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com> Reviewed-by: Dan Williams <dan.j.williams@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Changes from v6: * Rebase on the upstream: commit a894a8a56b57 ("Documentation: kernel-parameters: sort all "no..." parameters") Changes from RFC v2: * Make the option selected by CRYPTO_AES_KL. (Dan Williams) * Massage the changelog and the config option description. --- Documentation/admin-guide/kernel-parameters.txt | 2 ++ arch/x86/Kconfig | 3 +++ arch/x86/kernel/cpu/common.c | 16 ++++++++++++++++ 3 files changed, 21 insertions(+) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index c1247ec4589a..b42fc53cbcf9 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -3749,6 +3749,8 @@ kernel and module base offset ASLR (Address Space Layout Randomization). + nokeylocker [X86] Disable Key Locker hardware feature. + no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page fault handling. diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index a98c5f82be48..f9788b477db1 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1879,6 +1879,9 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS If unsure, say y. +config X86_KEYLOCKER + bool + choice prompt "TSX enable mode" depends on CPU_SUP_INTEL diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 5882ff6e3c6b..718ff1b1d6dd 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -402,6 +402,22 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c) static const unsigned long cr4_pinned_mask = X86_CR4_SMEP | X86_CR4_SMAP | X86_CR4_UMIP | X86_CR4_FSGSBASE | X86_CR4_CET; + +static __init int x86_nokeylocker_setup(char *arg) +{ + /* Expect an exact match without trailing characters. */ + if (strlen(arg)) + return 0; + + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) + return 1; + + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); + pr_info("x86/keylocker: Disabled by kernel command line.\n"); + return 1; +} +__setup("nokeylocker", x86_nokeylocker_setup); + static DEFINE_STATIC_KEY_FALSE_RO(cr_pinning); static unsigned long cr4_pinned_bits __ro_after_init; -- 2.17.1 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for Key Locker 2023-06-03 15:22 ` [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae @ 2023-06-03 16:37 ` Borislav Petkov 2023-06-04 22:13 ` Chang S. Bae 0 siblings, 1 reply; 14+ messages in thread From: Borislav Petkov @ 2023-06-03 16:37 UTC (permalink / raw) To: Chang S. Bae Cc: linux-kernel, linux-crypto, dm-devel, ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, Jonathan Corbet, Ingo Molnar, H. Peter Anvin, linux-doc On Sat, Jun 03, 2023 at 08:22:24AM -0700, Chang S. Bae wrote: > +static __init int x86_nokeylocker_setup(char *arg) > +{ > + /* Expect an exact match without trailing characters. */ > + if (strlen(arg)) > + return 0; > + > + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) > + return 1; > + > + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); > + pr_info("x86/keylocker: Disabled by kernel command line.\n"); > + return 1; > +} > +__setup("nokeylocker", x86_nokeylocker_setup); Can we stop adding those just to remove them at some point later but simply do: clearcpuid=keylocker ? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for Key Locker 2023-06-03 16:37 ` Borislav Petkov @ 2023-06-04 22:13 ` Chang S. Bae 0 siblings, 0 replies; 14+ messages in thread From: Chang S. Bae @ 2023-06-04 22:13 UTC (permalink / raw) To: Borislav Petkov Cc: linux-kernel, linux-crypto, dm-devel, ebiggers, elliott, gmazyland, luto, dave.hansen, tglx, mingo, x86, herbert, ardb, dan.j.williams, bernie.keany, charishma1.gairuboyina, lalithambika.krishnakumar, nhuck, Jonathan Corbet, Ingo Molnar, H. Peter Anvin, linux-doc On 6/3/2023 9:37 AM, Borislav Petkov wrote: > On Sat, Jun 03, 2023 at 08:22:24AM -0700, Chang S. Bae wrote: >> +static __init int x86_nokeylocker_setup(char *arg) >> +{ >> + /* Expect an exact match without trailing characters. */ >> + if (strlen(arg)) >> + return 0; >> + >> + if (!cpu_feature_enabled(X86_FEATURE_KEYLOCKER)) >> + return 1; >> + >> + setup_clear_cpu_cap(X86_FEATURE_KEYLOCKER); >> + pr_info("x86/keylocker: Disabled by kernel command line.\n"); >> + return 1; >> +} >> +__setup("nokeylocker", x86_nokeylocker_setup); > > Can we stop adding those just to remove them at some point later but > simply do: > > clearcpuid=keylocker > > ? Oh, I was not sure about this policy. Thanks, now I'm glad that I have confidence in removing this. Chang ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2023-06-06 4:18 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20220112211258.21115-1-chang.seok.bae@intel.com> 2022-01-12 21:12 ` [PATCH v5 01/12] Documentation/x86: Document Key Locker Chang S. Bae 2023-06-05 10:52 ` Bagas Sanjaya 2022-01-12 21:12 ` [PATCH v5 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230410225936.8940-1-chang.seok.bae@intel.com> 2023-04-10 22:59 ` [PATCH v6 01/12] Documentation/x86: Document " Chang S. Bae 2023-04-10 22:59 ` [PATCH v6 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230524165717.14062-1-chang.seok.bae@intel.com> 2023-05-24 16:57 ` [PATCH v7 01/12] Documentation/x86: Document " Chang S. Bae 2023-05-24 16:57 ` [PATCH v7 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae [not found] ` <20230603152227.12335-1-chang.seok.bae@intel.com> 2023-06-03 15:22 ` [PATCH v8 01/12] Documentation/x86: Document " Chang S. Bae 2023-06-05 10:54 ` Bagas Sanjaya 2023-06-06 2:17 ` Randy Dunlap 2023-06-06 4:18 ` Chang S. Bae 2023-06-03 15:22 ` [PATCH v8 09/12] x86/cpu: Add a configuration and command line option for " Chang S. Bae 2023-06-03 16:37 ` Borislav Petkov 2023-06-04 22:13 ` Chang S. Bae
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).