From: Marc Zyngier <maz@kernel.org>
To: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org
Cc: James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>,
Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Quentin Perret <qperret@google.com>,
Sean Christopherson <seanjc@google.com>,
David Matlack <dmatlack@google.com>
Subject: [PATCH v2 0/2] KVM: arm64: Plug a couple of MM races
Date: Thu, 16 Mar 2023 17:45:44 +0000 [thread overview]
Message-ID: <20230316174546.3777507-1-maz@kernel.org> (raw)
Ard recently reported a really odd warning generated with KASAN, where
the page table walker we use to inspect the userspace page tables was
going into the weeds and accessing something that was looking totally
unrelated (and previously freed).
Will and I spent quite some time looking into it, and while we were
not able to reproduce the issue, we were able to spot at least a
couple of issues that could partially explain the issue.
The first course of action is to disable interrupts while walking the
userspace PTs. This prevents exit_mmap() from tearing down these PTs
by blocking the IPI. We also fail gracefully if the IPI won the race
and killed the page tables before we started the walk.
The second issue is to not use a VMA pointer that was obtained with
the mmap_read_lock held after that lock has been released. There is no
guarantee that it is still valid.
I've earmarked both for stable, though I expect backporting this to
older revisions of the kernel could be... interesting.
* From v1[1]:
- Return -EAGAIN from get_user_mapping_size() when the mapping is
gone instead of -EFAULT which would be fatal (which is still
returned in cases that are not expected to be seen). Other error
codes can also be returned from kvm_pgtable_get_leaf(), but always
in conditions that are rather bad.
- Rebased on top of kvmarm/fixes which already contains David's own
MMU fix.
[1] https://lore.kernel.org/r/20230313091425.1962708-1-maz@kernel.org
Marc Zyngier (2):
KVM: arm64: Disable interrupts while walking userspace PTs
KVM: arm64: Check for kvm_vma_mte_allowed in the critical section
arch/arm64/kvm/mmu.c | 53 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 44 insertions(+), 9 deletions(-)
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2023-03-16 17:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 17:45 Marc Zyngier [this message]
2023-03-16 17:45 ` [PATCH v2 1/2] KVM: arm64: Disable interrupts while walking userspace PTs Marc Zyngier
2023-03-16 23:42 ` Oliver Upton
2023-03-17 9:03 ` Marc Zyngier
2023-03-16 17:45 ` [PATCH v2 2/2] KVM: arm64: Check for kvm_vma_mte_allowed in the critical section Marc Zyngier
2023-03-17 1:20 ` [PATCH v2 0/2] KVM: arm64: Plug a couple of MM races Oliver Upton
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230316174546.3777507-1-maz@kernel.org \
--to=maz@kernel.org \
--cc=ardb@kernel.org \
--cc=dmatlack@google.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).