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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.06.2020 14:53, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@xxxxxxxx>
>> Sent: 24 June 2020 13:52
>> To: Julien Grall <julien@xxxxxxx>
>> Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; 
>> paul@xxxxxxx; Andrew
>> Cooper <andrew.cooper3@xxxxxxxxxx>; George Dunlap 
>> <george.dunlap@xxxxxxxxxx>; Ian Jackson
>> <ian.jackson@xxxxxxxxxxxxx>; Stefano Stabellini <sstabellini@xxxxxxxxxx>; 
>> Wei Liu <wl@xxxxxxx>
>> Subject: 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.
> 
> How would the pages get mapped into process address space if the
> kernel doesn't know what's being done?

Urgh, yes, silly me.

Jan