|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/2] gnttab: remove guest_physmap_remove_page() call from gnttab_map_frame()
Hi Jan, Sorry for the delay. I was waiting for XSA-387 to go out before answering. On 13/09/2021 07:41, Jan Beulich wrote: Without holding appropriate locks, attempting to remove a prior mapping of the underlying page is pointless, as the same (or another) mapping could be re-established by a parallel request on another vCPU. Move the code to Arm's gnttab_set_frame_gfn(). Of course this new placement doesn't improve things in any way as far as the security of grant status frame mappings goes (see XSA-379). Proper locking would be needed here to allow status frames to be mapped securely. In turn this then requires replacing the other use in gnttab_unpopulate_status_frames(), which yet in turn requires adjusting x86's gnttab_set_frame_gfn(). Note that with proper locking inside guest_physmap_remove_page() combined with checking the GFN's mapping there against the passed in MFN, there then is no issue with the involved multiple gnttab_set_frame_gfn()-s potentially returning varying Do you mean gnttab_get_frame_gfn()?
I think using a function would make it a bit easier to understand what it does. However... The naming of the function is now quite confusing. The more on x86... #define gnttab_get_frame_gfn(gt, st, idx) ({ \ ... it will end up to remove the mapping. I don't have a better name at the moment. However I think this would deserve some documentation in the code so one can understand how to implement it for another arch. Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |