netdev - Re: AF_PACKET mmap() v4...

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:	Fri, 06 Nov 2015 12:34:45 +0100
From:	Daniel Borkmann <daniel@...earbox.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	Arnd Bergmann <arnd@...db.de>, David Miller <davem@...emloft.net>,
	netdev@...r.kernel.org, tklauser@...tanz.ch
Subject: Re: AF_PACKET mmap() v4...

On 11/05/2015 11:56 PM, Daniel Borkmann wrote:
> On 11/05/2015 05:17 PM, Eric Dumazet wrote:
>> On Thu, 2015-11-05 at 13:56 +0100, Daniel Borkmann wrote:
>>> On 11/05/2015 12:38 PM, Eric Dumazet wrote:
>>
>>>> If I am not mistaken, af_packet also lacks the ability to properly set
>>>> skb->protocol
>>>>
>>>> I noticed this using trafgen on a bonding device, when I did my SYNFLOOD
>>>> tests for TCP listener rewrite.
>>>>
>>>> The bonding hash function might uses flow dissector, but as this flow
>>>> dissection depends on skb->protocol, all the traffic is directed on a
>>>> single slave.
>>>
>>> Right, if I see this correctly, when you trigger the flushing of TX_RING
>>> via sendmsg(), one can hand over a sockaddr_ll, where we infer sll_protocol
>>> and tag every skb's skb->protocol with that in tpacket_fill_skb() for the
>>> current flushing run. Otherwise, we use the po->num specified at socket
>>> creation / bind time for everything (trafgen case).
>>>
>>> If needed on a per skb basis, perhaps we could map some tpacket_hdr{,2}
>>> member that is not used from TX_RING side (perhaps union on tp_snaplen)?
>>
>> If po->num is 0 (as in trafgen case), we could also get the proto from
>> Ethernet header provided by the user.
>>
>> The skb_probe_transport_header() call from tpacket_fill_skb() is useless
>> in the current kernel.
>>
>> Let say an application wants to mix IPv6 and IPv4 packets, using a
>> single TX ring....
>
> Sorry for the late answer.
>
> For the skb->protocol issue, perhaps something like this. Also noticed that
> we should rather do the vlan check when we have the actual linear data from
> the ring slot, the current way seems buggy if I see this correctly. Both
> patches squashed below.

Hmm, I believe there's another bug in TX_RING with SOCK_DGRAM, will do some
more experiments and post some patches later on.

Best,
Daniel
--
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