Re: AMD SEV-SNP/Intel TDX: validation of memory pages

[Sean Christopherson <seanjc@google.com>]

On Fri, Feb 12, 2021, Dave Hansen wrote:
> On 2/12/21 8:45 AM, Peter Zijlstra wrote:
> > But you're right, if a HV injects #VE in the syscall gap and gets a
> > concurrent CPU to 'fix' the exception frame (which then lives on the
> > user stack) the handler might never know it went ga-ga.
> > 
> > Is this something the TDX thread model covers? A malicous HV and a TDX
> > guest co-operating to bring down the guest kernel.
> 
> I'll say this: The current TDX guest code that Sathya posted is
> predicated on an assumption that an malicious HV can not inject a #VE in
> the syscall gap, or any of the other sensitive paths.
> 
> A #VE in the syscall gap is just as fatal as a #PF or #GP would be
> there.  If TDX can't provide guarantees to the guest that a #VE won't
> happen there, then TDX is broken, or the kernel implementation is broken.
> 
> If anyone knows of any way for a HV to inject #VE in the syscall gap,
> please speak up.  Better to know now.

Removing and reinserting the SYSCALL page (or any other page touched in the
SYSCALL gap) will result in a #VE, as TDX behavior is to generate a #VE on an
access to an unaccepated.

Andy L pointed out this conundrum a while back.  My hack idea to "solve" this
was to add an API to the TDX-Module that would allow the guest kernel to define
a set of GPAs that must never #VE.

https://lkml.kernel.org/r/20200825171903.GA20660@sjchrist-ice