On 21/11/2018 13:21, Andrew Cooper wrote:
> This covers various fixes related to XSA-277 which weren't in security
> supported areas, and associated cleanup.
>
> The biggest issue noticed here is that altp2m's use of hardware #VE support
> will cause general memory corruption if the guest ever balloons out the VEINFO
> page. The only safe way I think of doing this is for Xen to alloc annonymous
> domheap pages for the VEINFO, and for the guest to map them in a similar way
> to the shared info and grant table frames.
>
> Andrew Cooper (14):
> x86/soft-reset: Drop gfn reference after calling get_gfn_query()
> x86/mem-sharing: Don't leave the altp2m lock held when nominating a page
> AMD/IOMMU: Fix multiple reference counting errors
> x86/p2m: Fix locking in p2m_altp2m_lazy_copy()
> x86/p2m: Don't overwrite p2m_altp2m_lazy_copy()'s callers p2m pointer
> x86/hvm: Make the altp2m locking easier to follow
> x86/p2m: Coding style cleanup
> xen/memory: Drop ARM put_gfn() stub
> x86/p2m: Switch the two_gfns infrastructure to using gfn_t
> x86/mm: Switch {get,put}_gfn() infrastructure to using gfn_t
> xen/mm: Switch mfn_to_virt()/virt_to_mfn() to using mfn_t
> xen/gnttab: Drop gnttab_create_{shared,status}_page()
> xen/gnttab: Simplify gnttab_map_frame()
> xen/gnttab: Minor improvements to arch header files
A number of these patches are still pending maintainer review.
The p2m patches all need George as the MM maintainer. The AMD/IOMMU
patch is all unreachable code, but needs AMD input. The final patch
needs ARM input.
Given that these are mostly reviewed and non-controversial, it would be
nice to get them into 4.12, so I guess at this point I could also do
with a release ack.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
