[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220831153508.GB15107@breakpoint.cc>
Date: Wed, 31 Aug 2022 17:35:08 +0200
From: Florian Westphal <fw@...len.de>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: Toke Høiland-Jørgensen <toke@...nel.org>,
Florian Westphal <fw@...len.de>,
netfilter-devel@...r.kernel.org, bpf@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH nf-next] netfilter: nf_tables: add ebpf expression
Pablo Neira Ayuso <pablo@...filter.org> wrote:
> > asking the kernel to store an additional label with the program rule?
>
> @Florian, could you probably use the object infrastructure to refer to
> the program?
Yes, I would like to extend objref infra later once this is accepted.
> This might also allow you to refer to this new object type from
> nf_tables maps.
Yes, but first nft needs to be able to construct some meaningful output
again. If we don't attach a specific label (such as filename), we need
to be able to reconstruct info based on what we can query via id/tag and
bpf syscall.
objref infra doesn't help here unless we'll force something like
'nft-defined-objref-name-must-match-elf-binary-name', and I find that
terrible.
> It would be good to avoid linear rule-based matching to select what
> program to run.
Hmmm, I did not consider it a huge deal, its an ebpf program so
users can dispatch to another program.
Objref is nice if the program to run should be selected from a criterion that isn't
readily available to a sk_filter program though.
Powered by blists - more mailing lists