linux-kernel - Re: [PATCH v5.1 27/34] KVM: SVM: Add support for booting APs in an SEV-ES guest

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] [day] [month] [year] [list]

Message-ID: <e543b262-d5d2-a752-72df-5299919720a3@amd.com>
Date:   Thu, 7 Jan 2021 13:53:36 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org
Cc:     Jim Mattson <jmattson@...gle.com>, Joerg Roedel <joro@...tes.org>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v5.1 27/34] KVM: SVM: Add support for booting APs in an
 SEV-ES guest

On 1/7/21 12:13 PM, Paolo Bonzini wrote:
> On 04/01/21 21:20, Tom Lendacky wrote:
>> From: Tom Lendacky <thomas.lendacky@....com>
>>
>> Typically under KVM, an AP is booted using the INIT-SIPI-SIPI sequence,
>> where the guest vCPU register state is updated and then the vCPU is VMRUN
>> to begin execution of the AP. For an SEV-ES guest, this won't work because
>> the guest register state is encrypted.
>>
>> Following the GHCB specification, the hypervisor must not alter the guest
>> register state, so KVM must track an AP/vCPU boot. Should the guest want
>> to park the AP, it must use the AP Reset Hold exit event in place of, for
>> example, a HLT loop.
>>
>> First AP boot (first INIT-SIPI-SIPI sequence):
>>    Execute the AP (vCPU) as it was initialized and measured by the SEV-ES
>>    support. It is up to the guest to transfer control of the AP to the
>>    proper location.
>>
>> Subsequent AP boot:
>>    KVM will expect to receive an AP Reset Hold exit event indicating that
>>    the vCPU is being parked and will require an INIT-SIPI-SIPI sequence to
>>    awaken it. When the AP Reset Hold exit event is received, KVM will place
>>    the vCPU into a simulated HLT mode. Upon receiving the INIT-SIPI-SIPI
>>    sequence, KVM will make the vCPU runnable. It is again up to the guest
>>    to then transfer control of the AP to the proper location.
>>
>>    To differentiate between an actual HLT and an AP Reset Hold, a new MP
>>    state is introduced, KVM_MP_STATE_AP_RESET_HOLD, which the vCPU is
>>    placed in upon receiving the AP Reset Hold exit event. Additionally, to
>>    communicate the AP Reset Hold exit event up to userspace (if needed), a
>>    new exit reason is introduced, KVM_EXIT_AP_RESET_HOLD.
>>
>> A new x86 ops function is introduced, vcpu_deliver_sipi_vector, in order
>> to accomplish AP booting. For VMX, vcpu_deliver_sipi_vector is set to the
>> original SIPI delivery function, kvm_vcpu_deliver_sipi_vector(). SVM adds
>> a new function that, for non SEV-ES guests, invokes the original SIPI
>> delivery function, kvm_vcpu_deliver_sipi_vector(), but for SEV-ES guests,
>> implements the logic above.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
> 
> Queued, thanks.

Thanks, Paolo!

Tom

> 
> Paolo
>