netdev - Re: bpf: btf: Change how section is supported in 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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 12 Sep 2018 10:10:24 +0200
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Martin KaFai Lau <kafai@...com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: bpf: btf: Change how section is supported in btf_header

On Tue, Sep 11, 2018 at 8:10 PM, Martin KaFai Lau <kafai@...com> wrote:
> On Tue, Sep 11, 2018 at 06:40:05PM +0200, Dmitry Vyukov wrote:
>> Hi Martin,
>>
>> I am looking at the subj commit:
>>
>>  static int btf_add_type(struct btf_verifier_env *env, struct btf_type *t)
>> @@ -1754,9 +1756,9 @@ static int btf_check_all_metas(struct
>> btf_verifier_env *env)
>>         struct btf_header *hdr;
>>         void *cur, *end;
>>
>> -       hdr = btf->hdr;
>> +       hdr = &btf->hdr;
>>         cur = btf->nohdr_data + hdr->type_off;
>> -       end = btf->nohdr_data + hdr->str_off;
>> +       end = btf->nohdr_data + hdr->type_len;
>>
>> Shouldn't this be:
>>
>> +       end = cur + hdr->type_len;
>>
>> ? Or otherwise I am having trouble understanding meaning of fields.
> You are correct.  Thanks for pointing this out.
> Do you want to post an offical patch for the bpf branch?

no :)

Only if you want to send a syzkaller patch with btf descriptions ;)

>> On a related note, what's between header and type_off? Is type_off
>> supposed to be 0 always?
> type section is always the first section for now (i.e. immediately after
> the header).  Some other sections could be introduced later and it could
> be located before the type section such that the type_off will not be 0.

I see. Thanks.