linux-kernel - Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token

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: <f580b139-a08b-4705-addd-31f104fd570c@linux.dev>
Date: Mon, 14 Jul 2025 21:15:45 +0800
From: Tao Chen <chen.dylane@...ux.dev>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 martin.lau@...ux.dev, eddyz87@...il.com, song@...nel.org,
 yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
 sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, willemb@...gle.com,
 kerneljasonxing@...il.com, bpf@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Add struct bpf_token_info

在 2025/7/12 01:10, Andrii Nakryiko 写道:

Hi Andrri,

> On Fri, Jul 11, 2025 at 2:45 AM Tao Chen <chen.dylane@...ux.dev> wrote:
>>
>> The 'commit 35f96de04127 ("bpf: Introduce BPF token object")' added
>> BPF token as a new kind of BPF kernel object. And BPF_OBJ_GET_INFO_BY_FD
>> already used to get BPF object info, so we can also get token info with
>> this cmd.
>>
> 
> Do you have a specific use case in mind for this API? I can see how
> this might be useful for some hypothetical cases, but I have a few
> reservations as of right now:
> 
>    - we don't allow iterating all BPF token objects in the system the
> same way we do it for progs, maps, and btfs, so bpftool cannot take
> advantage of this to list all available tokens and their info, which
> makes this API a bit less useful, IMO;
> 
>    - BPF token was designed in a way that users don't really need to
> know allowed_* values (and if they do, they can get it from BPF FS's
> mount information (e.g., from /proc/mounts).
> 
> As I said, I can come up with some hypothetical situations where a
> user might want to avoid doing something that otherwise they'd do
> outside of userns, but I'm wondering what your motivations are for
> this?
> 

Sorry for the delay. Recentlly, i tried to use bpf_token feature in our 
production environment, in fact, bpf_token grants permission to prog, 
map, cmd, etc. It would be great if it could indicate which specific 
permission is the issue to user. So i wanted to provide a token info 
query interface. As you said, "mount | grep bpf" may solve it, but
functionally, can we make it more complete?

>> Signed-off-by: Tao Chen <chen.dylane@...ux.dev>
>> ---
>>   include/linux/bpf.h            | 11 +++++++++++
>>   include/uapi/linux/bpf.h       |  8 ++++++++
>>   kernel/bpf/syscall.c           | 18 ++++++++++++++++++
>>   kernel/bpf/token.c             | 30 ++++++++++++++++++++++++++++--
>>   tools/include/uapi/linux/bpf.h |  8 ++++++++
>>   5 files changed, 73 insertions(+), 2 deletions(-)
>>
> 
> [...]


-- 
Best Regards
Tao Chen