netdev - Re: [PATCH bpf-next v2 02/13] bpf: btf: Add BTF_KIND_FUNC and BTF_KIND_FUNC

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: <20181018211954.egdolymm3zqgphmd@kafai-mbp.dhcp.thefacebook.com>
Date:   Thu, 18 Oct 2018 21:19:56 +0000
From:   Martin Lau <kafai@...com>
To:     Edward Cree <ecree@...arflare.com>
CC:     Yonghong Song <yhs@...com>, Alexei Starovoitov <ast@...com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next v2 02/13] bpf: btf: Add BTF_KIND_FUNC and
 BTF_KIND_FUNC_PROTO

On Thu, Oct 18, 2018 at 08:41:52PM +0100, Edward Cree wrote:
> On 18/10/18 19:12, Martin Lau wrote:
> > The BTF verification and bpf_prog_load() has to treat
> > them differently.
> >
> > Are you suggesting they can be treated the same for
> > the kernel verification purpose?
> >
> > or
> >
> > The concern is, having two kind, BTF_KIND_FUNC_PROTO and
> > BTF_KIND_FUNC, is confusing because they have almost the
> > same BTF metadata?
> >
> > From the BTF perspective, they are different because
> > they are allowed to contain different information.
> > For example, only "foo" can have func_info in patch 5
> > (the to-be-added line_info can only belong to "foo" also).
> Perhaps I'm not properly understanding how BTF is to be used.
> But from my perspective, 'foo' is not a type; it's an instance
>  of a type; i.e. it's a value of type int ()(int).  Then by a
>  kind of metonymy, we are including a BTF record that defines
>  the type 'foo' as int()(int), in order to state that this is
>  the type _of_ foo.  Similarly, we are including a BTF record
>  defining 'bar' as the type int (*)(int), thus stating that
>  the type _of_ bar is int (*)(int).
> So everything that's special about 'foo' relates to the fact
>  that it is a named, rather than anonymous, type, which is
>  being used to indicate that there is an actual object 'foo'
>  of this type.
> And this is *identical* to how the BTF record "name 'a', type
>  int" declares an object a, the BTF record "name 'b', type
>  int *" declares an object b, and the anonymous int type
>  referenced by b's btf_type.type does not declare an object.
> 
> So either types and objects are represented the same way in
>  BTF, or not; it's inconsistent to make a distinction between
>  them for functions but not for other types.
> 
> I know C thinks functions are special, but that's a wart in C
>  that maybe makes sense in its context but not elsewhere.
As I have mentioned earlier, it is also special to
the kernel because the BTF verifier and bpf_prog_load()
need to do different checks for FUNC and FUNC_PROTO to
ensure they are sane.

First, we need to agree that the kernel needs to verify
them differently.

and then we can proceed to discuss how to distinguish them.
We picked the current way to avoid adding a
new BTF function section and keep it
strict forward to distinguish them w/o relying
on other hints from 'struct btf_type'.

Are you suggesting another way of doing it?