kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christian Borntraeger <borntraeger@linux.ibm.com>
To: David Woodhouse <dwmw2@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: butterflyhuangxx@gmail.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, seanjc@google.com,
	Cornelia Huck <cohuck@redhat.com>,
	Janosch Frank <frankja@linux.ibm.com>,
	David Hildenbrand <david@redhat.com>,
	linux-s390 <linux-s390@vger.kernel.org>,
	Thomas Huth <thuth@redhat.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: KVM: Warn if mark_page_dirty() is called without an active vCPU
Date: Thu, 13 Jan 2022 16:09:14 +0100	[thread overview]
Message-ID: <4a54cba5-6fce-7810-2966-b990d0dbb7c3@linux.ibm.com> (raw)
In-Reply-To: <bfc53985a178f43a3a21796f33449570cf9e4649.camel@infradead.org>

Am 13.01.22 um 14:22 schrieb David Woodhouse:
> On Thu, 2022-01-13 at 13:51 +0100, Christian Borntraeger wrote:
>>> Btw, that get_map_page() in arch/s390/kvm/interrupt.c looks like it has
>>> the same use-after-free problem that kvm_map_gfn() used to have. It
>>> probably wants converting to the new gfn_to_pfn_cache.
>>> Take a look at how I resolve the same issue for delivering Xen event
>>> channel interrupts.
>> Do you have a commit ID for your Xen event channel fix?
> 14243b387137 ("KVM: x86/xen: Add KVM_IRQ_ROUTING_XEN_EVTCHN and event
> channel delivery") and the commits reworking the gfn_to_pfn_cache which
> lead up to it.
> Questions: In your kvm_set_routing_entry() where it calls
> gmap_translate() to turn the summary_addr and ind_addr from guest
> addresses to userspace virtual addresses, what protects those
> translations? If the gmap changes before kvm_set_routing_entry() even
> returns, what ensures that the IRQ gets retranslated?

In the end the gmap translated between guest physical and host virtual, just
like the kvm memslots. This is done in kvm_arch_commit_memory_region. The gmap
is a method where we share the last level page table between the guest mapping
and the user mapping. That is why our memslots have to be on 1 MB boundary (our
page tables have 256 4k entries). So instead of gmap we could have used the
memslots as well for translation.

I have trouble seeing a kernel integrity issue: worst case is that we point to
a different address in the userspace mapping if qemu would change the memslots
maybe even to an invalid one. But then the access should fail (for invalid) or
you get a self-inflicted bit flips on your own address space if you play such

Well, one thing:  if QEMU changes memslots, it might need to redo the irqfd
registration as well as we do not follow these changes. Maybe this is something
that we could improve as future QEMUs could do more changes regarding memslots.

> And later in adapter_indicators_set() where you take that userspace
> virtual address and pass it to your get_map_page() function, the same
> question: what if userspace does a concurrent mmap() and changes the
> physical page that the userspace address points to?
> In the latter case, at least it does look like you don't support
> external memory accessed only by a PFN without having a corresponding
> struct page. So at least you don't end up accessing a page that can now
> belong to *another* guest, because the original underlying page is
> locked. You're probably OK in that case, so it's just the gmap changing
> that we need to focus on?

  reply	other threads:[~2022-01-13 15:09 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-18 17:14 There is a null-ptr-deref bug in kvm_dirty_ring_get in virt/kvm/dirty_ring.c butt3rflyh4ck
2021-10-21 20:08 ` Paolo Bonzini
2021-10-28  7:42   ` butt3rflyh4ck
2021-11-08  5:11   ` butt3rflyh4ck
2021-11-16 15:41   ` butt3rflyh4ck
2021-11-16 16:22   ` [EXTERNAL] " David Woodhouse
2021-11-16 17:07     ` David Woodhouse
2021-11-17  9:46   ` Woodhouse, David
2021-11-17 16:49     ` Paolo Bonzini
2021-11-17 18:10       ` Woodhouse, David
2021-11-20 10:16   ` KVM: Warn if mark_page_dirty() is called without an active vCPU David Woodhouse
2021-11-22 17:01     ` Sean Christopherson
2021-11-22 17:52       ` David Woodhouse
2021-11-22 18:49         ` Sean Christopherson
2022-01-13 12:06     ` Christian Borntraeger
2022-01-13 12:14       ` Paolo Bonzini
2022-01-13 12:29         ` [PATCH] KVM: avoid warning on s390 in mark_page_dirty Christian Borntraeger
2022-01-13 12:31           ` David Woodhouse
2022-01-18  8:37           ` Christian Borntraeger
2022-01-18  8:44             ` Paolo Bonzini
2022-01-18  8:53               ` Christian Borntraeger
2022-01-18 11:44                 ` Paolo Bonzini
2022-01-13 12:30         ` KVM: Warn if mark_page_dirty() is called without an active vCPU David Woodhouse
2022-01-13 12:51           ` Christian Borntraeger
2022-01-13 13:22             ` David Woodhouse
2022-01-13 15:09               ` Christian Borntraeger [this message]
2022-01-13 14:36           ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a54cba5-6fce-7810-2966-b990d0dbb7c3@linux.ibm.com \
    --to=borntraeger@linux.ibm.com \
    --cc=butterflyhuangxx@gmail.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=frankja@linux.ibm.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=thuth@redhat.com \
    --subject='Re: KVM: Warn if mark_page_dirty() is called without an active vCPU' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).