netdev - Re: [PATCH v5 bpf-next 1/2] bpf: introduce helper bpf_find

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: <23f914ba-36ea-7270-f0a7-9f2e4b396535@gmail.com>
Date:   Mon, 8 Nov 2021 14:56:40 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Song Liu <songliubraving@...com>
Cc:     bpf <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii@...nel.org" <andrii@...nel.org>,
        Kernel Team <Kernel-team@...com>,
        "kpsingh@...nel.org" <kpsingh@...nel.org>,
        "hengqi.chen@...il.com" <hengqi.chen@...il.com>,
        Yonghong Song <yhs@...com>
Subject: Re: [PATCH v5 bpf-next 1/2] bpf: introduce helper bpf_find_vma



On 11/8/21 2:43 PM, Eric Dumazet wrote:
> 
> 
> On 11/8/21 2:27 PM, Eric Dumazet wrote:
>>
>>
>> On 11/8/21 1:59 PM, Song Liu wrote:
>>>
>>>
>>>> On Nov 8, 2021, at 10:36 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
>>>>
>>>>
>>>>
>>>> On 11/5/21 4:23 PM, Song Liu wrote:
>>>>> In some profiler use cases, it is necessary to map an address to the
>>>>> backing file, e.g., a shared library. bpf_find_vma helper provides a
>>>>> flexible way to achieve this. bpf_find_vma maps an address of a task to
>>>>> the vma (vm_area_struct) for this address, and feed the vma to an callback
>>>>> BPF function. The callback function is necessary here, as we need to
>>>>> ensure mmap_sem is unlocked.
>>>>>
>>>>> It is necessary to lock mmap_sem for find_vma. To lock and unlock mmap_sem
>>>>> safely when irqs are disable, we use the same mechanism as stackmap with
>>>>> build_id. Specifically, when irqs are disabled, the unlocked is postponed
>>>>> in an irq_work. Refactor stackmap.c so that the irq_work is shared among
>>>>> bpf_find_vma and stackmap helpers.
>>>>>
>>>>> Acked-by: Yonghong Song <yhs@...com>
>>>>> Tested-by: Hengqi Chen <hengqi.chen@...il.com>
>>>>> Signed-off-by: Song Liu <songliubraving@...com>
>>>>> ---
>>>>
>>>> ...
>>>>
>>>>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>>>>> index dbc3ad07e21b6..cdb0fba656006 100644
>>>>> --- a/kernel/bpf/btf.c
>>>>> +++ b/kernel/bpf/btf.c
>>>>> @@ -6342,7 +6342,10 @@ const struct bpf_func_proto bpf_btf_find_by_name_kind_proto = {
>>>>> 	.arg4_type	= ARG_ANYTHING,
>>>>> };
>>>>>
>>>>> -BTF_ID_LIST_GLOBAL_SINGLE(btf_task_struct_ids, struct, task_struct)
>>>>> +BTF_ID_LIST_GLOBAL(btf_task_struct_ids)
>>>>> +BTF_ID(struct, task_struct)
>>>>> +BTF_ID(struct, file)
>>>>> +BTF_ID(struct, vm_area_struct)
>>>>
>>>> $ nm -v vmlinux |grep -A3 btf_task_struct_ids
>>>> ffffffff82adfd9c R btf_task_struct_ids
>>>> ffffffff82adfda0 r __BTF_ID__struct__file__715
>>>> ffffffff82adfda4 r __BTF_ID__struct__vm_area_struct__716
>>>> ffffffff82adfda8 r bpf_skb_output_btf_ids
>>>>
>>>> KASAN thinks btf_task_struct_ids has 4 bytes only.
>>>
>>> I have KASAN enabled, but couldn't repro this issue. I think
>>> btf_task_struct_ids looks correct:
>>>
>>> nm -v vmlinux | grep -A3 -B1 btf_task_struct_ids
>>> ffffffff83cf8260 r __BTF_ID__struct__task_struct__1026
>>> ffffffff83cf8260 R btf_task_struct_ids
>>> ffffffff83cf8264 r __BTF_ID__struct__file__1027
>>> ffffffff83cf8268 r __BTF_ID__struct__vm_area_struct__1028
>>> ffffffff83cf826c r bpf_skb_output_btf_ids
>>>
>>> Did I miss something?
>>>
>>> Thanks,
>>> Song
>>>
>>
>> I will release the syzbot bug, so that you can use its .config
>>
>> Basically, we have
>>
>> u32 btf_task_struct_ids[1];
> 
> That is, if  
> 
> # CONFIG_DEBUG_INFO_BTF is not set
> 

This is how btf_sock_ids gets defined :

#ifdef CONFIG_DEBUG_INFO_BTF
BTF_ID_LIST_GLOBAL(btf_sock_ids)
#define BTF_SOCK_TYPE(name, type) BTF_ID(struct, type)
BTF_SOCK_TYPE_xxx
#undef BTF_SOCK_TYPE
#else
u32 btf_sock_ids[MAX_BTF_SOCK_TYPE];
#endif


Perhaps do the same for btf_task_struct_ids ?

Thanks.