On Wed, Aug 31, 2022 at 05:35:08PM +0200, Florian Westphal wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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. OK, you don't have to select such an ugly long name ;) But I get your point: users need to declare explicitly the object. > > 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. You can also perform updates on the object without the need for reloading your ruleset. And the declared object also allows for more attributes to be added on it moving forward. I think this approach would also allow you to maintain symmetry between what you add and what it is shown in the listing?