On Sat, Nov 13, 2021, Marc Orr wrote: > On Sat, Nov 13, 2021 at 10:28 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > The behavior is no different than it is today for regular VMs. > > Isn't this counter to the sketch you laid out earlier where you wrote: > > --- QUOTE START --- > - if userspace accesses guest private memory, it gets SIGSEGV or whatever. > - if kernel accesses guest private memory, it does BUG/panic/oops[*] > - if guest accesses memory with the incorrect C/SHARED-bit, it gets killed. > --- QUOTE END --- > > Here, the guest does not get killed. Which seems hard to debug. No, it does contradict that statement. If the guest requests a conversion from shared=>private without first ensuring the gfn is unused (by a host "device"), the host will side will continue accessing the old, shared memory, which it locked, while the guest will be doing who knows what. In this case, the guest will have converted a GPA from shared=>private, i.e. changed the effective GFN for a e.g. a shared queue, without informing host userspace that the GFN, and thus the associated HVA in the host, has changed. For TDX that is literally the same bug as the guest changing the GFN without informing the host, as the SHARED bit is just an address bit with some extra meaning piled on top. For SNP, it's slightly different because the C-bit isn't strictly required to be an address bit, but for all intents and purposes it's the same type of bug. I phrased it "guest will be doing who knows what" because from a host userspace perspective, it can't know what the guest behavior will be, and more importantly, it doesn't care because (a) the guest is buggy and (b) the host itself is _not_ in danger. Yes, those types of bugs suck to debug. But they really should be few and far between. The only reason I called out this specific scenario was to note that host userspace doesn't need to take extra steps to guard against bogus shared=>private conversions, because host userspace already needs to have such guards in place. In prior (offline?) conversations, we had assumed that host userspace would need to propagate the shared vs. private status to any and all processes that map guest memory, i.e. would require substantial enabling, but that assumption was wrong. > If allowing userspace to inject #VC into the guest means that the host > can continue to serve other guests, that seems like a win. The > alternative, to blow up the host, essentially expands the blast radius > from a single guest to all guests. As mentioned in other threads of this conversation, when I say "host crashes", I am specifically talking about scenarios where it is simply not possible for the host kernel to recover, e.g. an RMP #PF violation on the IDT. Setting that aside, injecting a #VC into the guest is not in anyway necessary for a buggy host userspace to terminate a single guest, host userspace can simply stop running that specific guest.
