linux-kernel - Re: [PATCH 04/26] x86/traps: Add #VE support for TDX 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YcyV1uwa72vhPXPV@google.com>
Date:   Wed, 29 Dec 2021 17:07:34 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        tglx@...utronix.de, mingo@...hat.com, dave.hansen@...el.com,
        luto@...nel.org, peterz@...radead.org,
        sathyanarayanan.kuppuswamy@...ux.intel.com, aarcange@...hat.com,
        ak@...ux.intel.com, dan.j.williams@...el.com, david@...hat.com,
        hpa@...or.com, jgross@...e.com, jmattson@...gle.com,
        joro@...tes.org, jpoimboe@...hat.com, knsathya@...nel.org,
        pbonzini@...hat.com, sdeep@...are.com, tony.luck@...el.com,
        vkuznets@...hat.com, wanpengli@...cent.com, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        Sean Christopherson <sean.j.christopherson@...el.com>
Subject: Re: [PATCH 04/26] x86/traps: Add #VE support for TDX guest

On Wed, Dec 29, 2021, Borislav Petkov wrote:
> On Wed, Dec 29, 2021 at 02:31:12AM +0300, Kirill A. Shutemov wrote:
> What I read is:
> 
> "Interrupts, including NMIs, are blocked by the hardware starting with
> #VE delivery until TDGETVEINFO is called."

FWIW, virtual/guest NMIs are blocked by the TDX module until pending #VE info
is retrieved via TDGETVEINFO.  Hardware has nothing to do with that behavior.

> but this simply means that *if* you get a #VE anywhere, NMIs are masked
> until TDGETVEINFO.

Yep.

> If you get a #VE during the NMI entry code, then you're toast...

Yes?  The rules would be the same as whatever existing rules we have for taking
#DBs in NMI, but that's because the subsequent IRET unblocking NMIs, not because
there's anything special about #VE.  Pending NMIs are blocked by the regular NMI
status (unblocked by IRET) _and_ by an unread #VE info.

The unread #VE info clause in NMI blocking is purely to prevent an NMI from being
injected before the guest's #VE handler can do TDGETVEINFO, otherwise a #VE at
_any_ point in the NMI handler would be fatal due to it clobbering the unread #VE
info (it'd be a similar problem to SEV-ES's GHCB juggling).