diff mbox series

[stable,6.1.y,1/2] KVM: arm64: Prevent the donation of no-map pages

Message ID 20230920192729.694309-1-surajjs@amazon.com (mailing list archive)
State New, archived
Headers show
Series [stable,6.1.y,1/2] KVM: arm64: Prevent the donation of no-map pages | expand

Commit Message

Jitindar Singh, Suraj Sept. 20, 2023, 7:27 p.m. UTC 
From: Quentin Perret <qperret@google.com>

commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream.

Memory regions marked as "no-map" in the host device-tree routinely
include TrustZone carev-outs and DMA pools. Although donating such pages
to the hypervisor may not breach confidentiality, it could be used to
corrupt its state in uncontrollable ways. To prevent this, let's block
host-initiated memory transitions targeting "no-map" pages altogether in
nVHE protected mode as there should be no valid reason to do this in
current operation.

Thankfully, the pKVM EL2 hypervisor has a full copy of the host's list
of memblock regions, so we can easily check for the presence of the
MEMBLOCK_NOMAP flag on a region containing pages being donated from the
host.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Vincent Donnefort <vdonnefort@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org
[ bp: clean ]
Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
---
 arch/arm64/kvm/hyp/nvhe/mem_protect.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

Comments

Marc Zyngier Sept. 21, 2023, 7:13 a.m. UTC | #1 
On Wed, 20 Sep 2023 20:27:28 +0100,
Suraj Jitindar Singh <surajjs@amazon.com> wrote:
> 
> From: Quentin Perret <qperret@google.com>
> 
> commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream.
> 
> Memory regions marked as "no-map" in the host device-tree routinely
> include TrustZone carev-outs and DMA pools. Although donating such pages
> to the hypervisor may not breach confidentiality, it could be used to
> corrupt its state in uncontrollable ways. To prevent this, let's block
> host-initiated memory transitions targeting "no-map" pages altogether in
> nVHE protected mode as there should be no valid reason to do this in
> current operation.
> 
> Thankfully, the pKVM EL2 hypervisor has a full copy of the host's list
> of memblock regions, so we can easily check for the presence of the
> MEMBLOCK_NOMAP flag on a region containing pages being donated from the
> host.
> 
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Tested-by: Vincent Donnefort <vdonnefort@google.com>
> Signed-off-by: Quentin Perret <qperret@google.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> Link: https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org
> [ bp: clean ]

What is this?

> Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>

What is the rationale for backporting this? It wasn't tagged as Cc: to
stable for a reason: pKVM isn't functional upstream, and won't be for
the next couple of cycles *at least*.

So at it stands, I'm against such a backport.

Thanks,

	M.
Jitindar Singh, Suraj Sept. 21, 2023, 10:22 p.m. UTC | #2 
On Thu, 2023-09-21 at 08:13 +0100, Marc Zyngier wrote:
> On Wed, 20 Sep 2023 20:27:28 +0100,
> Suraj Jitindar Singh <surajjs@amazon.com> wrote:
> > 
> > From: Quentin Perret <qperret@google.com>
> > 
> > commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream.
> > 
> > Memory regions marked as "no-map" in the host device-tree routinely
> > include TrustZone carev-outs and DMA pools. Although donating such
> > pages
> > to the hypervisor may not breach confidentiality, it could be used
> > to
> > corrupt its state in uncontrollable ways. To prevent this, let's
> > block
> > host-initiated memory transitions targeting "no-map" pages
> > altogether in
> > nVHE protected mode as there should be no valid reason to do this
> > in
> > current operation.
> > 
> > Thankfully, the pKVM EL2 hypervisor has a full copy of the host's
> > list
> > of memblock regions, so we can easily check for the presence of the
> > MEMBLOCK_NOMAP flag on a region containing pages being donated from
> > the
> > host.
> > 
> > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > Tested-by: Vincent Donnefort <vdonnefort@google.com>
> > Signed-off-by: Quentin Perret <qperret@google.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > Link:
> > https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org
> > [ bp: clean ]
> 
> What is this?

Noting any details about the backport. In this case it was a clean
backport.

> 
> > Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
> 
> What is the rationale for backporting this? It wasn't tagged as Cc:
> to
> stable for a reason: pKVM isn't functional upstream, and won't be for
> the next couple of cycles *at least*.
> 
> So at it stands, I'm against such a backport.
> 

