On Fri, Feb 12, 2021, Dave Hansen wrote: > On 2/12/21 10:22 AM, Sean Christopherson wrote: > >> If anyone knows of any way for a HV to inject #VE in the syscall gap, > >> please speak up. Better to know now. > > Removing and reinserting the SYSCALL page (or any other page touched in the > > SYSCALL gap) will result in a #VE, as TDX behavior is to generate a #VE on an > > access to an unaccepated. > > > > Andy L pointed out this conundrum a while back. My hack idea to "solve" this > > was to add an API to the TDX-Module that would allow the guest kernel to define > > a set of GPAs that must never #VE. > > > > https://lkml.kernel.org/r/20200825171903.GA20660@sjchrist-ice > > Reminds me of the "what has to be mapped into userspace?" exercise for > PTI. That was fun. > > Really, the hypervisor shouldn't be able to cause #VE's. This should be > fatal to the guest, period. Or, worst case scenario, Linux should be > able to set a bit that says, I will only run under sane hypervisors. If > I somehow lose a bet and get a crappy, insane hypervisor, I want take my > ball and go home: don't even bother running me any more. Hmm, #VEs and #VCs are required for lazy-accept/pvalidate, and for converting pages between private and shared. Those #VEs/#VCs are technically caused by the hypervisor. What I think we want is to prevent the hypervisor from removing an accepted page without an explicit action from the guest. For TDX, IIRC, one of the motivations for allowing the host to remove a page without an explicit action from the guest was to prevent the guest from holding pages hostage. But, if the guest isn't playing nice, the hypervisor can just kill it. So for TDX, I _think_ we could dodge this bullet by making MAP_GPA an API provided by the TDX module so that the module can track which pages are allowed to be removed by the host. The S-EPT entry could be made not-present on MAP_GPA(SHARED) and tagged as being removable. Since the page is not-present, there should be plenty of bits available in the entry to do the tagging. The big question, other than if the above idea is actually feasible, is if page migration in the host would require the guest to re-accept the new page. That would throw a wrench into the whole thing. > No way do we want another fragile list of magic pages that we have to > maintain.
