netdev - Re: [Patch net-next v3] sock_map: dump socket map id via diag

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] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Mar 2023 15:10:29 -0700
From:   Martin KaFai Lau <martin.lau@...ux.dev>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Stanislav Fomichev <sdf@...gle.com>, netdev@...r.kernel.org,
        bpf@...r.kernel.org, Cong Wang <cong.wang@...edance.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jakub Sitnicki <jakub@...udflare.com>
Subject: Re: [Patch net-next v3] sock_map: dump socket map id via diag

On 3/25/23 1:27 PM, Cong Wang wrote:
> On Mon, Mar 20, 2023 at 01:29:39PM -0700, Martin KaFai Lau wrote:
>> On 3/20/23 11:13 AM, Stanislav Fomichev wrote:
>>> One thing I still don't understand here: what is missing from the
>>> socket iterators to implement this? Is it all the sk_psock_get magic?
>>> I remember you dismissed Yonghong's suggestion on v1, but have you
>>> actually tried it?
>> would be useful to know what is missing to print the bpf map id without
>> adding kernel code. There is new bpf_rdonly_cast() which will be useful here
>> also.
> 
> So you don't consider eBPF code as kernel code, right? Interestingly
> enough, eBPF code runs in kernel... and you still need to write eBPF
> code. So what is the point of "without adding kernel code" here?

Interesting, how is it the same? if it needs to print something other than the 
map id in the future, even putting aside further kernel maintenance and 
additional review, does a new bpf prog need to upgrade and reboot the kernel?

Based on your idea, all possible sk_filter automatically qualify to be added to 
the kernel source tree now because they also run in the kernel?

> 
> What is even more interesting is that even your own code does not agree
> with you here, for example, you introduced INET_DIAG_SK_BPF_STORAGES, so
> what was missing to print sk bpf storage without adding kernel code?

Yep, you are absolutely correct. Only if bpf-iter was available earlier. If 
bpf-iter was available before INET_DIAG_SK_BPF_STORAGES was added, there was no 
need to add INET_DIAG_SK_BPF_STORAGES and it would be no brainer to explore the 
bpf-iter approach first. Things have been improving.

The question (from a few people) was to figure out what was missing in the 
bpf-iter approach to print this bpf bits and trying to help. It is the only 
reason I replied. Apparently, you have not even tried and not interested.