netdev - Re: [PATCH net-next 3/4] net/smc: Introduce smc_bpf

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: <8ef927a3-050b-4d5f-9298-efc58f6a57bb@linux.alibaba.com>
Date: Tue, 29 Oct 2024 16:53:31 +0800
From: "D. Wythe" <alibuda@...ux.alibaba.com>
To: Martin KaFai Lau <martin.lau@...ux.dev>
Cc: kgraul@...ux.ibm.com, wenjia@...ux.ibm.com, jaka@...ux.ibm.com,
 ast@...nel.org, daniel@...earbox.net, andrii@...nel.org, 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, dtcccc@...ux.alibaba.com
Subject: Re: [PATCH net-next 3/4] net/smc: Introduce smc_bpf_ops

On 10/26/24 2:30 AM, Martin KaFai Lau wrote:
> On 10/25/24 4:05 AM, D. Wythe wrote:
>> Our main concern is to avoid introducing kfuncs as much as possible. For our subsystem, we might 
>> need to maintain it in a way that maintains a uapi, as we certainly have user applications 
>> depending on it.
> 
> The smc_bpf_ops can read/write the tp and ireq. In patch 4, there is 'tp->syn_smc = 1'. I assume the 
> real bpf prog will read something from the tp to make the decision also. Note that tp/ireq is also 
> not in the uapi but the CO-RE can help in case the tp->syn_smc bool is moved around.
> 
>  From looking at the selftest in patch 4 again, I think all it needs is for the bpf prog (i.e. the 
> ops) to return a bool instead of allowing the bpf prog to write or call a kfunc to change the tp/ireq.
> 

Hi Martin,

At the beginning, I did modify it by returning values, but later I wanted to make this ops more 
universal, so I considered influencing the behavior by modifying the tp without returning any value. 
But considering we currently do not have any other needs, perhaps modifying it by returning a value 
would be more appropriate.

And If that's the case, we won't need to add new prog parameters to the struct_access anymore. I'll 
try this in the next series.

Thanks,
D. Wythe