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: <CAM0EoMn6Nyu5AKgSERZEtSojvzKN6r7enc7t313G9xBvq-bcog@mail.gmail.com>
Date: Thu, 4 Apr 2024 19:16:18 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: 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>, 
	Daniel Borkmann <daniel@...earbox.net>, 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 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?

cheers,
jamal