Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 11 Jan 2016, David Vrabel wrote:
> On 11/01/16 17:17, Andrew Cooper wrote:
> > So from one point of view, sufficient justification for this change is
> > "because the Linux way isn't the only valid way to do this".
> 
> "Because we can" isn't a good justification for adding something new.
> Particularly something that is trivially easy to (accidentally) misuse
> and open a big security hole between userspace and kernel.
> 
> The vague idea for a userspace netfront that's floating around
> internally is also not a good reason for pushing this feature at this time.

I agree with David, but I might have another good use case for this.

Consider the following scenario: we have a Xen HVM guest, with Xen
installed inside of it (nested virtualization). I'll refer to Xen
running on the host as L0 Xen and Xen running inside the VM as L1 Xen.
Similarly we have two dom0 running, the one with access to the physical
hardware, L0 Dom0, and the one running inside the VM, L1 Dom0.

Let's suppose that we want to lay the groundwork for L1 Dom0 to use PV
frontend drivers, netfront and blkfront to speed up execution. In order
to do that, the first thing it needs to do is making an hypercall to L0
Xen. That's because netfront and blkfront needs to communicate with
netback and blkback in L0 Dom0: event channels and grant tables are the
ones provided by L0 Xen.

However L0 Xen refuses hypercalls from ring 3, and L1 Dom0 is running in
ring 3 so unfortunately it cannot actually do it.

With this hypercall in place, it is conceivable for L1 Dom0 to instruct
L1 Xen to make a HVMOP_set_hypercall_dpl call and allow L1 Dom0 to setup
netfront and blkfront with L0 Xen.

Fun, isn't it.

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