A 4K page appears to be able to hold 128 ioreq entries, which luckly matches the current vCPU limit. However, if we decide to increase the domain vCPU limit, that doesn't hold anymore and this function would now silently create a out of bounds pointer leading to confusing problems.
All architectures with ioreq support don't support 128 vCPU limit for HVM guests, and have pages that are at least 4 KB large, so this case doesn't occurs in with the current limits. For the time being, make sure we can't make a Xen build that can accidentally make a out of bounds pointers here. No functional change. Reported-by: Julian Vetter <[email protected]> Signed-off-by: Teddy Astie <[email protected]> --- v3: - make it a BUILD_BUG_ON instead (compile-time check) v2: - check and report instead of ASSERT and eventually crash offending domain xen/common/ioreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c index f5fd30ce12..7a0421cc07 100644 --- a/xen/common/ioreq.c +++ b/xen/common/ioreq.c @@ -99,6 +99,7 @@ static ioreq_t *get_ioreq(struct ioreq_server *s, struct vcpu *v) ASSERT((v == current) || !vcpu_runnable(v)); ASSERT(p != NULL); + BUILD_BUG_ON(HVM_MAX_VCPUS > (PAGE_SIZE / sizeof(struct ioreq))); return &p->vcpu_ioreq[v->vcpu_id]; } -- 2.51.2 -- Teddy Astie | Vates XCP-ng Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech
