From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, kernel-team@android.com,
stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>, Qais Yousef <qais.yousef@arm.com>
Subject: [PATCH 08/12] KVM: arm64: Force PTE mapping on fault resulting in a device mapping
Date: Fri, 30 Oct 2020 16:40:13 +0000 [thread overview]
Message-ID: <20201030164017.244287-9-maz@kernel.org> (raw)
In-Reply-To: <20201030164017.244287-1-maz@kernel.org>
From: Santosh Shukla <sashukla@nvidia.com>
VFIO allows a device driver to resolve a fault by mapping a MMIO
range. This can be subsequently result in user_mem_abort() to
try and compute a huge mapping based on the MMIO pfn, which is
a sure recipe for things to go wrong.
Instead, force a PTE mapping when the pfn faulted in has a device
mapping.
Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Santosh Shukla <sashukla@nvidia.com>
[maz: rewritten commit message]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1603711447-11998-2-git-send-email-sashukla@nvidia.com
---
arch/arm64/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index e431d2d8e368..c7c6df6309d5 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -851,6 +851,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (kvm_is_device_pfn(pfn)) {
device = true;
+ force_pte = true;
} else if (logging_active && !write_fault) {
/*
* Only actually map the page as writable if this was a write
--
2.28.0
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Santosh Shukla <sashukla@nvidia.com>,
Gavin Shan <gshan@redhat.com>,
kvm@vger.kernel.org, Quentin Perret <qperret@google.com>,
kernel-team@android.com,
Suzuki K Poulose <suzuki.poulose@arm.com>,
stable@vger.kernel.org, kvmarm@lists.cs.columbia.edu,
Vladimir Murzin <vladimir.murzin@arm.com>,
James Morse <james.morse@arm.com>,
linux-arm-kernel@lists.infradead.org,
David Brazdil <dbrazdil@google.com>,
Will Deacon <will@kernel.org>, Qais Yousef <qais.yousef@arm.com>,
Julien Thierry <julien.thierry.kdev@gmail.com>
Subject: [PATCH 08/12] KVM: arm64: Force PTE mapping on fault resulting in a device mapping
Date: Fri, 30 Oct 2020 16:40:13 +0000 [thread overview]
Message-ID: <20201030164017.244287-9-maz@kernel.org> (raw)
In-Reply-To: <20201030164017.244287-1-maz@kernel.org>
From: Santosh Shukla <sashukla@nvidia.com>
VFIO allows a device driver to resolve a fault by mapping a MMIO
range. This can be subsequently result in user_mem_abort() to
try and compute a huge mapping based on the MMIO pfn, which is
a sure recipe for things to go wrong.
Instead, force a PTE mapping when the pfn faulted in has a device
mapping.
Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Santosh Shukla <sashukla@nvidia.com>
[maz: rewritten commit message]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1603711447-11998-2-git-send-email-sashukla@nvidia.com
---
arch/arm64/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index e431d2d8e368..c7c6df6309d5 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -851,6 +851,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (kvm_is_device_pfn(pfn)) {
device = true;
+ force_pte = true;
} else if (logging_active && !write_fault) {
/*
* Only actually map the page as writable if this was a write
--
2.28.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: David Brazdil <dbrazdil@google.com>,
Gavin Shan <gshan@redhat.com>, James Morse <james.morse@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Qais Yousef <qais.yousef@arm.com>,
Quentin Perret <qperret@google.com>,
Santosh Shukla <sashukla@nvidia.com>,
Vladimir Murzin <vladimir.murzin@arm.com>,
Will Deacon <will@kernel.org>,
Julien Thierry <julien.thierry.kdev@gmail.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
stable@vger.kernel.org
Subject: [PATCH 08/12] KVM: arm64: Force PTE mapping on fault resulting in a device mapping
Date: Fri, 30 Oct 2020 16:40:13 +0000 [thread overview]
Message-ID: <20201030164017.244287-9-maz@kernel.org> (raw)
In-Reply-To: <20201030164017.244287-1-maz@kernel.org>
From: Santosh Shukla <sashukla@nvidia.com>
VFIO allows a device driver to resolve a fault by mapping a MMIO
range. This can be subsequently result in user_mem_abort() to
try and compute a huge mapping based on the MMIO pfn, which is
a sure recipe for things to go wrong.
Instead, force a PTE mapping when the pfn faulted in has a device
mapping.
Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings")
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Santosh Shukla <sashukla@nvidia.com>
[maz: rewritten commit message]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/1603711447-11998-2-git-send-email-sashukla@nvidia.com
---
arch/arm64/kvm/mmu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index e431d2d8e368..c7c6df6309d5 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -851,6 +851,7 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
if (kvm_is_device_pfn(pfn)) {
device = true;
+ force_pte = true;
} else if (logging_active && !write_fault) {
/*
* Only actually map the page as writable if this was a write
--
2.28.0
next prev parent reply other threads:[~2020-10-30 16:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-30 16:40 [GIT PULL] KVM/arm64 fixes for 5.10, take #1 Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 01/12] KVM: arm64: Don't corrupt tpidr_el2 on failed HVC call Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 02/12] KVM: arm64: Remove leftover kern_hyp_va() in nVHE TLB invalidation Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 03/12] KVM: arm64: Drop useless PAN setting on host EL1 to EL2 transition Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 04/12] KVM: arm64: Allocate stage-2 pgd pages with GFP_KERNEL_ACCOUNT Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 05/12] KVM: arm64: Fix AArch32 handling of DBGD{CCINT, SCRext} and DBGVCR Marc Zyngier
2020-10-30 16:40 ` [PATCH 05/12] KVM: arm64: Fix AArch32 handling of DBGD{CCINT,SCRext} " Marc Zyngier
2020-10-30 16:40 ` [PATCH 05/12] KVM: arm64: Fix AArch32 handling of DBGD{CCINT, SCRext} " Marc Zyngier
2020-10-30 16:40 ` [PATCH 06/12] KVM: arm64: Fix masks in stage2_pte_cacheable() Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 07/12] KVM: arm64: Use fallback mapping sizes for contiguous huge page sizes Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier [this message]
2020-10-30 16:40 ` [PATCH 08/12] KVM: arm64: Force PTE mapping on fault resulting in a device mapping Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 09/12] KVM: arm64: Factor out is_{vhe,nvhe}_hyp_code() Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 10/12] arm64: cpufeature: reorder cpus_have_{const, final}_cap() Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 11/12] arm64: cpufeature: upgrade hyp caps to final Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` [PATCH 12/12] KVM: arm64: Handle Asymmetric AArch32 systems Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-30 16:40 ` Marc Zyngier
2020-10-31 14:35 ` [GIT PULL] KVM/arm64 fixes for 5.10, take #1 Paolo Bonzini
2020-10-31 14:35 ` Paolo Bonzini
2020-10-31 14:35 ` Paolo Bonzini
[not found] <20201030163422.243844-1-maz@kernel.org>
2020-10-30 16:34 ` [PATCH 08/12] KVM: arm64: Force PTE mapping on fault resulting in a device mapping Marc Zyngier
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=20201030164017.244287-9-maz@kernel.org \
--to=maz@kernel.org \
--cc=kernel-team@android.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=pbonzini@redhat.com \
--cc=qais.yousef@arm.com \
--cc=stable@vger.kernel.org \
--cc=will@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.