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

[Jamie Lokier]

Dor Laor wrote:
> The installer of the guest agent is responsible for punching a hole in the
> firewall.

That's asking a lot from a generic installer.  Guests differ
enormously in how you do that - including different Linux guests.

Something else you have to do is disable forwarding between the
vmchannel NIC and other NICs - even if the other NICs are forwarding
enabled to each other.  How do you do that on Linux?
/proc/sys/net/ipv4/ip_forward is global, not per NIC...  How do you do
it on other guests?

It's easy to imagine a few simple guest agents written in C that
compile easily on any guest unix you might want to run on... except
this vmchannel setup would be the only non-portable part, and highly
non-portable at that.

>                - Link local addresses for ipv4 are problematic when
>           using on other
>           nics in parallel
>      Likewise, the guest could check the address situation beforehand.
> It does check (meaning we need to fully implement the link local rfc).
> The problem is that even if we check that no one is using this guest local
> link address, another nic can use link local addresses. So a remote host on
> the LAN of the other nic might chose the same address we are using.

No, that's not enough.  Even when you have globally unique link-local
addresses, you have the problem that NICs configured for link-local IP
always have the same subnet, so routing doesn't work.

You could workaround this by using non-standard link-local IP on the
vmchannel NIC.  Now you're playing more games...

>                   - We should either 1. not use link local on other
>           links 2. Use
>           standard dhcp addresses 3. do
>                      not use tcp/ip for vmchannel communication.
> 
>            So additional nic can do the job and we have several
>           flavours to choose
>           from.
>      The solution should be generic enough so that any nic can be
>      connected
>      to vmchannel.

It sounds "generic" in the sense that you need a custom configuration
which depends on the rest of the guest's configuration.  Not really
"drop in guest vmchannel app and it just works", is it?

If the guest vmchannel app installer looks at other NICs, and picks an
IP subnet that the others aren't using, or uses link-local when that's
not used on the others...  That will work most of the time.  But
sometimes it will break a working guest some hours after it's
installed.  What happens if the guests's LAN NIC is using DHCP, so the
vmchannel app picks link-local - and then the guests's LAN NIC changes
to link-local itself after some hours running?  That's not uncommon
behaviour nowadays on some networks.

Handling all the cases _reliably_, adapting reactively to network
config _changes_ on the other NICs while running, and doing so across
many guest types (even just Linux distros and Windows) without having
to have custom code for each guest type, is harder than it looks.

On the other hand, using packet sockets and not IP over the vmchannel
NIC... (just pick another ethernet type) that would work reliably, but
without the convenience of TCP/IP.  It would need more support in the
guest vmchannel app, and guest root access, but both sound plausible
to implement.

-- Jamie