netdev - RE: [RFC bpf-next 1/5] bpf, sockmap: Let BPF helpers use lookup operation on SOCKMAP

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:   Thu, 24 Oct 2019 09:59:22 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Jakub Sitnicki <jakub@...udflare.com>, bpf@...r.kernel.org
Cc:     John Fastabend <john.fastabend@...il.com>,
        Martin KaFai Lau <kafai@...com>, netdev@...r.kernel.org,
        kernel-team@...udflare.com
Subject: RE: [RFC bpf-next 1/5] bpf, sockmap: Let BPF helpers use lookup
 operation on SOCKMAP

Jakub Sitnicki wrote:
> Don't require the BPF helpers that need to access SOCKMAP maps to live in
> the sock_map module. Expose SOCKMAP lookup to all kernel-land.
> 
> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>
> ---
>  net/core/sock_map.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index eb114ee419b6..facacc296e6c 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -271,7 +271,9 @@ static struct sock *__sock_map_lookup_elem(struct bpf_map *map, u32 key)
>  
>  static void *sock_map_lookup(struct bpf_map *map, void *key)
>  {
> -	return ERR_PTR(-EOPNOTSUPP);
> +	u32 index = *(u32 *)key;
> +
> +	return __sock_map_lookup_elem(map, index);
>  }
>  
>  static int __sock_map_delete(struct bpf_stab *stab, struct sock *sk_test,
> -- 
> 2.20.1
> 

OK, I'm looking into the latest BTF bits to see if we can do something
more useful here to keep the type information when the lookup is done so
the sock can be feed from sk_lookup and actually read.

As this series stands after the lookup its just an opaque ptr_to_map_value
right?