On Thu, 2020-10-22 at 15:06 +0300, Kirill A. Shutemov wrote: > > I think the page could have got unmapped since the gup via the > > hypercall on another CPU. It could be an avenue for the guest to > > crash > > the host. > > Hm.. I'm not sure I follow. Could you elaborate on what scenario you > have > in mind? Kind of similar scenario as the userspace triggered oops. My understanding is that the protected status was gathered along with the gup, but after the mm gets unlocked, nothing stops the page transitioning to unmapped(?). At which point kmap() from a previous gup with !protected, would go down the regular kmap() route and return an address to an unmapped page. So the guest kernel could start with a page mapped as shared via the hypercall. Then trigger one of the PV MSR's that kmap() on CPU0. On CPU1, after the gup on CPU0, it could transitioned the page to private/unmapped via the hypercall. So the hva_to_pfn() would find !protected, but by the time the kmap() happened the page would have been unmapped. Am I missing something?
