netdev - Re: [PATCH net-next] bpf: add helper capable of reading out instructions

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]

Message-ID: <59778D0D.8060004@iogearbox.net>
Date:   Tue, 25 Jul 2017 20:25:17 +0200
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Jakub Kicinski <jakub.kicinski@...ronome.com>
CC:     netdev@...r.kernel.org, alexei.starovoitov@...il.com,
        oss-drivers@...ronome.com, kafai@...com
Subject: Re: [PATCH net-next] bpf: add helper capable of reading out instructions

On 07/25/2017 08:20 PM, Jakub Kicinski wrote:
> On Tue, 25 Jul 2017 18:40:23 +0200, Daniel Borkmann wrote:
>> [ +Martin ]
>
> Sorry, I thought I CCed Martin.
>
>> On 07/24/2017 11:22 PM, Jakub Kicinski wrote:
>>> To read translated and jited instructions from the kernel,
>>> one has to set certain pointers of struct bpf_prog_info to
>>> pre-allocated user buffers.  Unfortunately, the existing
>>> bpf_obj_get_info_by_fd() helper zeros struct bpf_prog_info
>>> before passing it to the kernel.
>>>
>>> Keeping the zeroing seems like a good idea in general, since
>>> kernel will check if the structure was zeroed.  Add a new
>>> helper for those more advanced users who can be trusted to
>>> take care of zeroing themselves.
>>>
>>> Signed-off-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
>>> ---
>>> I'm happy to change the name of the new function.
>>>
>>>    tools/lib/bpf/bpf.c | 10 ++++++++--
>>>    tools/lib/bpf/bpf.h |  2 ++
>>>    2 files changed, 10 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>>> index 412a7c82995a..2703fa282b65 100644
>>> --- a/tools/lib/bpf/bpf.c
>>> +++ b/tools/lib/bpf/bpf.c
>>> @@ -308,13 +308,12 @@ int bpf_map_get_fd_by_id(__u32 id)
>>>    	return sys_bpf(BPF_MAP_GET_FD_BY_ID, &attr, sizeof(attr));
>>>    }
>>>
>>> -int bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len)
>>> +int __bpf_obj_get_info_by_fd(int prog_fd, void *info, __u32 *info_len)
>>>    {
>>>    	union bpf_attr attr;
>>>    	int err;
>>>
>>>    	bzero(&attr, sizeof(attr));
>>> -	bzero(info, *info_len);
>>
>> Looks a bit unintentional to me, e.g. 95b9afd3987f ("bpf: Test for bpf
>> ID") did set up pointers in test_bpf_obj_id(), but later only checked
>> for the {jited,xlated}_prog_len.
>>
>> Clearing out the pointers looks not to useful. Lets just push the need
>> for bzero() to call-sites in general in this case.
>
> Should I target this at net then?  To avoid backwards compatibility
> issues?

Yep, sounds reasonable. Thanks!