[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On 24.06.2020 14:47, Julien Grall wrote:
> Hi,
> 
> On 24/06/2020 13:08, Jan Beulich wrote:
>> 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. 
> 
> It is not clear to me the sort of generic wrapping you are referring to. 
> Are you referring to a stable interface for an application?
> 
>> Makes me wonder whether, for this purpose, there should
>> be (have been) a new dmop with identical functionality, to
>> allow such funneling.
> 
> I am not sure how using DMOP will allow us to implement it fully in 
> userspace. Do you mind expanding it?

dmop was designed so that a kernel proxying requests wouldn't need
updating for every new request added to the interface. If the
request here was made through a new dmop, the kernel would never
have had a need to know of an interface structure that's of no
interest to it, but only to the tool stack.

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.