Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure
Hi Alexei, On Tue, Feb 20, 2018 at 06:01:39PM -0800, Alexei Starovoitov wrote: > On Tue, Feb 20, 2018 at 11:53:55AM +0100, Pablo Neira Ayuso wrote: > > > > I'll explore how to generate eBPF code in the next patchset version. > > from the user space please... OK, let's do that, from user space I see two things we can do to integrate with eBPF: 1) Add a bpf chain type, that we can use to allow to attach eBPF programs, it would look similar to tc cls_bpf. We mentioned this idea in the past, it can open up existing netfilter hooks for custom eBPF programs. 2) Use the usermode helper infrastructure that bpfilter PoC is proposing to transparently pass the nft netlink batch to userspace for eBPF jit. This would allow us to convert the datapath to eBPF. Regarding the usermode helper, just an idea, not sure your plans but it's probably interesting to explore some sort of messaging-based communication between kernel and the eBPF userspace infrastructure. But that can be done later on, I understand all this is a PoC. Thanks!
Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure
On Tue, Feb 20, 2018 at 11:53:55AM +0100, Pablo Neira Ayuso wrote: > Hi David, > > On Mon, Feb 19, 2018 at 01:53:34PM -0500, David Miller wrote: > > I'm very suprised that this is generating classical BPF filters. > > > > We have native eBPF and that is what anything generating new code > > should be using, rather than the 20+ year old CBPF. > > I'm not the only one that likes 90s interfaces after all ;-) > > I'll explore how to generate eBPF code in the next patchset version. from the user space please... it was already explained few times in this thread and in other threads (kprobe, seccomp, etc related) over the last years why it's not ok to generate eBPF from the kernel.
Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure
Hi David, On Mon, Feb 19, 2018 at 01:53:34PM -0500, David Miller wrote: > I'm very suprised that this is generating classical BPF filters. > > We have native eBPF and that is what anything generating new code > should be using, rather than the 20+ year old CBPF. I'm not the only one that likes 90s interfaces after all ;-) I'll explore how to generate eBPF code in the next patchset version. Thanks!
Re: [PATCH RFC 3/3] netfilter: nf_tables: add BPF-based jit infrastructure
From: Pablo Neira Ayuso Date: Mon, 19 Feb 2018 17:37:06 +0100 > From nf_tables_newrule(), this calls nft_jit_rule() that transforms > our internal expression structure layout to abstract syntax tree, then > we walk over this syntax tree to generate the BPF instructions that are > placed in the rule jit buffer. From the commit phase, collect all jit > buffers, place them in a BPF program that gets attached to the chain. > > This should be good enough to test simple payload and meta match. For > more sophisticated stuff, we may use internal bpf helpers to call our > _eval() functions. > > Signed-off-by: Pablo Neira Ayuso I'm very suprised that this is generating classical BPF filters. We have native eBPF and that is what anything generating new code should be using, rather than the 20+ year old CBPF. Furthermore, we should not ever generate and use bpf code snippets to use directly in the kernel. Instead, all BPF code should be given to the kernel from userspace through the bpf syscall interface, so that the boundry is distinct and the verifier can be run properly on all pieces of eBPF code before the kernel uses it.
