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 for Android: free password hash cracker in your pocket

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

Message-ID: <YKLO8ryjO7gZKJQC@google.com>
Date:   Mon, 17 May 2021 20:15:46 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Bae, Chang Seok" <chang.seok.bae@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        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 Mon, May 17, 2021, Bae, Chang Seok wrote:
> On May 15, 2021, at 11:01, Andy Lutomirski <luto@...nel.org> wrote:
> > What is the expected interaction between a KL-using VM guest and the
> > host VMM?

Messy.  :-)

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

Short answer, yes.  But the proposed solution is to disallow KL in KVM guests if
KL is in use by the host.  The problem is that, by design, the host can't restore
its key via LOADIWKEY because the whole point is to throw away the real key.  To
restore its value, the host would need to use the platform backup/restore
mechanism, which is comically slow (tens of thousands of cycles).

If KL virtualization is mutually exclusive with use in the host, then IIRC the
context switching penalty is only paid by vCPUs that have executed LOADIWKEY, as
other tasks can safely run with a stale/bogus key.

> > Should Linux actually enable KL if it detects that it's a VM guest?

Probably not by default.  It shouldn't even be considered unless the VMM is
trusted, as a malicious VMM can completely subvert KL.  Even if the host is
trusted, it's not clear that the tradeoffs are a net win.

Practically speaking, VMMs have to either (a) save the real key in host memory
or (b) provide a single VM exclusive access to the underlying hardware.

For (a), that rules out using an ephemeral, random key, as using a truly random
key prevents the VMM from saving/restoring the real key.  That means the guest
has to generate its own key, and the host has to also store the key in memory.
There are also potential performance and live migration implications.  The only
benefit to using KL in the guest is that the real key is not stored in _guest_
accessible memory.  So it probably reduces the attack surface, but on the other
hand the VMM may store the guest's master key in a known location, which might
make cross-VM attacks easier in some ways.

(b) is a fairly unlikely scenario, and certainly can't be assumed to be the
default scenario for a guest.

> > Should Linux have use a specific keying method as a guest?

Could you rephrase this question?  I didn't follow.

> First of all, there is an RFC series for KVM [2].

That series also fails to address the use case question.

[*] https://lore.kernel.org/kvm/YGs07I%2FmKhDy3pxD@google.com/