From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LL11k-0000B9-IY for qemu-devel@nongnu.org; Thu, 08 Jan 2009 14:58:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LL11i-0000A7-Gz for qemu-devel@nongnu.org; Thu, 08 Jan 2009 14:58:47 -0500 Received: from [199.232.76.173] (port=54480 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LL11i-00009x-CD for qemu-devel@nongnu.org; Thu, 08 Jan 2009 14:58:46 -0500 Received: from ik-out-1112.google.com ([66.249.90.177]:58377) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LL11h-0000xj-O3 for qemu-devel@nongnu.org; Thu, 08 Jan 2009 14:58:46 -0500 Received: by ik-out-1112.google.com with SMTP id b32so2027919ika.2 for ; Thu, 08 Jan 2009 11:58:44 -0800 (PST) Message-ID: <49665AE7.3000708@codemonkey.ws> Date: Thu, 08 Jan 2009 13:58:31 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] mark nic as trusted References: <20090107142626.GE3267@redhat.com> <4964D98B.6030404@codemonkey.ws> <20090107165050.GI3267@redhat.com> <4964EC2B.1080406@codemonkey.ws> <4964EC55.4000507@codemonkey.ws> <20090107184103.GA19406@redhat.com> <496501CD.8060202@codemonkey.ws> <20090107194633.GB19406@redhat.com> In-Reply-To: <20090107194633.GB19406@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Gleb Natapov wrote: > On Wed, Jan 07, 2009 at 01:26:05PM -0600, Anthony Liguori wrote: > >> Gleb Natapov wrote: >> >>> On Wed, Jan 07, 2009 at 11:54:29AM -0600, Anthony Liguori wrote: >>> >>> >>>> Anthony Liguori wrote: >>>> >>>> >>>>>> That is for secure guest<->host communication over network. Guest has to >>>>>> know somehow which link host uses for communication. If guest has no way >>>>>> to know this, another computer on untrusted network can pretend >>>>>> it is real >>>>>> host and "own" a guest. >>>>>> >>>>> So this is for vmchannel? How do you differentiate a real device >>>>> with that bit set compared to the vmchannel device? >>>>> >>>>> >>>> Like if you were doing PCI passthrough of an e1000... >>>> >>>> >>>> >>> It's not just one bit. It is 14 byte string. We can put something unique there. >>> >>> >> This is for vmchannel? Why not add a feature to virtio-net? >> >> > Yes. This is for vmchannel. Or any other management solution that work > over network. It has to know what network it can trust. The alternative > is much more complex (security certificates, etc). Why do it virtio-net > specific? What's wrong with more general solution? > Does Windows provide an API for determining "trustedness"? How is this exposed to userspace in Linux? The thinking behind virtio-net is that you may want to expose a different userspace interface in Windows than networking (maybe something more direct) since it may be impossible to get around the Windows firewalling nonsense. With virtio-net, you could have the Windows driver check the special "vmchannel" flag and present a different userspace interface than the traditional network driver. Although that's just a thought. Regards, Anthony Liguori > -- > Gleb. > > >