netdev - Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

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:	Mon, 04 Apr 2016 09:37:47 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Lorenzo Colitti <lorenzo@...gle.com>,
	Tom Herbert <tom@...bertland.com>
Cc:	Brenden Blanco <bblanco@...mgrid.com>,
	"David S. Miller" <davem@...emloft.net>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	gerlitz@...lanox.com, Daniel Borkmann <daniel@...earbox.net>,
	john fastabend <john.fastabend@...il.com>,
	Jesper Dangaard Brouer <brouer@...hat.com>
Subject: Re: [RFC PATCH 0/5] Add driver bpf hook for early packet drop

On Sun, 2016-04-03 at 11:28 +0900, Lorenzo Colitti wrote:

> That said, getting BPF to the driver is part of the picture. On the
> chipsets we're targeting for APF, we're only seeing 2k-4k of memory
> (that's 256-512 BPF instructions) available for filtering code, which
> means that BPF might be too large.

That's true, but I think that as far as the userspace API is concerned
that shouldn't really be an issue. I think we can compile the BPF into
APF, similar to how BPF can be compiled into machine code today.
Additionally, I'm not sure we can realistically expect all devices to
really implement APF "natively", I think there's a good chance but
there's also a possibility of compiling to the native firmware
environment, for example.

johannes