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: <2d65ef4f-acc9-4cd1-ca39-c1f57a5cd821@intel.com>
Date:   Wed, 29 Dec 2021 10:42:38 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Borislav Petkov <bp@...en8.de>
Cc:     tglx@...utronix.de, mingo@...hat.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,
        seanjc@...gle.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 12/28/21 3:31 PM, Kirill A. Shutemov wrote:
> On Thu, Dec 23, 2021 at 08:45:40PM +0100, Borislav Petkov wrote:
>> What happens if the NMI handler triggers a #VE after all? Or where is it
>> enforced that TDX guests should set panic_on_oops?
> Kernel will handle the #VE normally inside NMI handler. (We tested it once
> again, just in case.)
> 
> The critical part is that #VE must not be triggered in NMI entry code,
> before kernel is ready to handle nested NMIs. 
> 
> #VE cannot possibly happen there: no #VE-inducing instructions, code and
> data are in guest private memory.
...
> The situation is similar to NMIs vs. breakpoints.

Or page faults for that matter.

Page faults are architecturally permitted to occur in the NMI entry
path.  But, there's no facility to handle them.  The kernel (mostly
easily) avoids doing things that might cause page faults in the NMI
entry path.

The same goes for #VE's in the same path.  A guest is written to avoid
#VE in the NMI entry.  If they happen in that path, there's a bug somewhere.

I wouldn't go as far as to say "#VE cannot possibly happen there (NMI
entry code)".  They *CAN* happen there, but the kernel is doing
everything it can to avoid them.