| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home