linux-kernel - Re: [PATCH bpf v2 3/5] libbpf: Skip adjust mem size for load pointer in 32-bit arch in CO

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: <8911eeb0-d9a9-4592-34b5-e6e0a9efe692@huawei.com>
Date:   Tue, 8 Nov 2022 10:44:59 +0800
From:   Yang Jihong <yangjihong1@...wei.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
CC:     <ast@...nel.org>, <daniel@...earbox.net>, <andrii@...nel.org>,
        <martin.lau@...ux.dev>, <song@...nel.org>, <yhs@...com>,
        <john.fastabend@...il.com>, <kpsingh@...nel.org>, <sdf@...gle.com>,
        <haoluo@...gle.com>, <jolsa@...nel.org>,
        <illusionist.neo@...il.com>, <linux@...linux.org.uk>,
        <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <mykolal@...com>, <shuah@...nel.org>,
        <benjamin.tissoires@...hat.com>, <memxor@...il.com>,
        <asavkov@...hat.com>, <delyank@...com>, <bpf@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
        <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH bpf v2 3/5] libbpf: Skip adjust mem size for load pointer
 in 32-bit arch in CO_RE

Hello,

On 2022/11/8 9:22, Andrii Nakryiko wrote:
> On Mon, Nov 7, 2022 at 1:23 AM Yang Jihong <yangjihong1@...wei.com> wrote:
>>
>> bpf_core_patch_insn modifies load's mem size from 8 bytes to 4 bytes.
>> As a result, the bpf check fails, we need to skip adjust mem size to fit
>> the verifier.
>>
>> Signed-off-by: Yang Jihong <yangjihong1@...wei.com>
>> ---
>>   tools/lib/bpf/libbpf.c | 34 +++++++++++++++++++++++++++++-----
>>   1 file changed, 29 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
>> index 184ce1684dcd..e1c21b631a0b 100644
>> --- a/tools/lib/bpf/libbpf.c
>> +++ b/tools/lib/bpf/libbpf.c
>> @@ -5634,6 +5634,28 @@ static int bpf_core_resolve_relo(struct bpf_program *prog,
>>                                         targ_res);
>>   }
>>
>> +static bool
>> +bpf_core_patch_insn_skip(const struct btf *local_btf, const struct bpf_insn *insn,
>> +                        const struct bpf_core_relo_res *res)
>> +{
>> +       __u8 class;
>> +       const struct btf_type *orig_t;
>> +
>> +       class = BPF_CLASS(insn->code);
>> +       orig_t = btf_type_by_id(local_btf, res->orig_type_id);
>> +
>> +       /*
>> +        * verifier has to see a load of a pointer as a 8-byte load,
>> +        * CO_RE should not screws up access, bpf_core_patch_insn modifies
>> +        * load's mem size from 8 bytes to 4 bytes in 32-bit arch,
>> +        * so we skip adjust mem size.
>> +        */
> 
> Nope, this is only for BPF UAPI context types like __sk_buff (right
> now). fentry/fexit/raw_tp_btf programs traversing kernel types and
> following pointers actually need this to work correctly. Don't do
> this.
Distinguishing BPF UAPI context from kernel type requires some work. 
According to current situation, the solution of patch2 is relatively simple.

Thanks,
Yang