On 19/07/2019 13:25, Paul Durrant wrote: > When commit 3f8f1228 "x86/mm: add HYPERVISOR_memory_op to acquire guest > resources" introduced the concept of directly mapping some guest resources, > it was envisaged that the memory for some resources associated with a guest > may not actually be assigned to that guest, specifically the IOREQ server > resource introduces in commit 6e387461 "x86/hvm/ioreq: add a new mappable > resource type...". Such resources were dubbed "caller owned" and resulted > in the owned resources" and acquiring them resulted in the > XENMEM_rsrc_acq_caller_owned flag being passed back to the caller of the > memory op. > > Unfortunately the implementation led to XSA-276, which was mitigated > by commit f6b6ae78 "x86/hvm/ioreq: fix page referencing" and then a related > memory accounting problem was worked around by commit e862e6ce > "x86/hvm/ioreq: use ref-counted target-assigned shared pages". This latter > commit removed the only instance of a "caller owned" resource, but the > flag was left in header and checked in one place in the core code. > This patch removes that now redundant check and removes the definition of > XENMEM_rsrc_acq_caller_owned from the public header. Also, since this was > the only flag defined for the XENMEM_acquire_resource memory op, it removes > the 'flags' field of struct xen_mem_acquire_resource and replaces it with > an equivalently sized 'pad' field. > > Signed-off-by: Paul Durrant <[email protected]>
This is a modification to a public header, but in this specific case, I think it is the correct thing to do. XENMEM_rsrc_acq_caller_owned is totally unsafe to use. The only people who are going to be impacted by this change are those who haven't yet fixed XSA-276 and have an unstable system anyway, at which point, the build breakage is arguably doing them a favour. Acked-by: Andrew Cooper <[email protected]> _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
