[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 12.01.16 at 13:07, <stefano.stabellini@xxxxxxxxxxxxx> wrote:
> 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.

That's again a layering violation (bypassing the L1 hypervisor).

Jan


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


 


Rackspace

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