Re: [PATCH for-4.14] mm: fix public declaration of struct xen_mem_acquire_resource

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.06.2020 12:52, Julien Grall wrote:
> Hi Jan,
> 
> On 24/06/2020 11:05, Jan Beulich wrote:
>> On 23.06.2020 19:32, Roger Pau Monné wrote:
>>> On Tue, Jun 23, 2020 at 05:04:53PM +0200, Jan Beulich wrote:
>>>> On 23.06.2020 15:52, Roger Pau Monne wrote:
>>>>> XENMEM_acquire_resource and it's related structure is currently inside
>>>>> a __XEN__ or __XEN_TOOLS__ guarded section to limit it's scope to the
>>>>> hypervisor or the toolstack only. This is wrong as the hypercall is
>>>>> already being used by the Linux kernel at least, and as such needs to
>>>>> be public.
>>>>
>>>> Actually - how does this work for the Linux kernel, seeing
>>>>
>>>>      rc = rcu_lock_remote_domain_by_id(xmar.domid, &d);
>>>>      if ( rc )
>>>>          return rc;
>>>>
>>>>      rc = xsm_domain_resource_map(XSM_DM_PRIV, d);
>>>>      if ( rc )
>>>>          goto out;
>>>>
>>>> in the function?
>>>
>>> It's my understanding (I haven't tried to use that hypercall yet on
>>> FreeBSD, so I cannot say I've tested it), that xmar.domid is the
>>> remote domain, which the functions locks and then uses
>>> xsm_domain_resource_map to check whether the current domain has
>>> permissions to do privileged operations against it.
>>
>> Yes, but that's a tool stack operation, not something the kernel
>> would do all by itself. The kernel would only ever pass DOMID_SELF
>> (or the actual local domain ID), I would think.
> 
> You can't issue that hypercall directly from userspace because you need 
> to map the page in the physical address space of the toolstack domain.
> 
> So the kernel has to act as the proxy for the hypercall. This is 
> implemented as mmap() in Linux.

Oh, and there's no generic wrapping available here, unlike for
dmop. Makes me wonder whether, for this purpose, there should
be (have been) a new dmop with identical functionality, to
allow such funneling.

Janan