netdev - Re: [PATCH bpf-next v7 3/6] net/smc: Introduce generic hook smc

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250205080228.GA57822@j66a10360.sqa.eu95>
Date: Wed, 5 Feb 2025 16:02:28 +0800
From: "D. Wythe" <alibuda@...ux.alibaba.com    >
To: Gerd Bayer <gbayer@...ux.ibm.com>
Cc: dust.li@...ux.alibaba.com, "D. Wythe" <alibuda@...ux.alibaba.com>,
	kgraul@...ux.ibm.com, wenjia@...ux.ibm.com, jaka@...ux.ibm.com,
	ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
	martin.lau@...ux.dev, pabeni@...hat.com, song@...nel.org,
	sdf@...gle.com, haoluo@...gle.com, yhs@...com, edumazet@...gle.com,
	john.fastabend@...il.com, kpsingh@...nel.org, jolsa@...nel.org,
	guwen@...ux.alibaba.com, kuba@...nel.org, davem@...emloft.net,
	netdev@...r.kernel.org, linux-s390@...r.kernel.org,
	linux-rdma@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v7 3/6] net/smc: Introduce generic hook smc_ops

On Thu, Jan 23, 2025 at 11:15:21AM +0100, Gerd Bayer wrote:
> On Thu, 2025-01-23 at 15:30 +0800, Dust Li wrote:
> > On 2025-01-23 09:59:39, D. Wythe wrote:
> > > The introduction of IPPROTO_SMC enables eBPF programs to determine
> > > whether to use SMC based on the context of socket creation, such as
> > > network namespaces, PID and comm name, etc.
> > > 
> > 
> > I'm still not completely satisfied with the name smc_ops. Since this
> > will be the API for our users, we need to be carefull on the name.
> 
> If I may jump in with a suggestion here:
> On my first glance, I'd expect SMC_OPS to offer OPS as a general API.
> The description however suggest that this adds "contol points" or hooks
> in the SMC code, that eBPF programs can use to tweak the protocol's
> behavior. Exclusively eBPF programs, it seems.
> 
> So how about naming this SMC_EBPF_HOOKS or SMC_EBPF_SUPPORT?
> 
> Just my 2ct,
> Gerd

Hi all,

Thanks for all the suggestion.It seems that the naming of this ops has indeed
sparked some controversy. However, I still oppose explicitly linking the name
to BPF. As I mentioned earlier, this ops is not strongly tied to BPF
implementations, kernel modules can also implement them.

I used ChatGPT to generate some potential names, including:
smc_ops / smc_hook / smc_aug / smc_ext / smc_alert / smc_support

Perhaps these can be used as references.

However, in any case, these changes need to be acked by the SMC
maintainer, but for what I can tell, the maintainer of SMC is currently on
leave, so this discussion may still take some time.

Best wishes,
D. Wythe

> 
> > 
> > It seems like you're aiming to define a common set of operations, but
> > the implementation appears to be intertwined with BPF. If this is
> > intended to be a common interface, and if we are using another operation,
> > there shouldn’t be a need to hold a BPF reference.
> > 
> > As your 'help' sugguest, What about smc_hook ?
> > 
> > Best regards,
> > Dust
> > 
> >