[lkml]   [2021]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 04/26] x86/traps: Add #VE support for TDX guest
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.

VMM can remove private memory from under us, but access to unaccepted (or
missing) private memory leads to VM termination, not to #VE.

The situation is similar to NMIs vs. breakpoints.

> > + * be handled.
> > + *
> > + * For dis-allowed or invalid #VE just return failure.
> > + *
> > + * Return True on success and False on failure.
> You lost me here - function returns false unconditionally. And that
> bla about CPUID from user being a valid case doesn't really look like
> one when I look at the code. Especially since ve_raise_fault() sends a
> SIGSEGV for user #VEs.

tdx_virt_exception_user()/tdx_virt_exception_kernel() will be populated by
following patches. The patch adds generic infrastructure for #VE handling.

Kirill A. Shutemov

 \ /
  Last update: 2021-12-29 00:32    [W:0.176 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site