linux-kernel - Re: [RFC PATCH v2 00/11] x86: Support Intel Key Locker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <C08CCADB-864B-48E0-89E0-4BF6841771E8@intel.com>
Date:   Mon, 17 May 2021 18:21:55 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        X86 ML <x86@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v2 00/11] x86: Support Intel Key Locker

On May 15, 2021, at 11:01, Andy Lutomirski <luto@...nel.org> 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
state.

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

Thanks,
Chang

[1] https://lore.kernel.org/lkml/20210514201508.27967-4-chang.seok.bae@intel.com/
[2] https://lore.kernel.org/kvm/1611565580-47718-1-git-send-email-robert.hu@linux.intel.com/