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: <84383282-9439-c523-1f1d-9c4445ba1c69@solarflare.com>
Date:   Tue, 6 Nov 2018 18:52:11 +0000
From:   Edward Cree <ecree@...arflare.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     Martin Lau <kafai@...com>, 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 06/11/18 06:29, Alexei Starovoitov wrote:
> BTF is not pure type information. BTF is everything that verifier needs
> to know to make safety decisions that bpf instruction set doesn't have.
Yes, I'm not disputing that and never have.
I'm just saying that it will be much cleaner and better if it's
 internally organised differently.

> Splitting pure types into one section, variables into another,
> functions into yet another is not practical, since the same
> modifiers (like const or volatile) need to be applied to
> variables and functions. At the end all sections will have
> the same style of encoding, hence no need to duplicate
> the encoding three times and instead it's cleaner to encode
> all of them BTF-style via different KINDs.
This shows that you've misunderstood what I'm proposing, probably
 I explained it poorly so I'll try again.
I'm not suggesting that the 'functions' and 'variables' sections
 would have _type_ records in them, only that they would reference
 records in the 'types' section.  So if for instance we have
    int foo(int x) { int quux; /* ... */ }
    int bar(int y) { /* ... */ }
 in the source, then in the 'types' section we would have
1 INT 32bits encoding=signed offset=0
2 FUNC args=(name="x" type=1,), ret=1
3 FUNC args=(name="y" type=1,), ret=1
 while in the 'functions' section we would have
1 "foo" type=2 start_insn_idx=23 insn_count=19 (... maybe other info too...)
2 "bar" type=3 start_insn_idx=42 insn_count=5
 and in the 'variables' section we might have
1 "quux" type=1 where=stack func=1 offset=-8

Thus the graph of types lives entirely in the 'types' section, but
 things-that-are-not-types don't.  I'm not making a distinction
 between "pure types" and (somehow) impure types; I'm making a
 distinction between types (with all their impurities) and
 *instances* of those types.
Note that these 'sections' may all really be regions of the '.BTF'
 ELF section, if that makes the implementation easier.  Also, the
 'functions' and 'variables' sections _won't_ have the same style
 of encoding as the 'types', because they're storing entirely
 different data and in fact don't need variable record sizes.

And note that in this case any const or volatile qualifiers happen
 _in the 'types' section_, because they're just another way of
 deriving a type, and the records in other sections that might want
 them will just point at a BTF_KIND_CONST or BTF_KIND_VOLATILE
 record in the 'types' section.

-Ed