Re: [Qemu-devel] [PATCH] mark nic as trusted

[Gleb Natapov <gleb@redhat.com>]

On Thu, Jan 08, 2009 at 01:58:31PM -0600, Anthony Liguori wrote:
> 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?
>
Windows and Linux allows access to PCI space, so it is easy to check 
"trustedness". AFAIK we already have Windows code to do that. In Linux
it can be done even by shell script by examining files in /sys.

> 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.
>
Then we will have to implement some kind of reliable protocol on top
of that. It can be done, but it make sense to reuse TCP for that. We
will have to request proper firewall config from VM admin though. It
is possible to dial with build in Windows firewall automatically, but
third party firewalls may require admin intervention.

--
			Gleb.