netdev - Re: [PATCH bpf-next v1 03/15] bpf: Allow storing PTR_TO_BTF

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:   Wed, 23 Feb 2022 13:46:54 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Kumar Kartikeya Dwivedi <memxor@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andrii@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        netfilter-devel <netfilter-devel@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>
Subject: Re: [PATCH bpf-next v1 03/15] bpf: Allow storing PTR_TO_BTF_ID in map

On Tue, Feb 22, 2022 at 7:09 PM Kumar Kartikeya Dwivedi
<memxor@...il.com> wrote:
> > > +                   }
> > > +                   btf_id_tag = true;
> > > +           } else if (!strncmp("kernel.", __btf_name_by_offset(btf, t->name_off),
> > > +                      sizeof("kernel.") - 1)) {
> > > +                   /* TODO: Should we reject these when loading BTF? */
> > > +                   /* Unavailable tag in reserved tag namespace */
> >
> > I don't think we need to reserve the tag space.
> > There is little risk to break progs with future tags.
> > I would just drop this 'if'.
> >
>
> Fine with dropping, but what is the expected behavior when userspace has set a
> tag in map value BTF that we give some meaning in the kernel later?

All of these features fall into the unstable category.
kfuncs can disappear. kernel data structs can get renamed.
dtor, kptr_get functions not only can change, but can be removed.
When bpf progs are so tightly interacting with the kernel they
have to change and adjust.
Eventually we might bolt a bit of CO-RE like logic to kfunc and kptr
to make things more portable, but it's too early to reserve a btf_tag prefix.
Progs will change. We're not saving users any headache with reservation.
Tracing bpf progs are not user space. That's the key.