linux-kernel - Re: [PATCH] KVM: SVM: Do not terminate SEV-ES guests on GHCB validation failure

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

Message-ID: <324d9228-03e9-0fe2-59c0-5e41e449211b@amd.com>
Date:   Mon, 17 May 2021 10:08:03 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     kvm list <kvm@...r.kernel.org>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Paolo Bonzini <pbonzini@...hat.com>,
        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] KVM: SVM: Do not terminate SEV-ES guests on GHCB
 validation failure

On 5/14/21 6:06 PM, Peter Gonda wrote:
> On Fri, May 14, 2021 at 1:22 PM Tom Lendacky <thomas.lendacky@....com> wrote:
>>
>> Currently, an SEV-ES guest is terminated if the validation of the VMGEXIT
>> exit code and parameters fail. Since the VMGEXIT instruction can be issued
>> from userspace, even though userspace (likely) can't update the GHCB,
>> don't allow userspace to be able to kill the guest.
>>
>> Return a #GP request through the GHCB when validation fails, rather than
>> terminating the guest.
> 
> Is this a gap in the spec? I don't see anything that details what
> should happen if the correct fields for NAE are not set in the first
> couple paragraphs of section 4 'GHCB Protocol'.

No, I don't think the spec needs to spell out everything like this. The
hypervisor is free to determine its course of action in this case.

I suppose the spec could suggest a course of action, but I don't think the
spec should require a specific course of action.

Thanks,
Tom

>