]> xenbits.xensource.com Git - xen.git/commit
xen/arm: p2m: Avoid off-by-one check on p2m->max_mapped_gfn
authorJulien Grall <julien.grall@arm.com>
Thu, 31 Oct 2019 16:13:59 +0000 (17:13 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 31 Oct 2019 16:13:59 +0000 (17:13 +0100)
commit952f362d4a685cbe7b528517e553106ec0735f73
tree65d7e5560990ff87bfbb76383c7a6a899144a131
parent7c3c7d8bdb9a2d7dbb08b081bdd9cdd12db6605a
xen/arm: p2m: Avoid off-by-one check on p2m->max_mapped_gfn

The code base is using inconsistently the field p2m->max_mapped_gfn.
Some of the useres expect that p2m->max_guest_gfn contain the highest
mapped GFN while others expect highest + 1.

p2m->max_guest_gfn is set as highest + 1, because of that the sanity
check on the GFN in p2m_resolved_translation_fault() and
p2m_get_entry() can be bypassed when GFN == p2m->max_guest_gfn.

p2m_get_root_pointer(p2m->max_guest_gfn) may return NULL if it is
outside of address range supported and therefore the BUG_ON() could be
hit.

The current value hold in p2m->max_mapped_gfn is inconsistent with the
expectation of the common code (see domain_get_maximum_gpfn()) and also
the documentation of the field.

Rather than changing the check in p2m_translation_fault() and
p2m_get_entry(), p2m->max_mapped_gfn is now containing the highest
mapped GFN and the callers assuming "highest + 1" are now adjusted.

Take the opportunity to use 1UL rather than 1 as page_order could
theoritically big enough to overflow a 32-bit integer.

Lastly, the documentation of the field max_guest_gfn to reflect how it
is computed.

This is part of XSA-301.

Reported-by: Julien Grall <Julien.Grall@arm.com>
Signed-off-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
master commit: 6e8e163b46d0823526f1afbbe6f66c668fc811d1
master date: 2019-10-31 16:18:38 +0100
xen/arch/arm/p2m.c
xen/include/asm-arm/p2m.h