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: Fri, 9 Oct 2020 14:07:44 -0700 From: Alexei Starovoitov <alexei.starovoitov@...il.com> To: John Fastabend <john.fastabend@...il.com> Cc: Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <brouer@...hat.com>, bpf@...r.kernel.org, netdev@...r.kernel.org, Daniel Borkmann <borkmann@...earbox.net>, maze@...gle.com, lmb@...udflare.com, shaun@...era.io, Lorenzo Bianconi <lorenzo@...nel.org>, marek@...udflare.com, eyal.birger@...il.com Subject: Re: [PATCH bpf-next V3 0/6] bpf: New approach for BPF MTU handling On Fri, Oct 09, 2020 at 01:49:14PM -0700, John Fastabend wrote: > Jakub Kicinski wrote: > > On Thu, 08 Oct 2020 16:08:57 +0200 Jesper Dangaard Brouer wrote: > > > V3: Drop enforcement of MTU in net-core, leave it to drivers > > > > Sorry for being late to the discussion. > > > > I absolutely disagree. We had cases in the past where HW would lock up > > if it was sent a frame with bad geometry. > > > > We will not be sprinkling validation checks across the drivers because > > some reconfiguration path may occasionally yield a bad packet, or it's > > hard to do something right with BPF. > > This is a driver bug then. As it stands today drivers may get hit with > skb with MTU greater than set MTU as best I can tell. Generally I > expect drivers use MTU to configure RX buffers not sure how it is going > to be used on TX side? Any examples? I just poked around through the > driver source to see and seems to confirm its primarily for RX side > configuration with some drivers throwing the event down to the firmware > for something that I can't see in the code? > > I'm not suggestiong sprinkling validation checks across the drivers. > I'm suggesting if the drivers hang we fix them. +1 I've seen HW that hangs when certain sizes of the packet. Like < 68 byte TX where size is one specific constant. I don't think it's a job of the stack or the driver to deal with that. It's firmware/hw bug.
Powered by blists - more mailing lists