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
| ||
|
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
Powered by blists - more mailing lists