[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f140db9b-ed23-7e56-e5b9-d90caf6493cb@fb.com>
Date: Fri, 21 Aug 2020 08:46:05 -0700
From: Yonghong Song <yhs@...com>
To: Lorenz Bauer <lmb@...udflare.com>, <jakub@...udflare.com>,
<john.fastabend@...il.com>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>
CC: <kernel-team@...udflare.com>, <netdev@...r.kernel.org>,
<bpf@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v3 4/6] bpf: override the meaning of
ARG_PTR_TO_MAP_VALUE for sockmap and sockhash
On 8/21/20 3:29 AM, Lorenz Bauer wrote:
> The verifier assumes that map values are simple blobs of memory, and
> therefore treats ARG_PTR_TO_MAP_VALUE, etc. as such. However, there are
> map types where this isn't true. For example, sockmap and sockhash store
> sockets. In general this isn't a big problem: we can just
> write helpers that explicitly requests PTR_TO_SOCKET instead of
> ARG_PTR_TO_MAP_VALUE.
>
> The one exception are the standard map helpers like map_update_elem,
> map_lookup_elem, etc. Here it would be nice we could overload the
> function prototype for different kinds of maps. Unfortunately, this
> isn't entirely straight forward:
> We only know the type of the map once we have resolved meta->map_ptr
> in check_func_arg. This means we can't swap out the prototype
> in check_helper_call until we're half way through the function.
>
> Instead, modify check_func_arg to treat ARG_PTR_TO_MAP_VALUE to
> mean "the native type for the map" instead of "pointer to memory"
> for sockmap and sockhash. This means we don't have to modify the
> function prototype at all
>
> Signed-off-by: Lorenz Bauer <lmb@...udflare.com>
Acked-by: Yonghong Song <yhs@...com>
Powered by blists - more mailing lists