netdev - Re: [PATCH bpf-next 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]

Date:   Wed, 17 Oct 2018 03:11:58 +0000
From:   Yonghong Song <yhs@...com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...com>, Martin Lau <kafai@...com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 02/13] bpf: btf: Add BTF_KIND_FUNC and
 BTF_KIND_FUNC_PROTO



On 10/15/18 3:30 PM, Daniel Borkmann wrote:
> On 10/12/2018 08:54 PM, Yonghong Song wrote:
>> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
>> support to the type section. BTF_KIND_FUNC_PROTO is used
>> to specify the type of a function pointer. With this,
>> BTF has a complete set of C types (except float).
>>
>> BTF_KIND_FUNC is used to specify the signature of a
>> defined subprogram. BTF_KIND_FUNC_PROTO can be referenced
>> by another type, e.g., a pointer type, and BTF_KIND_FUNC
>> type cannot be referenced by another type.
>>
>> For both BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO types,
>> the func return type is in t->type (where t is a
>> "struct btf_type" object). The func args are an array of
>> u32s immediately following object "t".
>>
>> As a concrete example, for the C program below,
>>    $ cat test.c
>>    int foo(int (*bar)(int)) { return bar(5); }
>> with latest llvm trunk built with Debug mode, we have
>>    $ clang -target bpf -g -O2 -mllvm -debug-only=btf -c test.c
>>    Type Table:
>>    [1] FUNC name_off=1 info=0x0c000001 size/type=2
>>            param_type=3
>>    [2] INT name_off=11 info=0x01000000 size/type=4
>>            desc=0x01000020
>>    [3] PTR name_off=0 info=0x02000000 size/type=4
>>    [4] FUNC_PROTO name_off=0 info=0x0d000001 size/type=2
>>            param_type=2
>>
>>    String Table:
>>    0 :
>>    1 : foo
>>    5 : .text
>>    11 : int
>>    15 : test.c
>>    22 : int foo(int (*bar)(int)) { return bar(5); }
>>
>>    FuncInfo Table:
>>    sec_name_off=5
>>            insn_offset=<Omitted> type_id=1
>>
>>    ...
>>
>> (Eventually we shall have bpftool to dump btf information
>>   like the above.)
>>
>> Function "foo" has a FUNC type (type_id = 1).
>> The parameter of "foo" has type_id 3 which is PTR->FUNC_PROTO,
>> where FUNC_PROTO refers to function pointer "bar".
> 
> Should also "bar" be part of the string table (at least at some point in future)?

Yes, we can do it. The dwarf for the abovee example looks like

0x00000043:     DW_TAG_formal_parameter
                   DW_AT_location        (0x00000000
                      [0x0000000000000000,  0x0000000000000008): 
DW_OP_reg1 W1
                      [0x0000000000000008,  0x0000000000000018): 
DW_OP_reg2 W2)
                   DW_AT_name    ("bar")
                   DW_AT_decl_file       ("/home/yhs/tmp/t.c")
                   DW_AT_decl_line       (1)
                   DW_AT_type    (0x0000005a "subroutine int*")

0x0000005a:   DW_TAG_pointer_type
                 DW_AT_type      (0x0000005f "subroutine int")

0x0000005f:   DW_TAG_subroutine_type
                 DW_AT_type      (0x00000053 "int")
                 DW_AT_prototyped        (true)

0x00000064:     DW_TAG_formal_parameter
                   DW_AT_type    (0x00000053 "int")

0x00000069:     NULL

0x0000006a:   NULL

The current llvm implementation does not record func
parameter name, so "bar" got lost. We could associate
"bar" with pointer type in the future implementation.

> Iow, if verifier hints to an issue in the program when it would for example walk
> pointers and rewrite ctx access, then it could dump the var name along with it.
> It might be useful as well in combination with 22 from str table, when annotating
> the source. We might need support for variadic functions, though. How is LLVM
> handling the latter with the recent BTF support?

The LLVM implementation does support variadic functions.
The last type id 0 indicates a variadic function.

> 
>> In FuncInfo Table, for section .text, the function,
>> with to-be-determined offset (marked as <Omitted>),
>> has type_id=1 which refers to a FUNC type.
>> This way, the function signature is
>> available to both kernel and user space.
>> Here, the insn offset is not available during the dump time
>> as relocation is resolved pretty late in the compilation process.
>>
>> Signed-off-by: Martin KaFai Lau <kafai@...com>
>> Signed-off-by: Yonghong Song <yhs@...com>