mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 10:11:27 +01:00
Konrad Rzeszutek Wilk
b10bca0483
Said hypercall for large BARs can take quite a while. As such we can require that the hypercall MUST break up the request in smaller values. Another approach is to add preemption to it - whether we do the preemption using hypercall_create_continuation or returning EAGAIN to userspace (and have it re-invocate the call) - either way the issue we cannot easily solve is that in 'map_mmio_regions' if we encounter an error we MUST call 'unmap_mmio_regions' for the whole BAR region. Since the preemption would re-use input fields such as nr_mfns, first_gfn, first_mfn - we would lose the original values - and only undo what was done in the current round (i.e. ignoring anything that was done prior to earlier preemptions). Unless we re-used the return value as 'EAGAIN|nr_mfns_done<<10' but that puts a limit (since the return value is a long) on the amount of nr_mfns that can provided. This patch sidesteps this problem by: - Setting an hard limit of nr_mfns having to be 64 or less. - Toolstack adjusts correspondingly to the nr_mfn limit. - If the there is an error when adding the toolstack will call the remove operation to remove the whole region. The need to break this hypercall down is for large BARs can take more than the guest (initial domain usually) time-slice. This has the negative result in that the guest is locked out for a long duration and is unable to act on any pending events. We also augment the code to return zero if nr_mfns instead of trying to the hypercall. This is XSA-125 / CVE-2015-2752. Suggested-by: Jan Beulich <jbeulich@suse.com> Acked-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>