netdev - Re: [PATCH bpf-next 1/3] bpf: introduce helper bpf_get_task_stack

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 for Android: free password hash cracker in your pocket

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

Message-ID: <FF92494E-D1EB-4B84-9D2F-8CD43FEAB164@fb.com>
Date:   Tue, 23 Jun 2020 16:59:27 +0000
From:   Song Liu <songliubraving@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
CC:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>
Subject: Re: [PATCH bpf-next 1/3] bpf: introduce helper
 bpf_get_task_stack_trace()



> On Jun 23, 2020, at 8:19 AM, Alexei Starovoitov <alexei.starovoitov@...il.com> wrote:
> 
> On Tue, Jun 23, 2020 at 12:08 AM Song Liu <songliubraving@...com> wrote:
>> 

[...]

>> 
>> +BPF_CALL_3(bpf_get_task_stack_trace, struct task_struct *, task,
>> +          void *, entries, u32, size)
>> +{
>> +       return stack_trace_save_tsk(task, (unsigned long *)entries, size, 0);
>> +}
>> +
>> +static int bpf_get_task_stack_trace_btf_ids[5];
>> +static const struct bpf_func_proto bpf_get_task_stack_trace_proto = {
>> +       .func           = bpf_get_task_stack_trace,
>> +       .gpl_only       = true,
> 
> why?

Actually, I am not sure when we should use gpl_only = true. 

> 
>> +       .ret_type       = RET_INTEGER,
>> +       .arg1_type      = ARG_PTR_TO_BTF_ID,
>> +       .arg2_type      = ARG_PTR_TO_MEM,
>> +       .arg3_type      = ARG_CONST_SIZE_OR_ZERO,
> 
> OR_ZERO ? why?

Will fix. 

> 
>> +       .btf_id         = bpf_get_task_stack_trace_btf_ids,
>> +};
>> +
>> static const struct bpf_func_proto *
>> raw_tp_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>> {
>> @@ -1521,6 +1538,10 @@ tracing_prog_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
>>                return prog->expected_attach_type == BPF_TRACE_ITER ?
>>                       &bpf_seq_write_proto :
>>                       NULL;
>> +       case BPF_FUNC_get_task_stack_trace:
>> +               return prog->expected_attach_type == BPF_TRACE_ITER ?
>> +                       &bpf_get_task_stack_trace_proto :
> 
> why limit to iter only?

I guess it is also useful for other types. Maybe move to bpf_tracing_func_proto()?

> 
>> + *
>> + * int bpf_get_task_stack_trace(struct task_struct *task, void *entries, u32 size)
>> + *     Description
>> + *             Save a task stack trace into array *entries*. This is a wrapper
>> + *             over stack_trace_save_tsk().
> 
> size is not documented and looks wrong.
> the verifier checks it in bytes, but it's consumed as number of u32s.

I am not 100% sure, but verifier seems check it correctly. And I think it is consumed
as u64s?

Thanks,
Song