>>> On 17.03.16 at 17:15, <andrew.coop...@citrix.com> wrote: > On 17/03/16 15:32, Jan Beulich wrote: >>>>> On 17.03.16 at 15:44, <andrew.coop...@citrix.com> wrote: >>> On 17/03/16 14:31, Jan Beulich wrote: >>>> Also - do we really want to make this code dependent on >>>> map_pages_to_xen() not intermediately zapping the mappings >>>> being changed? >>> Do you mean "immediately"? >> No. >> >>> As far as I can tell, it is guaranteed to be safe, even when remapping >>> the code section. Updates to the live pagetables are using atomic >>> writes, and I didn't spot a point which would end up with a transient >>> non-present mapping. >> But we may, at some point and for whatever reason, come to make >> the function zap the mapping (i.e. clear the present bit), flush, and >> only the re-establish the new mapping. > > This change is temporary until I can fix the legacy boot issue and > reintroduce the proper 2M functionality. > > If someone in the future wants to change the behaviour of > map_pages_to_xen() then we can reconsider. However, I think it is > unlikely that this will actually happen at all, and if it ever does, I > hope to have already fixed the 2M alignment and deleted this change. > > This change is a big security improvement, and absolutely should be > taken, especially as the current implementation of map_pages_to_xen() is > safe.
I by no means intend to reject this change just because of this aspect - I merely wanted to make the slight concern explicit. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel