linux-kernel - Re: [RFC PATCH 0/8] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <FED814E6-425E-405D-9907-609C4B51D739@intel.com>
Date:   Tue, 22 Dec 2020 19:03:14 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     "Cooper, Andrew" <andrew.cooper3@...rix.com>,
        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>,
        "Sun, Ning" <ning.sun@...el.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@...el.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/8] x86: Support Intel Key Locker


> On Dec 20, 2020, at 03:59, Andy Lutomirski <luto@...nel.org> wrote:
> 
> On Wed, Dec 16, 2020 at 9:46 AM Chang S. Bae <chang.seok.bae@...el.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