[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



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.

Cheers,

--
Julien Grall



 


Rackspace

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