linux-kernel - Re: [RFCv2 14/16] KVM: Handle protected memory in __kvm_map_gfn()/__kvm_unmap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Oct 2020 16:59:49 +0000
From:   "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To:     "kirill@...temov.name" <kirill@...temov.name>
CC:     "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jmattson@...gle.com" <jmattson@...gle.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "Christopherson, Sean J" <sean.j.christopherson@...el.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "aarcange@...hat.com" <aarcange@...hat.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>,
        "liran.alon@...cle.com" <liran.alon@...cle.com>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "wad@...omium.org" <wad@...omium.org>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "Kleen, Andi" <andi.kleen@...el.com>
Subject: Re: [RFCv2 14/16] KVM: Handle protected memory in
 __kvm_map_gfn()/__kvm_unmap_gfn()

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?