|
[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, On 26/11/2021 08:07, Jan Beulich wrote: On 25.11.2021 17:37, Julien Grall wrote: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 varyingDo you mean gnttab_get_frame_gfn()?No, I don't think so; I do mean gnttab_set_frame_gfn(). Its return value directs the caller to do (or not) certain things. Hmmm ok. I misundertood that comment then. Thanks for the clarification!
So looking at Oleksandr series, I think we should be able to have the Arm helper matching the x86 one. At which point, I could deal with this version for now. However... The naming of the function is now quite confusing. The more on x86...#define gnttab_get_frame_gfn(gt, st, idx) ({ \ Fair point. I don't expect Oleksandr's series to be committed long after yours. I don't have a better name so far. However, without any documentation this is very difficult to figure out what it is meant to do (I am not only referring to someone implementing it for another arch here).That may then also lead to overall simpler code, ideally with more suitable names (if the present ones are deemed unsuitable, which I'm not convinced of). Cheers, -- Julien Grall
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |