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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 25 Mar 2023 13:27:12 -0700
From:   Cong Wang <xiyou.wangcong@...il.com>
To:     Martin KaFai Lau <martin.lau@...ux.dev>
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 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?

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?

Thanks.