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