| Message ID | 20190719122545.3486-1-paul.durrant@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | include/public/memory.h: remove the XENMEM_rsrc_acq_caller_owned flag | expand |
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 <paul.durrant@citrix.com> 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 <andrew.cooper3@citrix.com>
On 19.07.2019 14:41, Andrew Cooper wrote: > 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 <paul.durrant@citrix.com> > > This is a modification to a public header, but in this specific case, I > think it is the correct thing to do. This is in a large "#if defined(__XEN__) || defined(__XEN_TOOLS__)" section, and we consider public interface parts in such sections volatile anyway. Jan
On 19/07/2019 14:31, Jan Beulich wrote: > On 19.07.2019 14:41, Andrew Cooper wrote: >> 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 <paul.durrant@citrix.com> >> This is a modification to a public header, but in this specific case, I >> think it is the correct thing to do. > This is in a large "#if defined(__XEN__) || defined(__XEN_TOOLS__)" section, > and we consider public interface parts in such sections volatile anyway. Oh - even better. I'd not spotted that. ~Andrew
On 19.07.2019 14: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 <paul.durrant@citrix.com> I notice this has now been committed, but I didn't see any further discussion, i.e. in particular it is unclear to me at this point if Bitdefender have found a different solution for their change using this flag. Jan
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c index 334571d445..58f463259f 100644 --- a/xen/arch/x86/mm.c +++ b/xen/arch/x86/mm.c @@ -4521,8 +4521,7 @@ int xenmem_add_to_physmap_one( int arch_acquire_resource(struct domain *d, unsigned int type, unsigned int id, unsigned long frame, - unsigned int nr_frames, xen_pfn_t mfn_list[], - unsigned int *flags) + unsigned int nr_frames, xen_pfn_t mfn_list[]) { int rc; diff --git a/xen/common/compat/memory.c b/xen/common/compat/memory.c index 2eb79efa65..10a954f281 100644 --- a/xen/common/compat/memory.c +++ b/xen/common/compat/memory.c @@ -624,12 +624,6 @@ int compat_memory_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) compat) compat_frame_list, cmp.mar.nr_frames) ) return -EFAULT; - - if ( __copy_field_to_guest( - guest_handle_cast(compat, - compat_mem_acquire_resource_t), - &cmp.mar, flags) ) - return -EFAULT; } break; diff --git a/xen/common/memory.c b/xen/common/memory.c index 30d210fc08..44a7b1d3a8 100644 --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -1060,7 +1060,7 @@ static int acquire_resource( if ( copy_from_guest(&xmar, arg, 1) ) return -EFAULT; - if ( xmar.flags != 0 ) + if ( xmar.pad != 0 ) return -EINVAL; if ( guest_handle_is_null(xmar.frame_list) ) @@ -1096,7 +1096,7 @@ static int acquire_resource( default: rc = arch_acquire_resource(d, xmar.type, xmar.id, xmar.frame, - xmar.nr_frames, mfn_list, &xmar.flags); + xmar.nr_frames, mfn_list); break; } @@ -1116,11 +1116,9 @@ static int acquire_resource( /* * FIXME: Until foreign pages inserted into the P2M are properly * reference counted, it is unsafe to allow mapping of - * non-caller-owned resource pages unless the caller is - * the hardware domain. + * resource pages unless the caller is the hardware domain. */ - if ( !(xmar.flags & XENMEM_rsrc_acq_caller_owned) && - !is_hardware_domain(currd) ) + if ( !is_hardware_domain(currd) ) return -EACCES; if ( copy_from_guest(gfn_list, xmar.frame_list, xmar.nr_frames) ) @@ -1136,10 +1134,6 @@ static int acquire_resource( } } - if ( xmar.flags != 0 && - __copy_field_to_guest(arg, &xmar, flags) ) - rc = -EFAULT; - out: rcu_unlock_domain(d); diff --git a/xen/include/asm-arm/mm.h b/xen/include/asm-arm/mm.h index 3dbc8a6469..9b9fb7e346 100644 --- a/xen/include/asm-arm/mm.h +++ b/xen/include/asm-arm/mm.h @@ -356,7 +356,7 @@ void clear_and_clean_page(struct page_info *page); static inline int arch_acquire_resource(struct domain *d, unsigned int type, unsigned int id, unsigned long frame, unsigned int nr_frames, - xen_pfn_t mfn_list[], unsigned int *flags) + xen_pfn_t mfn_list[]) { return -EOPNOTSUPP; } diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h index 6c14635270..cc6d733b27 100644 --- a/xen/include/asm-x86/mm.h +++ b/xen/include/asm-x86/mm.h @@ -634,7 +634,6 @@ static inline bool arch_mfn_in_directmap(unsigned long mfn) int arch_acquire_resource(struct domain *d, unsigned int type, unsigned int id, unsigned long frame, - unsigned int nr_frames, xen_pfn_t mfn_list[], - unsigned int *flags); + unsigned int nr_frames, xen_pfn_t mfn_list[]); #endif /* __ASM_X86_MM_H__ */ diff --git a/xen/include/public/memory.h b/xen/include/public/memory.h index 68ddadbea8..cfdda6e2a8 100644 --- a/xen/include/public/memory.h +++ b/xen/include/public/memory.h @@ -632,16 +632,7 @@ struct xen_mem_acquire_resource { * maximum value supported by the implementation on return. */ uint32_t nr_frames; - /* - * OUT - Must be zero on entry. On return this may contain a bitwise - * OR of the following values. - */ - uint32_t flags; - - /* The resource pages have been assigned to the calling domain */ -#define _XENMEM_rsrc_acq_caller_owned 0 -#define XENMEM_rsrc_acq_caller_owned (1u << _XENMEM_rsrc_acq_caller_owned) - + uint32_t pad; /* * IN - the index of the initial frame to be mapped. This parameter * is ignored if nr_frames is 0.
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 <paul.durrant@citrix.com> --- Cc: Andrew Cooper <andrew.cooper3@citrix.com> Cc: George Dunlap <George.Dunlap@eu.citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Jan Beulich <jbeulich@suse.com> Cc: Julien Grall <julien.grall@arm.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: Tim Deegan <tim@xen.org> Cc: Wei Liu <wl@xen.org> --- xen/arch/x86/mm.c | 3 +-- xen/common/compat/memory.c | 6 ------ xen/common/memory.c | 14 ++++---------- xen/include/asm-arm/mm.h | 2 +- xen/include/asm-x86/mm.h | 3 +-- xen/include/public/memory.h | 11 +---------- 6 files changed, 8 insertions(+), 31 deletions(-)