Re: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest

[Dave Hansen]

On 3/17/22 13:21, Peter Zijlstra wrote:
> 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?

#GP and #PF can be raised from any memop too.  But, we know that if we
only touch normal, valid kernel mappings, we don't have to worry about them.

The memop rules to avoid #VE are basically the same, except they also
include "TD-shared" memory.  But, "normal" kernel memory isn't ever
shared because it's under the control of the untrusted hypervisor.  The
kernel trusts shared memory like it trusts userspace-mapped memory.

The kernel would be insane to, for instance, put its stack in
userspace-writable memory.  The same goes for TD-shared memory.

In the end, I'm asserting that we don't really have to be any more
careful to avoid a #VE on a memory access than we are to avoid #GP and #PF.

The TDX rules are *much* nicer than SEV.  They're also a lot nicer on
TDX _now_ than they used to be.  There are a few stubborn people at
Intel who managed to add some drops of sanity to the architecture.