Re: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 09/02/17 16:03, Jan Beulich wrote:
>>>> On 09.02.17 at 16:56, <andrew.cooper3@citrix.com> wrote:
>> On 09/02/17 15:50, Boris Ostrovsky wrote:
>>>
>>> On 02/09/2017 09:27 AM, Paul Durrant wrote:
>>>>> -----Original Message-----
>>>>> From: Paul Durrant [mailto:paul.durrant@citrix.com]
>>>>> Sent: 09 February 2017 14:18
>>>>> To: xen-devel@lists.xenproject.org; linux-kernel@vger.kernel.org 
>>>>> Cc: Paul Durrant <Paul.Durrant@citrix.com>; Boris Ostrovsky
>>>>> <boris.ostrovsky@oracle.com>; Juergen Gross <jgross@suse.com>
>>>>> Subject: [PATCH 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>>>>>
>>>>> Recently a new dm_op[1] hypercall was added to Xen to provide a
>>>>> mechanism
>>>>> for restricting device emulators (such as QEMU) to a limited set of
>>>>> hypervisor operations, and being able to audit those operations in the
>>>>> kernel of the domain in which they run.
>>>>>
>>>>> This patch adds IOCTL_PRIVCMD_DM_OP as gateway for
>>>>> __HYPERVISOR_dm_op,
>>>>> bouncing the callers buffers through kernel memory to allow the address
>>>>> ranges to be audited (and negating the need to bounce through locked
>>>>> memory in user-space).
>>>> Actually, it strikes me (now that I've posted the patch) that I
>>>> should probably just mlock the user buffers rather than bouncing them
>>>> through kernel... Anyway, I'd still appreciate review on other
>>>> aspects of the patch.
>>>
>>> Are you suggesting that the caller (user) mlocks the buffers?
>> Doesn't libxc already use the hypercall buffer API for each of the buffers?
>>
>> The kernel oughtn’t to need to do anything special to the user pointers
>> it has, other than call access_ok() on them.
> And translate 32-bit layout to 64-bit for a compat caller.

Ah yes (although that looks to be done suitably in the patch as presented).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel