Messages in this thread | | | Subject | Re: Should SEV-ES #VC use IST? (Re: [PATCH] Allow RDTSC and RDTSCP from userspace) | From | Andrew Cooper <> | Date | Tue, 28 Apr 2020 17:34:36 +0100 |
| |
On 28/04/2020 08:55, Joerg Roedel wrote: > On Mon, Apr 27, 2020 at 10:37:41AM -0700, Andy Lutomirski wrote: >> I have a somewhat serious question: should we use IST for #VC at all? >> As I understand it, Rome and Naples make it mandatory for hypervisors >> to intercept #DB, which means that, due to the MOV SS mess, it's sort >> of mandatory to use IST for #VC. But Milan fixes the #DB issue, so, >> if we're running under a sufficiently sensible hypervisor, we don't >> need IST for #VC. > The reason for #VC being IST is not only #DB, but also SEV-SNP. SNP adds > page ownership tracking between guest and host, so that the hypervisor > can't remap guest pages without the guest noticing. > > If there is a violation of ownership, which can happen at any memory > access, there will be a #VC exception to notify the guest. And as this > can happen anywhere, for example on a carefully crafted stack page set > by userspace before doing SYSCALL, the only robust choice for #VC is to > use IST.
The kernel won't ever touch the guest stack before restoring %rsp in the syscall path, but the (minimum 2) memory accesses required to save the user %rsp and load the kernel stack may be subject to #VC exceptions, as are instruction fetches at the head of the SYSCALL path.
So yes - #VC needs IST.
Sorry for the noise. (That said, it is unfortunate that the hypervisor messing with the memory backing the guest #VC handler results in an infinite loop, rather than an ability to cleanly terminate.)
~Andrew
| |