From: Wen Congyang <wency@cn.fujitsu.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Jiang Yunhong <yunhong.jiang@intel.com>,
Dong Eddie <eddie.dong@intel.com>,
xen devel <xen-devel@lists.xen.org>,
Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [RFC Patch v4 5/9] check if mfn is supported by IOCTL_PRIVCMD_MMAPBATCH before calling ioctl()
Date: Tue, 23 Sep 2014 09:40:36 +0800 [thread overview]
Message-ID: <5420CF94.8000109@cn.fujitsu.com> (raw)
In-Reply-To: <1411395965.14971.9.camel@kazak.uk.xensource.com>
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@cn.fujitsu.com>
>> ---
>> 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:
>
>
> .
>
next prev parent reply other threads:[~2014-09-23 1:40 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-22 5:59 [RFC Patch v4 0/9] Some bugfix patches Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 1/9] copy the correct page to memory Wen Congyang
2014-09-22 14:38 ` Ian Campbell
2014-09-22 5:59 ` [RFC Patch v4 2/9] csum the correct page Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 3/9] pass correct file to qemu if we use blktap2 Wen Congyang
2014-12-11 16:45 ` George Dunlap
2014-12-13 17:06 ` Wei Liu
2014-12-15 10:18 ` Ian Campbell
2014-12-15 11:10 ` George Dunlap
2014-09-22 5:59 ` [RFC Patch v4 4/9] read nictype from xenstore Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 5/9] check if mfn is supported by IOCTL_PRIVCMD_MMAPBATCH before calling ioctl() Wen Congyang
2014-09-22 14:26 ` Ian Campbell
2014-09-23 1:40 ` Wen Congyang [this message]
2014-09-23 10:08 ` Ian Campbell
2014-09-24 1:36 ` Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 6/9] don't zero out ioreq page and handle the pended I/O after resuming Wen Congyang
2014-09-22 11:22 ` Jan Beulich
2014-09-22 5:59 ` [RFC Patch v4 7/9] correct xc_domain_save()'s return value Wen Congyang
2014-09-22 7:30 ` Olaf Hering
2014-09-22 7:34 ` Wen Congyang
2014-09-22 7:46 ` Olaf Hering
2014-09-22 8:06 ` Wen Congyang
2014-09-22 8:13 ` Olaf Hering
2014-09-22 8:24 ` Wen Congyang
2014-09-22 8:41 ` Wen Congyang
2014-09-22 12:42 ` Ian Campbell
2014-09-22 13:03 ` Ian Jackson
2014-09-22 13:13 ` Ian Campbell
2014-09-22 13:57 ` [PATCH RFC 0/3] " Ian Jackson
2014-09-22 13:58 ` Ian Campbell
2014-09-22 14:00 ` Ian Campbell
2014-09-22 13:58 ` [PATCH 1/3] libxl: save helper: remove redundant declaration Ian Jackson
2014-09-22 13:58 ` [PATCH 2/3] libxl: save helper: transport errno with all callback return values Ian Jackson
2014-09-22 13:58 ` [PATCH 3/3] libxl: save/restore callbacks: enforce a useful errno value Ian Jackson
2014-09-22 14:07 ` Ian Campbell
2014-09-22 14:08 ` Ian Jackson
2014-09-22 14:06 ` [RFC Patch v4 7/9] correct xc_domain_save()'s return value Andrew Cooper
2014-09-23 2:14 ` Wen Congyang
2014-09-23 9:00 ` Andrew Cooper
2014-09-23 9:10 ` Wen Congyang
2014-09-23 9:25 ` Andrew Cooper
2014-09-23 9:29 ` Wen Congyang
2014-09-23 10:09 ` Ian Campbell
2014-09-23 9:52 ` Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 8/9] store correct format into tapdisk-params/params Wen Congyang
2014-09-22 14:37 ` Ian Campbell
2014-09-23 2:07 ` Wen Congyang
2014-09-23 10:11 ` Ian Campbell
2014-09-23 10:32 ` Wen Congyang
2014-09-22 5:59 ` [RFC Patch v4 9/9] update libxl__device_disk_from_xs_be() to support blktap device Wen Congyang
2014-09-22 15:08 ` Ian Campbell
2014-09-23 3:07 ` Wen Congyang
2014-09-23 10:12 ` Ian Campbell
2014-09-22 12:44 ` [RFC Patch v4 0/9] Some bugfix patches Ian Campbell
2014-09-22 12:56 ` Wen Congyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5420CF94.8000109@cn.fujitsu.com \
--to=wency@cn.fujitsu.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=eddie.dong@intel.com \
--cc=laijs@cn.fujitsu.com \
--cc=xen-devel@lists.xen.org \
--cc=yanghy@cn.fujitsu.com \
--cc=yunhong.jiang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).