The 2 patches were backported to address CVE-2023-21264.
This one provides context for the proceeding patch.

I wasn't aware that it's non functional. Does this mean that the code
won't be compiled or just that it can't actually be run currently from
the upstream codebase?

I guess I'm trying to understand if the conditions of the CVE are a
real concern even if it isn't technically functional.

Thanks

> Thanks,
> 
>         M.
>
Greg Kroah-Hartman Sept. 22, 2023, 9:25 a.m. UTC | #3 
On Thu, Sep 21, 2023 at 10:22:54PM +0000, Jitindar Singh, Suraj wrote:
> On Thu, 2023-09-21 at 08:13 +0100, Marc Zyngier wrote:
> > On Wed, 20 Sep 2023 20:27:28 +0100,
> > Suraj Jitindar Singh <surajjs@amazon.com> wrote:
> > > 
> > > From: Quentin Perret <qperret@google.com>
> > > 
> > > commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream.
> > > 
> > > Memory regions marked as "no-map" in the host device-tree routinely
> > > include TrustZone carev-outs and DMA pools. Although donating such
> > > pages
> > > to the hypervisor may not breach confidentiality, it could be used
> > > to
> > > corrupt its state in uncontrollable ways. To prevent this, let's
> > > block
> > > host-initiated memory transitions targeting "no-map" pages
> > > altogether in
> > > nVHE protected mode as there should be no valid reason to do this
> > > in
> > > current operation.
> > > 
> > > Thankfully, the pKVM EL2 hypervisor has a full copy of the host's
> > > list
> > > of memblock regions, so we can easily check for the presence of the
> > > MEMBLOCK_NOMAP flag on a region containing pages being donated from
> > > the
> > > host.
> > > 
> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > Tested-by: Vincent Donnefort <vdonnefort@google.com>
> > > Signed-off-by: Quentin Perret <qperret@google.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > Link:
> > > https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org
> > > [ bp: clean ]
> > 
> > What is this?
> 
> Noting any details about the backport. In this case it was a clean
> backport.
> 
> > 
> > > Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
> > 
> > What is the rationale for backporting this? It wasn't tagged as Cc:
> > to
> > stable for a reason: pKVM isn't functional upstream, and won't be for
> > the next couple of cycles *at least*.
> > 
> > So at it stands, I'm against such a backport.
> > 
> 
> The 2 patches were backported to address CVE-2023-21264.
> This one provides context for the proceeding patch.
> 
> I wasn't aware that it's non functional. Does this mean that the code
> won't be compiled or just that it can't actually be run currently from
> the upstream codebase?
> 
> I guess I'm trying to understand if the conditions of the CVE are a
> real concern even if it isn't technically functional.

Why do you think the CVE is actually even valid?  Who filed it and why?

Remember, CVEs almost never mean anything for the kernel, they are not
able to be given out by the kernel security team, and they just don't
make any sense for us.

I'll go drop these patches from the stable queues for now, and wait for
you all to agree what is happening here.

thanks,

greg k-h
Marc Zyngier Sept. 22, 2023, 10:08 a.m. UTC | #4 
On Thu, 21 Sep 2023 23:22:54 +0100,
"Jitindar Singh, Suraj" <surajjs@amazon.com> wrote:
> 
> On Thu, 2023-09-21 at 08:13 +0100, Marc Zyngier wrote:
> > On Wed, 20 Sep 2023 20:27:28 +0100,
> > Suraj Jitindar Singh <surajjs@amazon.com> wrote:
> > > 
> > > From: Quentin Perret <qperret@google.com>
> > > 
> > > commit 43c1ff8b75011bc3e3e923adf31ba815864a2494 upstream.
> > > 
> > > Memory regions marked as "no-map" in the host device-tree routinely
> > > include TrustZone carev-outs and DMA pools. Although donating such
> > > pages
> > > to the hypervisor may not breach confidentiality, it could be used
> > > to
> > > corrupt its state in uncontrollable ways. To prevent this, let's
> > > block
> > > host-initiated memory transitions targeting "no-map" pages
> > > altogether in
> > > nVHE protected mode as there should be no valid reason to do this
> > > in
> > > current operation.
> > > 
> > > Thankfully, the pKVM EL2 hypervisor has a full copy of the host's
> > > list
> > > of memblock regions, so we can easily check for the presence of the
> > > MEMBLOCK_NOMAP flag on a region containing pages being donated from
> > > the
> > > host.
> > > 
> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> > > Tested-by: Vincent Donnefort <vdonnefort@google.com>
> > > Signed-off-by: Quentin Perret <qperret@google.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > Link:
> > > https://lore.kernel.org/r/20221110190259.26861-8-will@kernel.org
> > > [ bp: clean ]
> > 
> > What is this?
> 
> Noting any details about the backport. In this case it was a clean
> backport.

