netdev - Re: [PATCH v1 1/2] bpf: add a longest prefix match trie map implementation

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]

Date:   Fri, 06 Jan 2017 11:43:21 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Daniel Mack <daniel@...que.org>, ast@...com
CC:     dh.herrmann@...il.com, netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH v1 1/2] bpf: add a longest prefix match trie map implementation

On 01/05/2017 09:14 PM, Daniel Mack wrote:
[...]
> In my use case, the actual value of a node is in fact ignored, all that
> matters is whether a node exists in a trie or not. The test code uses
> u64 for its tests.
>
> I can change it around so that the value size can be defined by
> userspace, but ideally it would also support 0-byte lengths then. The
> bpf map syscall handler should handle the latter just fine if I read the
> code correctly?

Right now no map is allowed to have value size of 0, but since kmalloc()
would return ZERO_SIZE_PTR in such case, it looks like it should
work^tm, although I haven't checked whether it's guaranteed that all
the copy_{from,to}_user() implementations work with 0 size as well
and whether ubsan would complain on the ZERO_SIZE_PTR for memcpy() etc.
Perhaps better to reject value size of 0 initially and later on follow
up with making the syscall code more robust for such cases (afaik, for
the htab this was also on todo.)?

Thanks,
Daniel