On Thu, Oct 22, 2020 at 04:59:49PM +0000, Edgecombe, Rick P wrote: > 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? We need to fail protection enabling if a page is pinned. That's the only option I see. But it might be pain to debug. -- Kirill A. Shutemov
