linux-kernel - Re: [RFC PATCH V6 01/14] x86/sev: Add a #HV exception handler

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: <383cd217-b128-fcca-0a99-432210de5e99@amd.com>
Date:   Wed, 7 Jun 2023 13:19:59 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     "Gupta, Pankaj" <pankaj.gupta@....com>,
        Tianyu Lan <ltykernel@...il.com>, luto@...nel.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        seanjc@...gle.com, pbonzini@...hat.com, jgross@...e.com,
        tiala@...rosoft.com, kirill@...temov.name,
        jiangshan.ljs@...group.com, ashish.kalra@....com,
        srutherford@...gle.com, akpm@...ux-foundation.org,
        anshuman.khandual@....com, pawan.kumar.gupta@...ux.intel.com,
        adrian.hunter@...el.com, daniel.sneddon@...ux.intel.com,
        alexander.shishkin@...ux.intel.com, sandipan.das@....com,
        ray.huang@....com, brijesh.singh@....com, michael.roth@....com,
        venu.busireddy@...cle.com, sterritt@...gle.com,
        tony.luck@...el.com, samitolvanen@...gle.com, fenghua.yu@...el.com,
        pangupta@....com, linux-kernel@...r.kernel.org,
        kvm@...r.kernel.org, linux-hyperv@...r.kernel.org,
        linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH V6 01/14] x86/sev: Add a #HV exception handler

On 5/31/23 04:14, Peter Zijlstra wrote:
> On Tue, May 30, 2023 at 08:52:32PM +0200, Peter Zijlstra wrote:
> 
>>> That should really say that a nested #HV should never be raised by the
>>> hypervisor, but if it is, then the guest should detect that and
>>> self-terminate knowing that the hypervisor is possibly being malicious.
>>
>> I've yet to see code that can do that reliably.
> 
> Tom; could you please investigate if this can be enforced in ucode?
> 
> Ideally #HV would have an internal latch such that a recursive #HV will
> terminate the guest (much like double #MC and tripple-fault).
> 
> But unlike the #MC trainwreck, can we please not leave a glaring hole in
> this latch and use a spare bit in the IRET frame please?
> 
> So have #HV delivery:
>   - check internal latch; if set, terminate machine
>   - set latch
>   - write IRET frame with magic bit set
> 
> have IRET:
>   - check magic bit and reset #HV latch

Hi Peter,

I talked with the hardware team about this and, unfortunately, it is not 
practical to implement. The main concerns are that there are already two 
generations of hardware out there with the current support and, given 
limited patch space, in addition to the ucode support to track and perform 
the latch support, additional ucode support would be required to 
save/restore the latch information when handling a VMEXIT during #HV 
processing.

Thanks,
Tom

>