netdev - Re: Guest 8021q VLAN tags and macvtap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <53C70C94.6050507@redhat.com>
Date:	Wed, 16 Jul 2014 19:36:52 -0400
From:	Vlad Yasevich <vyasevic@...hat.com>
To:	Matthew Rosato <mjrosato@...ux.vnet.ibm.com>,
	netdev@...r.kernel.org
Subject: Re: Guest 8021q VLAN tags and macvtap

On 07/16/2014 04:15 PM, Matthew Rosato wrote:
> Prior to commit 6acf54f1cf (macvtap: Add support of packet capture on
> macvtap device), I was able to setup an environment where qemu guests
> connected via macvtaps (eg, guest eth0 --> host macvtap0 --> host eth0)
> could configure guest 8021q tagging and communicate with each other over
> the vlan, with the guests being responsible for tagging/untagging. I
> accomplished this by configuring the desired vlan id on both the guest
> interface (guest eth0.123) as well as by adding the vlan to the
> underlying host macvtap (macvtap0.123).  Configuring the id on the
> macvtap was done to allow the tagged packets to get past the lowerdev.
> 
> Now, post 6acf54f1cf, guest-tagged traffic never arrives on the target
> guest (untagged traffic is fine).  I did some tracing as a tagged packet
> comes in on the target host, summarized:
> 
> 1) __netif_receive_skb calls untag_vlan, vlan_tci is stashed,
> vlan_do_receive returns false
> 2) rx_handler (macvlan_handle_frame) is called
> 3) netif_rx_ni is called, skb queued/dequeued (pass to macvtap)
> 4) __netif_receive_skb called again - vlan_do_receive is called
> successfully, causing us to lose our stashed vlan_tci
> 5) rx_handler (macvtap_handle_frame) is called
> 
> My understanding is that macvtap expects packets to get untagged, and
> intends to re-tag them later at macvtap_put_user.  But, because the
> macvtap is vlan-enabled, the stashed vlan_tci is always gone because of
> vlan_do_receive.
> 
> I think it boils down to the old macvtap_receive/forward logic not
> calling vlan_do_receive, but now we do since we're using netif.  Was my
> configuration wrong in the first place, or is this a bug?
> 
> FWIW, I hacked __netif_receive_skb to skip the vlan_do_receive call for
> IFF_MACVLAN, and sure enough that restores my expected behavior, but
> I'm not sure if that's the right solution.

No, that's not the right solution.  The reason you are seeing loss of
vlan_tci is due to the existance of macvtap0.123 (the host side vlan
device).  If you remove that device, guest-guest comms will work,
but guest-remote will stop

Getting the tagged packets received at the lower dev is the issue.
You could unload vlan module and that should restore guest-remote
communications.
You could setting promisc mode on the lower dev, but that's not a nice
solution.

I need to thing about more about how better solve this.

Thanks
-vlad


> 
> Thanks,
> Matt
> 

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html