[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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.