netdev - Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

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]

Date:	Thu, 9 Apr 2015 18:25:18 +0100
From:	Ian Jackson <Ian.Jackson@...citrix.com>
To:	Prashant Sreedharan <prashant@...adcom.com>,
	Michael Chan <mchan@...adcom.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	"Boris Ostrovsky" <boris.ostrovsky@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Thadeu Lima de Souza Cascardo <cascardo@...ux.vnet.ibm.com>,
	Vlad Yasevich <vyasevich@...il.com>,
	"Nithin Nayak Sujir" <nsujir@...adcom.com>,
	<xen-devel@...ts.xensource.com>, <netdev@...r.kernel.org>
Subject: Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

Ian Jackson writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]"):
> Prashant Sreedharan writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]"):
> > yes please do
> 
> I will do so.

I did this test:
 - Linux 3.14.21
 - baremetal
 - `iommu=soft swiotlb=force' as suggested by Konrad
 - no bridge
 - manually added arp entries on both ends
   between target box and a server on same network

The results are:

On the test box, `ping 10.80.248.135' and `ping -s 500 10.80.248.135'
generate apparently-good ICMP echo requests which the server replies
to, but they don't seem to be received.

I ran
  tcpdump -pvvs500 -lnieth0 \! ether dst cc:cc:cc:cc:cc:cc and \! \
  ether dst 00:00:00:00:00:00 and \! ether dst 00:00:cc:cc:cc:cc and \
  \! ether dst 00:00:00:00:cc:cc and \! ether dst cc:cc:00:00:00:00
on the test box while pinging it from the server (-s500 and the
default).  No relevant packets matched the tcpdump filter.

However, as time goes by more and more packets with apparently random
data in their address fields start turning up so I have to keep adding
more mac addresses to be filtered out.

root@...bug:~# ethtool -S eth0 | grep -v ': 0$'
NIC statistics:
     rx_octets: 8196868
     rx_ucast_packets: 633
     rx_mcast_packets: 1
     rx_bcast_packets: 123789
     tx_octets: 42854
     tx_ucast_packets: 9
     tx_mcast_packets: 8
     tx_bcast_packets: 603
root@...bug:~# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:13:72:14:c0:51  
          inet addr:10.80.249.102  Bcast:10.80.251.255
          Mask:255.255.252.0
          inet6 addr: fe80::213:72ff:fe14:c051/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:124774 errors:0 dropped:88921 overruns:0 frame:0
          TX packets:620 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8222158 (7.8 MiB)  TX bytes:42854 (41.8 KiB)
          Interrupt:17 

root@...bug:~#

It appears therefore that packets are being corrupted on the receive
path, and the kernel then drops them (as misaddressed).

I also tried under Xen (rather than with baremetal and Konrad's
iommu/swiotlb kernel options), but that seems to be a less effective
repro.  Under Xen, without the bridge, I got ~6-8% packet loss,
compared to ~25-30% with the bridge.  I didn't investigate that
configuration in detail.

Thanks,
Ian.
--
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