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:	Thu, 05 Nov 2015 13:56:34 +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 12:38 PM, Eric Dumazet wrote:
> On Thu, 2015-11-05 at 10:39 +0100, Daniel Borkmann wrote:
>> On 11/05/2015 10:07 AM, Arnd Bergmann wrote:
>>> On Thursday 05 November 2015 00:04:14 David Miller wrote:
>>>> As part of fixing y2038 problems, Arnd is going to have to make a new
>>>> version fo the AF_PACKET mmap() tpacker descriptors in order to extend
>>>> the time values to 64-bit.
>>>>
>>>> So I want everyone to think about whether there are any other changes
>>>> we might want to make given that we have to make a v4 anyways.
>>>>
>>>> Particularly, I am rather certain that the buffer management could be
>>>> improved.  Some have complained that v3 is kinda awkward to use and/or
>>>> suboptimal is various ways.
>>>
>>> I have taken a closer look at the actual timestamp data now, and noticed
>>> that we use __u32 for both tp_sec and ts_sec in the user visible data.
>>> This means that once we fix the internal implementation to use 64-bit
>>> timestamps, we actually won't overflow until 2106 because the 2038 overflow
>>> is only for signed 32-bit numbers as we have in 'struct timespec'.
>>>
>>> So the good news is that we can keep the existing v1 through v3 formats
>>> beyond 2038, but only as long as all user space that cares about the
>>> value also interprets it as unsigned.
>>
>> Right, I was just about to ask that. So we could just make a union in
>> AF_PACKET's UAPI for a single 64-bit variable (as in ktime_t) to fix that.
>
> 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)?
--
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