netdev - Re: [net PATCH] flow_dissector: Fix unaligned access in __skb_flow_dissector when used by eth_get

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:	Sat, 30 Jan 2016 17:13:35 -0800
From:	Alexander Duyck <alexander.duyck@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Sowmini Varadhan <sowmini.varadhan@...cle.com>,
	Alexander Duyck <aduyck@...antis.com>,
	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Tom Herbert <tom@...bertland.com>
Subject: Re: [net PATCH] flow_dissector: Fix unaligned access in
 __skb_flow_dissector when used by eth_get_headlen

On Sat, Jan 30, 2016 at 11:26 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> On Sat, 2016-01-30 at 10:36 -0800, Alexander Duyck wrote:
>
>> As far as the NET_IP_ALIGN on the page offset I think it is a horrible
>> idea.  Basically it means we have to allocate at least 1K more space
>> than we need since page sizes are powers of 2, and buffer sizes in
>> hardware are measured in 1K increments.
>
> I thought Ethernet frames were something like ~1500 bytes.

It is, but if jumbo frames are enabled or LRO is enabled the NIC will
generate larger frames.

> Can't you program the NIC to not receive frames bigger than MTU + 18, or
> at least 2046 ?

Yes and no.  The NIC will already block frames larger than a fixed
size, but there are features like LRO that will let the NIC assemble a
larger frame.

> Of course, if the NIC is able to push 2048 bytes (instead of 2046 max),
> using an offset of 2 is not going to work.

The NIC hardware only allows us to set receive buffer sizes in 1K
increments.  I think fm10k may be an exception in that it may be able
to support 512 byte, but otherwise igb and ixgbe are strictly set in
1K increments.  So basically if we did the NET_IP_ALIGN of the page we
are limited to 1K buffers if we were to retain the current page reuse,
or we could go up to 3K if we were to allocate order 1 pages for
receive buffers as currently occurs with FCoE.

I would really prefer to keep the pages DMA aligned, and the skb->data
IP aligned.  If nothing else it has the advantage of actually having
the proper alignment on all the headers if I only pull the outer
headers and leave the inner headers in the page.. :-/

- Alex