[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86/hvm: Allow the guest to permit the use of userspace hypercalls
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |