netdev - Re: [PATCH bpf-next 3/4] bpf: Add BPF_FIB_LOOKUP_SKIP_NEIGH for bpf_fib

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]

Message-ID: <dd4e2b92-53c9-6973-86ff-8cb04913c3ca@iogearbox.net>
Date:   Fri, 17 Feb 2023 17:00:39 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Martin KaFai Lau <martin.lau@...ux.dev>, bpf@...r.kernel.org
Cc:     'Alexei Starovoitov ' <ast@...nel.org>,
        'Andrii Nakryiko ' <andrii@...nel.org>,
        netdev@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH bpf-next 3/4] bpf: Add BPF_FIB_LOOKUP_SKIP_NEIGH for
 bpf_fib_lookup

On 2/17/23 1:41 AM, Martin KaFai Lau wrote:
> From: Martin KaFai Lau <martin.lau@...nel.org>
> 
> The bpf_fib_lookup() also looks up the neigh table.
> This was done before bpf_redirect_neigh() was added.
> 
> In the use case that does not manage the neigh table
> and requires bpf_fib_lookup() to lookup a fib to
> decide if it needs to redirect or not, the bpf prog can
> depend only on using bpf_redirect_neigh() to lookup the
> neigh. It also keeps the neigh entries fresh and connected.
> 
> This patch adds a bpf_fib_lookup flag, SKIP_NEIGH, to avoid
> the double neigh lookup when the bpf prog always call
> bpf_redirect_neigh() to do the neigh lookup.
> 
> Signed-off-by: Martin KaFai Lau <martin.lau@...nel.org>
> ---
>   include/uapi/linux/bpf.h       |  1 +
>   net/core/filter.c              | 33 +++++++++++++++++++++++----------
>   tools/include/uapi/linux/bpf.h |  1 +
>   3 files changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 1503f61336b6..6c1956e36c97 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
[...]
> @@ -5838,21 +5836,28 @@ static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params,
>   	if (likely(nhc->nhc_gw_family != AF_INET6)) {
>   		if (nhc->nhc_gw_family)
>   			params->ipv4_dst = nhc->nhc_gw.ipv4;
> -
> -		neigh = __ipv4_neigh_lookup_noref(dev,
> -						 (__force u32)params->ipv4_dst);
>   	} else {
>   		struct in6_addr *dst = (struct in6_addr *)params->ipv6_dst;
>   
>   		params->family = AF_INET6;
>   		*dst = nhc->nhc_gw.ipv6;
> -		neigh = __ipv6_neigh_lookup_noref_stub(dev, dst);
>   	}
>   
> +	if (flags & BPF_FIB_LOOKUP_SKIP_NEIGH)
> +		goto set_fwd_params;
> +
> +	if (params->family == AF_INET6)

Nit, would have probably more intuitive to keep the same test also here
(nhc->nhc_gw_family != AF_INET6), but either way, lgtm.

Are you still required to fill the params->smac in bpf_fib_set_fwd_params()
in that case, meaning, shouldn't bpf_redirect_neigh() take care of it as well
from neigh_output()? Looks unnecessary and could be moved out too.

(Took in first 2 in the meantime which look good.)

> +		neigh = __ipv6_neigh_lookup_noref_stub(dev, params->ipv6_dst);
> +	else
> +		neigh = __ipv4_neigh_lookup_noref(dev,
> +						  (__force u32)params->ipv4_dst);
> +
>   	if (!neigh || !(neigh->nud_state & NUD_VALID))
>   		return BPF_FIB_LKUP_RET_NO_NEIGH;
> +	memcpy(params->dmac, neigh->ha, ETH_ALEN);
>   
> -	return bpf_fib_set_fwd_params(params, neigh, dev, mtu);
> +set_fwd_params:
> +	return bpf_fib_set_fwd_params(params, dev, mtu);