lkml.org 
[lkml]   [2022]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest
On Thu, Mar 17, 2022 at 08:33:54PM +0300, Kirill A. Shutemov wrote:

> [ Disclaimer: I have limited understanding of the entry code complexity
> and may miss some crucial details. But I try my best. ]
>
> Yes, it is the same comment, but it is based on code audit, not only on
> testing.
>
> I claim that kernel does not do anything that can possibly trigger #VE
> where kernel cannot deal with it:
>
> - on syscall entry code before kernel stack is set up (few instructions
> in the beginning of entry_SYSCALL_64())
>
> - in NMI entry code (asm_exc_nmi()) before NMI nesting is safe:
> + for NMI from user mode, before switched to thread stack
> + for NMI from kernel, up to end_repead_nmi
>
> After that points #VE is safe.

In what way is it guaranteed that #VE isn't raised in those places? What
does an auditor / future coder looking to changes things, need to
consider to keep this so.

From vague memories #VE can be raised on any memop, loading the stack
address in the syscall-gap is a memop. What makes that special? Can we
get a comment _there_ to explain how this is safe such that we can keep
it so?

Same for the NMI path I suppose.

\
 
 \ /
  Last update: 2022-03-17 21:26    [W:0.278 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site