xen/arm: p2m: Avoid off-by-one check on p2m->max_mapped_gfn
authorJulien Grall <julien.grall@arm.com>
Tue, 15 Oct 2019 16:10:41 +0000 (17:10 +0100)
committerJan Beulich <jbeulich@suse.com>
Thu, 31 Oct 2019 15:18:38 +0000 (16:18 +0100)
commit6e8e163b46d0823526f1afbbe6f66c668fc811d1
tree5a7ac53c9f350fe43f005159aa4442064ee25afe
parent88aaf40eeff771c546ad3bbb02000171648a89f7
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>
xen/arch/arm/p2m.c
xen/include/asm-arm/p2m.h