|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC Patch v4 5/9] check if mfn is supported by IOCTL_PRIVCMD_MMAPBATCH before calling ioctl()
On 09/22/2014 10:26 PM, Ian Campbell wrote:
> On Mon, 2014-09-22 at 13:59 +0800, Wen Congyang wrote:
>> If mfn is invalid, ioctl(fd, IOCTL_PRIVCMD_MMAPBATCH, ..) also returns 0,
>> and set error information in error bits(bits28-31). So if the user input
>> a large valid mfn, we cannot reliably distinguish between a large MFN and
>> an error. So we should check the input mfn before calling ioctl().
>> The user can input more than one mfn, and part of them are ~0UL. In this
>> case, the user expects we can map the memory for all valid mfn. So we
>> cannot just return NULL if some mfn is not supported.
>
> I don't follow this last bit. linux_privcmd_map_foreign_bulk already
> returns NULL and maps nothing in some error cases (e.g. mmap failure),
> what is the problem also doing that here?
Yes, if mmap fails, linux_privcmd_map_foreign_bulk() returns NULL.
But some mfn is invalid, ioctl() returns 0, and then
linux_privcmd_map_foreign_bulk()
doesn't return NULL.
For example:
page0, page1, ... page m, page m+1, ... page n
mfn 0, mfn 1, ... mfn m, mfn m+1, ... mfn n
If only mfn m is invalid, the user can access page 0, page 1, page m+1.
The user can know which page can't be accessed by the array err[].
If some mfn is valid, but it is large, and IOCTL_PRIVCMD_MMAPBATCH doesn't
support it. The user doesn't know the page can't be accessed, and will
cause page fault(the user program may segment fault) when the user accesses the
page.
>
> The way you have it here we need to worry about what the behaviour of
> Xen/privcmd is on pfn==~0UL, and whether we can rely on it. Far better
> to just declare such attempts to be fundamentally broken on the part of
> the caller and return.
In the function apply_batch():
/* setup region_mfn[] for batch map, if necessary.
* For HVM guests, this interface takes PFNs, not MFNs */
if ( pagetype == XEN_DOMCTL_PFINFO_XTAB
|| pagetype == XEN_DOMCTL_PFINFO_XALLOC )
region_mfn[i] = ~0UL; /* map will fail but we don't care */
else
region_mfn[i] = ctx->hvm ? pfn : ctx->p2m[pfn];
It is why I choose ~0UL. I don't know how to check if the mfn is valid,
and we should allow the caller passes ~0UL, otherwise, it will break
migration.
Thanks
Wen Congyang
>
> Ian.
>
>> Signed-off-by: Wen Congyang <wency@xxxxxxxxxxxxxx>
>> ---
>> tools/libxc/xc_linux_osdep.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/tools/libxc/xc_linux_osdep.c b/tools/libxc/xc_linux_osdep.c
>> index a19e4b6..d11bcee 100644
>> --- a/tools/libxc/xc_linux_osdep.c
>> +++ b/tools/libxc/xc_linux_osdep.c
>> @@ -321,6 +321,18 @@ static void
>> *linux_privcmd_map_foreign_bulk(xc_interface *xch, xc_osdep_handle h
>> }
>>
>> memcpy(pfn, arr, num * sizeof(*arr));
>> + for ( i = 0; i < num; i++ )
>> + {
>> + /*
>> + * IOCTL_PRIVCMD_MMAPBATCH doesn't support the mfn which
>> + * error bits are set
>> + */
>> + if ( pfn[i] & PRIVCMD_MMAPBATCH_MFN_ERROR )
>> + {
>> + pfn[i] = ~0UL;
>> + err[i] = -EINVAL;
>> + }
>> + }
>>
>> ioctlx.num = num;
>> ioctlx.dom = dom;
>> @@ -333,6 +345,9 @@ static void *linux_privcmd_map_foreign_bulk(xc_interface
>> *xch, xc_osdep_handle h
>>
>> for ( i = 0; i < num; ++i )
>> {
>> + if ( pfn[i] == ~0UL )
>> + continue;
>> +
>> switch ( pfn[i] ^ arr[i] )
>> {
>> case 0:
>
>
> .
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |