linux-kernel - Re: problems with e1000 and jumboframes

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, 3 Aug 2006 08:57:36 -0700
From:	"Chris Leech" <chris.leech@...il.com>
To:	"Evgeniy Polyakov" <johnpol@....mipt.ru>
Cc:	"Krzysztof Oledzki" <olel@....pl>,
	"Arnd Hannemann" <arnd@...dnet.de>, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: problems with e1000 and jumboframes

On 8/3/06, Evgeniy Polyakov <johnpol@....mipt.ru> wrote:

> > Strange, why this skb_shared_info cannon be added before first alignment?
> > And what about smaller frames like 1500, does this driver behave similar
> > (first align then add)?
>
> It can be.
> Could attached  (completely untested) patch help?

Note that e1000 uses power of two buffers because that's what the
hardware supports.  Also, there's no program able MTU - only a single
bit for "long packet enable" that disables frame length checks when
using jumbo frames.  That means that if you tell the e1000 it has a
16k buffer, and a 16k frame shows up on the wire, it's going to write
to the entire 16k regardless of your 9k MTU setting.  If a 32k frame
shows up, two full 16k buffers get written to (OK, assuming the frame
can fit into the receive FIFO)

That's why I've always been against trying to optimize the allocation
sizes in the driver, even with your small change the skb_shinfo area
can get corrupted.  It may be unlikely, because the frame still has to
be valid, but some switches aren't real picky about what sized frame
they'll forward on if you enable jumbo support either.  So any box on
the LAN could send you larger than MTU frames in an attempt to corrupt
memory.

I believe that if you tell a hardware device it has a buffer of a
certain size, you need to be prepared for that entire buffer to get
written to.  Unfortunately that means wasteful allocations for e1000
if a single buffer per frame is going to be used.

- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/