netdev - Re: BUG:af_packet fails to TX TSO frames

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, 12 Oct 2017 15:12:52 +0100
From:   Anton Ivanov <anton.ivanov@...bridgegreys.com>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc:     Network Development <netdev@...r.kernel.org>
Subject: Re: BUG:af_packet fails to TX TSO frames

On 10/12/17 14:39, Willem de Bruijn wrote:
>> If I produce a real vnet frame out of a live kernel frame using
>> virtio_net_hdr_from_skb() and try to send it it fails on the check in
>> af_packet, while succeeding for tap. If I remove the af_packet check the
>> frame is accepted by the hardware too.
>>
>> If I produce it a synthetic frame + vnet header using the test program - it
>> works. Go figure.
> Besides looking at the raw frame bytes, also compare the setup
> of virtio_net_header, as well as the tcp checksum field. The stack
> expects the pseudo header to have already been calculated.

I am feeding it a skb which is coming up in the tx routine of a User 
Mode Linux device which is marked as NETIF_F_HW_CSUM and SG - that 
results in a skb with csum-ed headers, body set up for CSUM_PARTIAL and 
multiple fragments (always at least 1 more frag besides the TCP head).

That has everything in order as expected by virtio_net_hdr_from_skb and 
this is what I use to generate the vnet header. It works correctly for 
csum and GRO with af_packet and it works correctly for everything using 
a tap device. It fails only on GSO + af_packet TX.

What I am doing is the same thing virtio_net does - it just takes the 
output of virtio_net_hdr_from_skb and does nothing more. There should be 
no need to do anything more :(

It should just work.

Unless there is a gremlin somewhere in the machinery and that gremlin 
needs some light to be flushed out.
>
>> I am going to continue digging into it.
>>
>> At the very least I now have a positive test case which uses the same
>> semantics as my code so I have something to compare to.
> Glad to hear that the test is helpful. I wrote it because I
> have run into these exact same issues in the past.

It is. I have changes ready for it so it also supports vector IO, need 
to finish fighting with it.

A.

>

-- 
Anton R. Ivanov

Cambridge Greys Limited, England and Wales company No 10273661
http://www.cambridgegreys.com/