Messages in this thread | | | Date | Thu, 17 Mar 2022 13:32:07 -0700 | From | Dave Hansen <> | Subject | Re: [PATCHv6 07/30] x86/traps: Add #VE support for TDX guest |
| |
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.
| |