WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Paging and memory sharing for HVM guests

>>> "Jan Beulich" <JBeulich@xxxxxxxxxx> 04.01.10 17:30 >>>
>>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 04.01.10 16:32 >>>
>>On 04/01/2010 14:14, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>
>>> Isn't this undermining the purpose of privcmd_enforce_singleshot_mapping()?
>>> You don't check that the eventual single page re-mapping attempt is
>>> really due to an earlier -ENOENT failure, and hence the whole single
>>> shot mapping checks are now pointless (though other than possibly to
>>> enforce some minimal security I don't really know what its purpose
>>> is/was - Keir?).
>>
>>It was just to avoid the BUG_ON(!pte_none(*pte)) in
>>direct_remap_area_pte_fn(). We trust privcmd users enough we could just get
>>rid of privcmd_enforce_singleshot_mapping(). We could instead forcibly clear
>>ptes before calling direct_remap_area(); or just do nothing.
>
>I'm of the opinion that even privileged users shouldn't be able to oops
>the kernel, and hence hitting the BUG_ON() you're mentioning should
>be avoided. Clearing the old mappings seems like a reasonable thing
>to do.

Actually, after some more thinking about this it seems to me that the
best approach would probably be a per-page single shot mechanism.
This could simply be done through apply_to_page_range(), checking
for pte_none() in the callback. The old mechanism could be removed
then.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>