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
| ||
|
Message-ID: <acb77026-c8eb-39e8-b3a8-23c348cbd60c@linux.alibaba.com> Date: Wed, 12 Apr 2023 16:33:21 +0800 From: "D. Wythe" <alibuda@...ux.alibaba.com> To: 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 Cc: 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: [RFC PATCH bpf-next 0/5] net/smc: Introduce BPF injection capability Hi everyone, It's seems the RFC patch been hanging for some time. I would like to politely inquire if there are any suggestions or criticisms. Compared to previous patches, this patch has several main features: 1. Allow registration of multiple negotiators, each SMC negotiator has a name and can be indexed that name 2. no read/write lock anymore 3. support bpf update If you have any suggestions or criticisms, please let me know. Thanks D. Wythe On 4/6/23 11:30 PM, D. Wythe wrote: > From: "D. Wythe" <alibuda@...ux.alibaba.com> > > This patches attempt to introduce BPF injection capability for SMC, > and add selftest to ensure code stability. > > As we all know that the SMC protocol is not suitable for all scenarios, > especially for short-lived. However, for most applications, they cannot > guarantee that there are no such scenarios at all. Therefore, apps > may need some specific strategies to decide shall we need to use SMC > or not, for example, apps can limit the scope of the SMC to a specific > IP address or port. > > Based on the consideration of transparent replacement, we hope that apps > can remain transparent even if they need to formulate some specific > strategies for SMC using. That is, do not need to recompile their code. > > On the other hand, we need to ensure the scalability of strategies > implementation. Although it is simple to use socket options or sysctl, > it will bring more complexity to subsequent expansion. > > Fortunately, BPF can solve these concerns very well, users can write > thire own strategies in eBPF to choose whether to use SMC or not. > And it's quite easy for them to modify their strategies in the future. > > This patches implement injection capability for SMC via struct_ops. > In that way, we can add new injection scenarios in the future. > > D. Wythe (5): > net/smc: move smc_sock related structure definition > net/smc: net/smc: allow smc to negotiate protocols on policies > net/smc: allow set or get smc negotiator by sockopt > bpf: add smc negotiator support in BPF struct_ops > bpf/selftests: add selftest for SMC bpf capability > > include/net/smc.h | 268 +++++++++++++++++ > include/uapi/linux/smc.h | 1 + > kernel/bpf/bpf_struct_ops_types.h | 4 + > net/Makefile | 1 + > net/smc/Kconfig | 13 + > net/smc/af_smc.c | 203 ++++++++++--- > net/smc/bpf_smc.c | 359 +++++++++++++++++++++++ > net/smc/smc.h | 224 -------------- > tools/testing/selftests/bpf/prog_tests/bpf_smc.c | 107 +++++++ > tools/testing/selftests/bpf/progs/bpf_smc.c | 265 +++++++++++++++++ > 10 files changed, 1186 insertions(+), 259 deletions(-) > create mode 100644 net/smc/bpf_smc.c > create mode 100644 tools/testing/selftests/bpf/prog_tests/bpf_smc.c > create mode 100644 tools/testing/selftests/bpf/progs/bpf_smc.c >
Powered by blists - more mailing lists