I don't think this has anything to do here. If you want to add a note
indicating what was changed in the patch, make it *extremely* visible
in the commit message, and not hidden as some obscure form of
metadata.

> 
> > 
> > > Signed-off-by: Suraj Jitindar Singh <surajjs@amazon.com>
> > 
> > What is the rationale for backporting this? It wasn't tagged as Cc:
> > to
> > stable for a reason: pKVM isn't functional upstream, and won't be for
> > the next couple of cycles *at least*.
> > 
> > So at it stands, I'm against such a backport.
> > 
> 
> The 2 patches were backported to address CVE-2023-21264.
> This one provides context for the proceeding patch.

I care about CVEs as much as I care about holes in my socks (i.e. very
little). If there is a concern, it should be brought up on the list as
a discussion, and not as a consequence of some script kiddie
automatically generating CVEs.

> I wasn't aware that it's non functional. Does this mean that the code
> won't be compiled or just that it can't actually be run currently from
> the upstream codebase?

This code is inactive unless you pass the correct option on the
command line, and as it is brings zero benefit over standard KVM.  The
only place this matters is in the Android kernel, as it has full
support for pKVM, and has the fix already. We carry it upstream at a
courtesy to the pKVM developers, but that's about it.

> I guess I'm trying to understand if the conditions of the CVE are a
> real concern even if it isn't technically functional.

This CVE is a waste of precious bytes, and I have no interest in
seeing this backported.

Thanks,

	M.
diff mbox series

Patch

diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
index 07f9dc9848ef..0f6c053686c7 100644
--- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c
+++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c
@@ -195,7 +195,7 @@  struct kvm_mem_range {
 	u64 end;
 };
 
-static bool find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
+static struct memblock_region *find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
 {
 	int cur, left = 0, right = hyp_memblock_nr;
 	struct memblock_region *reg;
@@ -218,18 +218,28 @@  static bool find_mem_range(phys_addr_t addr, struct kvm_mem_range *range)
 		} else {
 			range->start = reg->base;
 			range->end = end;
-			return true;
+			return reg;
 		}
 	}
 
-	return false;
+	return NULL;
 }
 
 bool addr_is_memory(phys_addr_t phys)
 {
 	struct kvm_mem_range range;
 
-	return find_mem_range(phys, &range);
+	return !!find_mem_range(phys, &range);
+}
+
+static bool addr_is_allowed_memory(phys_addr_t phys)
+{
+	struct memblock_region *reg;
+	struct kvm_mem_range range;
+
+	reg = find_mem_range(phys, &range);
+
+	return reg && !(reg->flags & MEMBLOCK_NOMAP);
 }
 
 static bool is_in_mem_range(u64 addr, struct kvm_mem_range *range)
@@ -348,7 +358,7 @@  static bool host_stage2_force_pte_cb(u64 addr, u64 end, enum kvm_pgtable_prot pr
 static int host_stage2_idmap(u64 addr)
 {
 	struct kvm_mem_range range;
-	bool is_memory = find_mem_range(addr, &range);
+	bool is_memory = !!find_mem_range(addr, &range);
 	enum kvm_pgtable_prot prot;
 	int ret;
 
@@ -425,7 +435,7 @@  static int __check_page_state_visitor(u64 addr, u64 end, u32 level,
 	struct check_walk_data *d = arg;
 	kvm_pte_t pte = *ptep;
 
-	if (kvm_pte_valid(pte) && !addr_is_memory(kvm_pte_to_phys(pte)))
+	if (kvm_pte_valid(pte) && !addr_is_allowed_memory(kvm_pte_to_phys(pte)))
 		return -EINVAL;
 
 	return d->get_page_state(pte) == d->desired ? 0 : -EPERM;