[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b647bed6c75f8743b8afea251a88f00a5feaee29.camel@infradead.org>
Date: Tue, 01 Dec 2020 13:07:23 +0000
From: David Woodhouse <dwmw2@...radead.org>
To: Joao Martins <joao.m.martins@...cle.com>, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Cc: Ankur Arora <ankur.a.arora@...cle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Krčmář <rkrcmar@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [PATCH RFC 03/39] KVM: x86/xen: register shared_info page
On Wed, 2019-02-20 at 20:15 +0000, Joao Martins wrote:
> +static int kvm_xen_shared_info_init(struct kvm *kvm, gfn_t gfn)
> +{
> + struct shared_info *shared_info;
> + struct page *page;
> +
> + page = gfn_to_page(kvm, gfn);
> + if (is_error_page(page))
> + return -EINVAL;
> +
> + kvm->arch.xen.shinfo_addr = gfn;
> +
> + shared_info = page_to_virt(page);
> + memset(shared_info, 0, sizeof(struct shared_info));
> + kvm->arch.xen.shinfo = shared_info;
> + return 0;
> +}
> +
Hm.
How come we get to pin the page and directly dereference it every time,
while kvm_setup_pvclock_page() has to use kvm_write_guest_cached()
instead?
If that was allowed, wouldn't it have been a much simpler fix for
CVE-2019-3016? What am I missing?
Should I rework these to use kvm_write_guest_cached()?
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)
Powered by blists - more mailing lists