archive mirror
 help / color / mirror / Atom feed
From: "Bae, Chang Seok" <>
To: Andy Lutomirski <>
Cc: Thomas Gleixner <>,
	Ingo Molnar <>, Borislav Petkov <>,
	X86 ML <>, Herbert Xu <>,
	"Williams, Dan J" <>,
	"Hansen, Dave" <>,
	"Shankar, Ravi V" <>,
	Linux Crypto Mailing List <>,
	"" <>
Subject: Re: [RFC PATCH v2 00/11] x86: Support Intel Key Locker
Date: Mon, 17 May 2021 18:21:55 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On May 15, 2021, at 11:01, Andy Lutomirski <> wrote:
> On 5/14/21 1:14 PM, Chang S. Bae 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.
>> 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

> 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.



  reply	other threads:[~2021-05-17 18:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-14 20:14 [RFC PATCH v2 00/11] x86: Support Intel Key Locker Chang S. Bae
2021-05-14 20:14 ` [RFC PATCH v2 01/11] x86/cpufeature: Enumerate Key Locker feature Chang S. Bae
2021-05-14 20:14 ` [RFC PATCH v2 02/11] x86/insn: Add Key Locker instructions to the opcode map Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 03/11] x86/cpu: Load Key Locker internal key at boot-time Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 04/11] x86/msr-index: Add MSRs for Key Locker internal key Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 05/11] x86/power: Restore Key Locker internal key from the ACPI S3/4 sleep states Chang S. Bae
2021-05-24 14:21   ` Rafael J. Wysocki
2021-05-14 20:15 ` [RFC PATCH v2 06/11] x86/cpu: Add a config option and a chicken bit for Key Locker Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 07/11] selftests/x86: Test Key Locker internal key maintenance Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 08/11] crypto: x86/aes-ni - Improve error handling Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 09/11] crypto: x86/aes-ni - Refactor to prepare a new AES implementation Chang S. Bae
2021-05-14 20:15 ` [RFC PATCH v2 10/11] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions Chang S. Bae
2021-05-17 21:34   ` Eric Biggers
2021-05-17 22:20     ` Bae, Chang Seok
2021-05-17 23:33       ` Eric Biggers
2021-05-18 16:57   ` Andy Lutomirski
2021-05-14 20:15 ` [RFC PATCH v2 11/11] x86/cpu: Support the hardware randomization option for Key Locker internal key Chang S. Bae
2021-05-15 18:01 ` [RFC PATCH v2 00/11] x86: Support Intel Key Locker Andy Lutomirski
2021-05-17 18:21   ` Bae, Chang Seok [this message]
2021-05-17 18:45     ` Dan Williams
2021-05-17 22:20       ` Bae, Chang Seok
2021-05-17 20:15     ` Sean Christopherson
2021-05-18 17:10     ` Andy Lutomirski
2021-05-18 17:52       ` Sean Christopherson
2021-05-19 23:26         ` Andy Lutomirski
2021-05-19 23:34           ` Sean Christopherson
2021-05-20  0:00             ` Sean Christopherson
2021-12-06 21:48       ` Bae, Chang Seok

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).