linux-kernel - Re: [PATCH net-next v21] net: refactor ->ndo_bpf calls into dev_xdp

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: <20240821164318.34503e64@kernel.org>
Date: Wed, 21 Aug 2024 16:43:18 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Mina Almasry <almasrymina@...gle.com>, Hangbin Liu
 <liuhangbin@...il.com>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-hyperv@...r.kernel.org, bpf@...r.kernel.org, Jay Vosburgh
 <jv@...sburgh.net>, Andy Gospodarek <andy@...yhouse.net>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, "K. Y. Srinivasan" <kys@...rosoft.com>, Haiyang Zhang
 <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
 <decui@...rosoft.com>, Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann
 <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Martin KaFai
 Lau <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu
 <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend
 <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav
 Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
 <jolsa@...nel.org>, "Björn Töpel" <bjorn@...nel.org>,
 Magnus Karlsson <magnus.karlsson@...el.com>, Maciej Fijalkowski
 <maciej.fijalkowski@...el.com>, Jonathan Lemon <jonathan.lemon@...il.com>,
 Jesper Dangaard Brouer <hawk@...nel.org>
Subject: Re: [PATCH net-next v21] net: refactor ->ndo_bpf calls into
 dev_xdp_propagate

On Wed, 21 Aug 2024 04:56:29 +0000 Mina Almasry wrote:
> When net devices propagate xdp configurations to slave devices, or when
> core propagates xdp configuration to a device, we will need to perform
> a memory provider check to ensure we're not binding xdp to a device
> using unreadable netmem.
> 
> Currently ->ndo_bpf calls are all over the place. Adding checks to all
> these places would not be ideal.
> 
> Refactor all the ->ndo_bpf calls into one place where we can add this
> check in the future.
> 
> Suggested-by: Jakub Kicinski <kuba@...nel.org>
> Signed-off-by: Mina Almasry <almasrymina@...gle.com>

> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index f9633a6f8571..73f9416c6c1b 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2258,7 +2258,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
>  			goto err_sysfs_del;
>  		}
>  
> -		res = slave_dev->netdev_ops->ndo_bpf(slave_dev, &xdp);
> +		res = dev_xdp_propagate(slave_dev, &xdp);

I was hoping we can fold the "is there any program present already"
but I'm not sure if that check itself isn't buggy... so let's leave
that part to someone else.

Hangbin, would you be willing to take a look at testing (and fixing)
the XDP program propagation? I did a naive test of adding a bond
and veth under it, I attached an XDP prog to bond, and nothing happened
on the veth. Maybe I'm misreading but I expected the XDP prog to show
up on the veth.

> diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c
> index 4a9522689fa4..e01c5997a551 100644
> --- a/drivers/net/hyperv/netvsc_bpf.c
> +++ b/drivers/net/hyperv/netvsc_bpf.c
> @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog)
>  	xdp.command = XDP_SETUP_PROG;
>  	xdp.prog = prog;
>  
> -	ret = vf_netdev->netdev_ops->ndo_bpf(vf_netdev, &xdp);
> +	ret = dev_xdp_propagate(vf_netdev, &xdp);

Again, the driver itself appears rather questionable but we can leave
it be :)

> @@ -130,7 +130,7 @@ static int bpf_map_offload_ndo(struct bpf_offloaded_map *offmap,
>  	/* Caller must make sure netdev is valid */
>  	netdev = offmap->netdev;
>  
> -	return netdev->netdev_ops->ndo_bpf(netdev, &data);
> +	return dev_xdp_propagate(netdev, &data);

This is not propagation, it's an offload call, let's not convert it

> diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
> index c0e0204b9630..f44d68c8d75d 100644
> --- a/net/xdp/xsk_buff_pool.c
> +++ b/net/xdp/xsk_buff_pool.c
> @@ -149,7 +149,7 @@ static void xp_disable_drv_zc(struct xsk_buff_pool *pool)
>  		bpf.xsk.pool = NULL;
>  		bpf.xsk.queue_id = pool->queue_id;
>  
> -		err = pool->netdev->netdev_ops->ndo_bpf(pool->netdev, &bpf);
> +		err = dev_xdp_propagate(pool->netdev, &bpf);
>  
>  		if (err)
>  			WARN(1, "Failed to disable zero-copy!\n");
> @@ -215,7 +215,7 @@ int xp_assign_dev(struct xsk_buff_pool *pool,
>  	bpf.xsk.pool = pool;
>  	bpf.xsk.queue_id = queue_id;
>  
> -	err = netdev->netdev_ops->ndo_bpf(netdev, &bpf);
> +	err = dev_xdp_propagate(netdev, &bpf);
>  	if (err)
>  		goto err_unreg_pool;
>  

That's also not xdp propagation. If you're not doing so already in your
series - you should look at queue state here directly and check if it
has MP installed. Conversely you should look at rxq->pool when binding
MP. But as I said, that's not part of the XDP refactor, just as part of
your series.

So in case my ramblings were confusing - code LG, but ditch the
net/xdp/xsk_buff_pool.c and kernel/bpf/offload.c changes.