On Fri, Feb 12, 2021 at 05:45:11PM +0100, Peter Zijlstra wrote: > I really don't want #VE to be IST. I really *really* detests ISTs, > they're an unmitigated trainwreck. > > 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. If the guest is not malicous, and you have a valid user-stack in the SYSCALL gap, then it depends on whether SMAP is active. I guess it usually is, in which case the #VE would be promoted to a #DF to kill the machine. But since we don't trust user-space either in a TDX guest, it must be expected that user RSP points to something clever within the kernel. And in this case making #VE an IST handler will be the only help. Note that a TDX guest doesn't need to be kept alive in this situation, but we must make sure it can reliably crash. Otherwise a naughty HV has a chance to take control of the code-flow in the guest to make it reveal its secrets. Regards, Joerg
