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: <6645d026-f909-3f9d-2816-02bea6dced97@solarflare.com>
Date:   Thu, 18 Oct 2018 20:41:52 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Martin Lau <kafai@...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 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.

-Ed