netdev - Re: [PATCH net-next v2] samples/bpf: fixup some tools to be able to support xdp multibuffer

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: <40fd78fc-2bb1-8eed-0b64-55cb3db71664@gmail.com>
Date:   Tue, 3 Jan 2023 14:55:22 +0200
From:   Tariq Toukan <ttoukan.linux@...il.com>
To:     Andy Gospodarek <andrew.gospodarek@...adcom.com>, ast@...nel.org,
        daniel@...earbox.net, davem@...emloft.net, kuba@...nel.org,
        hawk@...nel.org, john.fastabend@...il.com, andrii@...nel.org,
        kafai@...com, songliubraving@...com, yhs@...com,
        kpsingh@...nel.org, toke@...hat.com, lorenzo.bianconi@...hat.com,
        netdev@...r.kernel.org, bpf@...r.kernel.org,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc:     Andy Gospodarek <gospo@...adcom.com>,
        Lorenzo Bianconi <lorenzo@...nel.org>, gal@...dia.com,
        Saeed Mahameed <saeedm@...dia.com>, tariqt@...dia.com
Subject: Re: [PATCH net-next v2] samples/bpf: fixup some tools to be able to
 support xdp multibuffer



On 21/06/2022 20:54, Andy Gospodarek wrote:
> This changes the section name for the bpf program embedded in these
> files to "xdp.frags" to allow the programs to be loaded on drivers that
> are using an MTU greater than PAGE_SIZE.  Rather than directly accessing
> the buffers, the packet data is now accessed via xdp helper functions to
> provide an example for those who may need to write more complex
> programs.
> 
> v2: remove new unnecessary variable
> 

Hi,

I'm trying to understand if there are any assumptions/requirements on 
the length of the xdp_buf linear part when passed to XDP multi-buf programs?
Can the linear part be empty, with all data residing in the fragments? 
Is it valid?

Per the proposed pattern below (calling bpf_xdp_load_bytes() to memcpy 
packet data into a local buffer), no such assumption is required, and an 
xdp_buf created by the driver with an empty linear part is valid.

However, in the _xdp_tx_iptunnel example program, it fails (returns 
XDP_DROP) in case the headers are not in the linear part.

Regards,
Tariq

> Signed-off-by: Andy Gospodarek <gospo@...adcom.com>
> Acked-by: John Fastabend <john.fastabend@...il.com>
> Acked-by: Lorenzo Bianconi <lorenzo@...nel.org>
> ---
>   samples/bpf/xdp1_kern.c            | 11 ++++++++---
>   samples/bpf/xdp2_kern.c            | 11 ++++++++---
>   samples/bpf/xdp_tx_iptunnel_kern.c |  2 +-
>   3 files changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/samples/bpf/xdp1_kern.c b/samples/bpf/xdp1_kern.c
> index f0c5d95084de..0a5c704badd0 100644
> --- a/samples/bpf/xdp1_kern.c
> +++ b/samples/bpf/xdp1_kern.c
> @@ -39,11 +39,13 @@ static int parse_ipv6(void *data, u64 nh_off, void *data_end)
>   	return ip6h->nexthdr;
>   }
>   
> -SEC("xdp1")
> +#define XDPBUFSIZE	64
> +SEC("xdp.frags")
>   int xdp_prog1(struct xdp_md *ctx)
>   {
> -	void *data_end = (void *)(long)ctx->data_end;
> -	void *data = (void *)(long)ctx->data;
> +	__u8 pkt[XDPBUFSIZE] = {};
> +	void *data_end = &pkt[XDPBUFSIZE-1];
> +	void *data = pkt;
>   	struct ethhdr *eth = data;
>   	int rc = XDP_DROP;
>   	long *value;
> @@ -51,6 +53,9 @@ int xdp_prog1(struct xdp_md *ctx)
>   	u64 nh_off;
>   	u32 ipproto;
>   
> +	if (bpf_xdp_load_bytes(ctx, 0, pkt, sizeof(pkt)))
> +		return rc;
> +
>   	nh_off = sizeof(*eth);
>   	if (data + nh_off > data_end)
>   		return rc;
> diff --git a/samples/bpf/xdp2_kern.c b/samples/bpf/xdp2_kern.c
> index d8a64ab077b0..3332ba6bb95f 100644
> --- a/samples/bpf/xdp2_kern.c
> +++ b/samples/bpf/xdp2_kern.c
> @@ -55,11 +55,13 @@ static int parse_ipv6(void *data, u64 nh_off, void *data_end)
>   	return ip6h->nexthdr;
>   }
>   
> -SEC("xdp1")
> +#define XDPBUFSIZE	64
> +SEC("xdp.frags")
>   int xdp_prog1(struct xdp_md *ctx)
>   {
> -	void *data_end = (void *)(long)ctx->data_end;
> -	void *data = (void *)(long)ctx->data;
> +	__u8 pkt[XDPBUFSIZE] = {};
> +	void *data_end = &pkt[XDPBUFSIZE-1];
> +	void *data = pkt;
>   	struct ethhdr *eth = data;
>   	int rc = XDP_DROP;
>   	long *value;
> @@ -67,6 +69,9 @@ int xdp_prog1(struct xdp_md *ctx)
>   	u64 nh_off;
>   	u32 ipproto;
>   
> +	if (bpf_xdp_load_bytes(ctx, 0, pkt, sizeof(pkt)))
> +		return rc;
> +
>   	nh_off = sizeof(*eth);
>   	if (data + nh_off > data_end)
>   		return rc;
> diff --git a/samples/bpf/xdp_tx_iptunnel_kern.c b/samples/bpf/xdp_tx_iptunnel_kern.c
> index 575d57e4b8d6..0e2bca3a3fff 100644
> --- a/samples/bpf/xdp_tx_iptunnel_kern.c
> +++ b/samples/bpf/xdp_tx_iptunnel_kern.c
> @@ -212,7 +212,7 @@ static __always_inline int handle_ipv6(struct xdp_md *xdp)
>   	return XDP_TX;
>   }
>   
> -SEC("xdp_tx_iptunnel")
> +SEC("xdp.frags")
>   int _xdp_tx_iptunnel(struct xdp_md *xdp)
>   {
>   	void *data_end = (void *)(long)xdp->data_end;