netdev - Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc8cef7d-7b5a-d72a-9c31-5890fdac68c6@01019freenet.de>
Date:   Mon, 27 Nov 2017 17:46:14 +0100
From:   Andreas Hartmann <andihartmann@...19freenet.de>
To:     netdev@...r.kernel.org
Cc:     john.fastabend@...il.com
Subject: Re: Linux 4.14 - regression: broken tun/tap / bridge network with
 virtio - bisected

On 11/26/2017 at 03:17 PM Andreas Hartmann wrote:
> Hello!
> 
> Since Linux 4.14 (running as host), the virtual network based on bridge
> and tun/tap-devices is partly broken. Linux 4.13.x or earlier works
> perfectly.
> 
> 
> Given is the following architecture on host:
> 
> VM1 -> tun/tap -> br1
> VM2 -> tun/tap -> br0 / br1
> VM3 -> tun/tap -> br0
> 
> Example network configuration of the VMs:
> 
>     <interface type='bridge'>
>       <mac address='...'/>
>       <source bridge='br0'/>
>       <model type='virtio'/>
>     </interface>
> 
> 
> Host is connected through br1.
> 
> 
> VM2 is the router between two different networks provided by br1 and br0.
> 
> VM3 can be reached by the host via ssh through the router.
> There are some more VMs in the network provided by br0 - e.g. VM4.
> 
> Mostly all VMs are Centos 7 / 64bit (Linux 3.10.x) VMs provided by
> kvm_amd. VM1 uses Linux 4.4.x.
> 
> 
> Now, VM1 sends a UDP IPv4 package (it's the first radius message from
> hostapd during initialization of a EAP-TLS handshake with a WLAN client
> - Access Request) to VM3. This package is answered by VM3 (Access
> Challenge) and received by VM1.
> 
> Next, VM1 sends the second Access Request. I'm not sure, if this package
> is still received by VM3 or not. But this is sure: VM1 never gets any
> answer and the connection to VM3 is now *completely dead*. It isn't even
> possible to reach VM3 by ssh any more.
> 
> There aren't any log messages - neither on the host, nor on the VM.
> Other VMs aren't affected.
> 
> 
> Bisecting the problem leads to this patch:
> 
> 2ddf71e23cc246e95af72a6deed67b4a50a7b81c
> net: add notifier hooks for devmap bpf map
> 
> 
> It turns out, that the problem can be worked around by using e1000 as VM
> interface instead of virtio for VM1 and 3:
> 
>     <interface type='bridge'>
>       <mac address='52:54:00:15:ac:42'/>
>       <source bridge='br0'/>
>       <!-- <model type='virtio'/> -->
>       <model type='e1000'/>
>     </interface>
> 
> 
> Would it be possible to fix this problem to get it working again with
> virtio? Do you need some more information? Feel free to ask!

Some additional information:

Using virtio not just breaks the network completely as described above,
it even leaves a never stoppable or restartable qemu process (even kill
-9 doesn't work). It's absolutely necessary to *force* a reboot to exit
or restart the VM.

I switched back to linux 4.13 as 4.14 virtualization is quite unusable.

I'm not the only one affected:
https://bugzilla.kernel.org/show_bug.cgi?id=197861


Thanks,
Andreas