kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Robert Hoo <robert.hu@linux.intel.com>
Cc: pbonzini@redhat.com, vkuznets@redhat.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org, chang.seok.bae@intel.com,
	kvm@vger.kernel.org, robert.hu@intel.com
Subject: Re: [RFC PATCH 00/12] KVM: Support Intel KeyLocker
Date: Mon, 5 Apr 2021 16:03:56 +0000	[thread overview]
Message-ID: <YGs07I/mKhDy3pxD@google.com> (raw)
In-Reply-To: <1611565580-47718-1-git-send-email-robert.hu@linux.intel.com>

On Mon, Jan 25, 2021, Robert Hoo wrote:
> IWKey, is the core of this framework. It is loaded into CPU by LOADIWKEY
> instruction, then inaccessible from (CPU) outside anymore.

Unless the VMM intercepts and saves the key in normal memory, which is what this
series proposes to do.  That needs to be called out very, very clearly.

> LOADIWKEY is the
> only Key Locker instruction that will cause VM-exit (if we set so in VM
> Execution Control). When load IWKey into CPU, we can ask CPU further
> randomize it, if HW supports this.
> The IWKey can also be distributed among CPUs, rather than LOADIWKEY on each
> CPU, by: first backup IWKey to platform specific storage, then copy it on
> target CPU. The backup process is triggered by writing to MSR
> IA32_COPY_LOCAL_TO_PLATFORM. The restore process is triggered by writing to
> Virtualization Design
> Key Locker Spec [2] indicates virtualization limitations by current HW
> implementation.
> 1) IWKey cannot be read from CPU after it's loaded (this is the nature of
> this feature) and only 1 copy of IWKey inside 1 CPU.
> 2) Initial implementations may take a significant amount of time to perform
> a copy of IWKeyBackup to IWKey (via a write to MSR
> IA32_COPY_PLATFORM_LOCAL) so it may cause a significant performance impact
> to reload IWKey after each VM exit.
> Due to above reasons, virtualization design makes below decisions
> 1) don't expose HW randomize IWKey capability (CPUID.0x19.ECX[1]) to guest. 
>    As such, guest IWKey cannot be preserved by VMM across VM-{Exit, Entry}.
>    (VMM cannot know what exact IWKey were set by CPU)
> 2) guests and host can only use Key Locker feature exclusively. [4] 
> The virtualization implementation is generally straight forward
> 1) On VM-Exit of guest 'LOADIWKEY', VMM stores the IWKey in vCPU scope
>         area (kvm_vcpu_arch)
> 2) Right before VM-Entry, VMM load that vCPU's IWKey in to pCPU, by
> LOADIWKEY instruction.
> 3) On guest backup local to platform operation, VMM traps the write
>    to MSR, and simulate the IWKey store process by store it in a KVM
>    scope area (kvm_arch), mark the success status in the shadow
>    msr_ia32_iwkey_backup_status and msr_ia32_copy_status.
> 4) On guest copy from platform to local operation, VMM traps the write
>    to MSR and simulate the process by load kvm_arch.iwkey_backup to
>    vCPU.iwkey; and simulate the success status in the
>    shadow msr_ia32_copy_status.
> 5) Guest read the 2 status MSRs will also be trapped and return the shadow
>    value.
> 6) Other Key Locker instructions can run without VM-Exit in non-root mode.
> At the end, we don't suggest this feature to be migratable, as if so, IWKey
> would have to be exposed to user space, which would weaken this feature's

/s/weaken/further weaken.  Saving the key in host kernel memory already subverts
IWKey to some extent.

Is there a concrete use case for virtualizing IWKey?  The caveats that come with
it quite nasty, e.g. reduced security (relative to native IWKey), not migratable,
increased vCPU switching latency, etc...

> security significance.

      parent reply	other threads:[~2021-04-05 16:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25  9:06 [RFC PATCH 00/12] KVM: Support Intel KeyLocker Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 01/12] x86/keylocker: Move LOADIWKEY opcode definition from keylocker.c to keylocker.h Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 02/12] x86/cpufeature: Add CPUID.19H:{EBX,ECX} cpuid leaves Robert Hoo
2021-04-05 15:32   ` Sean Christopherson
2021-04-06  3:34     ` Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 03/12] kvm/vmx: Introduce the new tertiary processor-based VM-execution controls Robert Hoo
2021-01-25  9:41   ` Vitaly Kuznetsov
2021-01-26  9:27     ` Robert Hoo
2021-02-03  6:32     ` Robert Hoo
2021-02-03  8:45       ` Vitaly Kuznetsov
2021-04-05 15:38   ` Sean Christopherson
2021-04-06  3:37     ` Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 04/12] kvm/vmx: enable LOADIWKEY vm-exit support in " Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 05/12] kvm/vmx: Add KVM support on KeyLocker operations Robert Hoo
2021-04-05 16:25   ` Sean Christopherson
2021-04-08  5:44     ` Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 06/12] kvm/cpuid: Enumerate KeyLocker feature in KVM Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 07/12] kvm/vmx/nested: Support new IA32_VMX_PROCBASED_CTLS3 vmx feature control MSR Robert Hoo
2021-04-05 15:44   ` Sean Christopherson
2021-04-08  5:45     ` Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 08/12] kvm/vmx: Refactor vmx_compute_tertiary_exec_control() Robert Hoo
2021-04-05 15:46   ` Sean Christopherson
2021-04-08  5:45     ` Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 09/12] kvm/vmx/vmcs12: Add Tertiary Exec-Control field in vmcs12 Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 10/12] kvm/vmx/nested: Support tertiary VM-Exec control in vmcs02 Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 11/12] kvm/vmx/nested: Support CR4.KL in nested Robert Hoo
2021-01-25  9:06 ` [RFC PATCH 12/12] kvm/vmx/nested: Enable nested LOADIWKey VM-exit Robert Hoo
2021-04-05 16:03 ` Sean Christopherson [this message]

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 \
    --in-reply-to=YGs07I/mKhDy3pxD@google.com \
    --to=seanjc@google.com \
    --cc=chang.seok.bae@intel.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=robert.hu@intel.com \
    --cc=robert.hu@linux.intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \


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