On Mon, Nov 15, 2021 at 06:26:16PM +0000, Sean Christopherson wrote: > No, because as Andy pointed out, host userspace must already guard against a bad > GPA, i.e. this is just a variant of the guest telling the host to DMA to a GPA > that is completely bogus. The shared vs. private behavior just means that when > host userspace is doing a GPA=>HVA lookup, it needs to incorporate the "shared" > state of the GPA. If the host goes and DMAs into the completely wrong HVA=>PFN, > then that is a host bug; that the bug happened to be exploited by a buggy/malicious > guest doesn't change the fact that the host messed up. The thing is that the usual checking mechanisms can't be applied to guest-private pages. For user-space the GPA is valid if it fits into the guest memory layout user-space set up before. But whether a page is shared or private is the guests business. And without an expensive reporting/query mechanism user-space doesn't have the information to do the check. A mechanism to lock pages to shared is also needed, and that creates the next problems: * Who can release the lock, only the process which created it or anyone who has the memory mapped? * What happens when a process has locked guest regions and then dies with SIGSEGV, will its locks on guest memory be released stay around forever? And this is only what comes to mind immediatly, I sure there are more problematic details in such an interface. Regards, -- Jörg Rödel jroedel@xxxxxxx SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
