netdev - Re: [PATCH net-next v14 14/15] p4tc: add set of P4TC table kfuncs

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]

Message-ID: <db5fa77e-c179-d90c-f4f5-1f39a5a0f56d@iogearbox.net>
Date: Fri, 5 Apr 2024 17:51:48 +0200
From: Daniel Borkmann <daniel@...earbox.net>
To: Jamal Hadi Salim <jhs@...atatu.com>,
 Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Network Development <netdev@...r.kernel.org>, deb.chatterjee@...el.com,
 Anjali Singhai Jain <anjali.singhai@...el.com>, namrata.limaye@...el.com,
 tom@...anda.io, Marcelo Ricardo Leitner <mleitner@...hat.com>,
 Mahesh.Shirshyad@....com, Vipin.Jain@....com, tomasz.osinski@...el.com,
 Jiri Pirko <jiri@...nulli.us>, Cong Wang <xiyou.wangcong@...il.com>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Vlad Buslov <vladbu@...dia.com>, Simon Horman <horms@...nel.org>,
 khalidm@...dia.com, Toke Høiland-Jørgensen
 <toke@...hat.com>, Martin KaFai Lau <martin.lau@...ux.dev>,
 victor@...atatu.com, Pedro Tammela <pctammela@...atatu.com>,
 bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH net-next v14 14/15] p4tc: add set of P4TC table kfuncs

On 4/5/24 1:16 AM, Jamal Hadi Salim wrote:
> On Thu, Apr 4, 2024 at 7:05 PM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
>> On Thu, Apr 4, 2024 at 3:59 PM Jamal Hadi Salim <jhs@...atatu.com> wrote:
>>>
>>> We will use ebpf/xdp/kfuncs whenever they make sense to us.
>>
>> In such case my Nack stands even if you drop this patch.
> 
> We are not changing any ebpf code. I must have missed the memo that
> stated you can control how people write or use ebpf.
> The situation is this: Anybody can write kfuncs today. They can put
> them in kernel modules - i am sure you designed it with that intent.
> So what exactly are you objecting to that is ebpf related here?

To be honest, this entire patchset is questionable from a design pov for
the many reasons stated by various folks (including tc co-maintainers) in
all the earlier discussions, but related to the BPF bits if someone else
were trying to propose an interface on kfuncs which replicate to a larger
extend BPF map APIs, the feedback would be similarly in that this should
be attempted to generalize instead so that this is useful as a building
block, esp given the goal is on SW datapath and not offloads, and the
context specific pieces would reside in the p4tc code.