linux-kernel - Re: [RFC PATCH bpf-next 08/13] bpf: Alloc and free 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: <CALOAHbBd5Bx0Tnzv1MW_NV9mOJrqdk5oySYWQr-XXURAM5xndw@mail.gmail.com>
Date:   Mon, 27 Mar 2023 10:44:12 +0800
From:   Yafang Shao <laoar.shao@...il.com>
To:     Toke Høiland-Jørgensen <toke@...nel.org>
Cc:     ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
        kafai@...com, songliubraving@...com, yhs@...com,
        john.fastabend@...il.com, kpsingh@...nel.org, sdf@...gle.com,
        haoluo@...gle.com, jolsa@...nel.org, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH bpf-next 08/13] bpf: Alloc and free bpf_map id in bpf namespace

On Sun, Mar 26, 2023 at 6:51 PM Toke Høiland-Jørgensen <toke@...nel.org> wrote:
>
> Yafang Shao <laoar.shao@...il.com> writes:
>
> > We only expose the bpf map id under current bpf namespace to user. The
> > map->id is still the id in the init bpf namespace.
> >
> > The result as follows,
> >
> > Run bpftool in a new bpf namespace
> > $ bpftool map show
> > 4: array  name kprobe_b.rodata  flags 0x80
> >         key 4B  value 37B  max_entries 1  memlock 360B
> >         btf_id 159  frozen
>
> The btf_id is identical for all the different objects in this example
> output; surely that can't be right? Copy-paste error? Same thing in the
> other patches...
>

The bpf progs {"kretprobe_run","kprobe_run"} and the bpf maps
{"kprobe_b.rodata","kprobe_b.data"} belong to the same bpf program. So
the btf_id of them are always the same. For example, below is the
result when I rerun it on my test server,
$ bpftool btf show
...
943: name <anon>  size 1086B  prog_ids 48824,48822  map_ids 43712,43711
        pids kprobe(3599801)
...

$ bpftool map show
43711: array  name kprobe_b.rodata  flags 0x80
        key 4B  value 37B  max_entries 1  memlock 360B
        btf_id 943  frozen
        pids kprobe(3599801)
43712: array  name kprobe_b.data  flags 0x400
        key 4B  value 4B  max_entries 1  memlock 8192B
        btf_id 943
        pids kprobe(3599801)

$ bpftool prog show
48822: kprobe  name kretprobe_run  tag 0de47cc241a2b1b3  gpl
        loaded_at 2023-03-27T10:35:01+0800  uid 0
        xlated 112B  jited 78B  memlock 4096B  map_ids 43711
        btf_id 943
        pids kprobe(3599801)
48824: kprobe  name kprobe_run  tag bf163b23cd3b174d  gpl
        loaded_at 2023-03-27T10:35:01+0800  uid 0
        xlated 104B  jited 75B  memlock 4096B  map_ids 43711
        btf_id 943
        pids kprobe(3599801)

The btf_id hasn't been added into the bpf namespace, so the btf id in
init bpf namespace and child bpf namespace are the same value.

-- 
Regards
Yafang