[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] x86/mm: mod_l<N>_entry() have no need to use __copy_from_user()
On 20.12.2019 15:54, George Dunlap wrote: > On 12/20/19 2:52 PM, Jan Beulich wrote: >> On 20.12.2019 15:47, George Dunlap wrote: >>> On 12/20/19 2:42 PM, Andrew Cooper wrote: >>>> On 20/12/2019 14:19, Jan Beulich wrote: >>>>> mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86: >>>>> Fold page_info lock into type_info"), and the other three never had such >>>>> a need, at least going back as far as 3.2.0. >>>>> >>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> >>>> >>>> These presumably want ACCESS_ONCE() to avoid introducing repeated read >>>> vulnerabilities? While the mappings might be safe, they still point to >>>> live guest data. >>> >>> The L1 itself should be mapped read-only by the guest, and locked at >>> this point, no? >> >> True, but I think it won't hurt to use ACCESS_ONCE() nevertheless >> - it makes the code more obviously safe independent of any locking >> knowledge. > > But that might give someone the idea that that it *was* safe to do the > type adjustments without the page being locked, which it certainly isn't. It isn't in the common case, but we couldn't, for example, put in ASSERT()s in place of using ACCESS_ONCE(), as new_guest_cr3()'s use of mod_l4_entry() is without lock, yet still safe (because of acting on the otherwise immutable L4 table of a 32-bit guest). FAOD this code path also doesn't need the ACCESS_ONCE() (for the same reason). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |