netdev - Re: [PATCH bpf-next 12/16] libbpf: Add egress XDP support

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:   Tue, 21 Apr 2020 12:20:16 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     David Ahern <dsahern@...nel.org>, netdev@...r.kernel.org
Cc:     davem@...emloft.net, kuba@...nel.org,
        prashantbhole.linux@...il.com, jasowang@...hat.com,
        brouer@...hat.com, toshiaki.makita1@...il.com,
        daniel@...earbox.net, john.fastabend@...il.com, ast@...nel.org,
        kafai@...com, songliubraving@...com, yhs@...com, andriin@...com,
        dsahern@...il.com, David Ahern <dahern@...italocean.com>
Subject: Re: [PATCH bpf-next 12/16] libbpf: Add egress XDP support

David Ahern <dsahern@...nel.org> writes:

> From: David Ahern <dahern@...italocean.com>
>
> Patch adds egress XDP support in libbpf.
>
> New section name hint, xdp_egress, is added to set expected attach
> type at program load. Programs can use xdp_egress as the prefix in
> the SEC statement to load the program with the BPF_XDP_EGRESS
> attach type set.
>
> egress is added to bpf_xdp_set_link_opts to specify egress type for
> use with bpf_set_link_xdp_fd_opts. Update library side to check
> for flag and set nla_type to IFLA_XDP_EGRESS.
>
> Add egress version of bpf_get_link_xdp* info and id apis with core
> code refactored to handle both rx and tx paths.
>
> Signed-off-by: Prashant Bhole <prashantbhole.linux@...il.com>
> Co-developed-by: David Ahern <dahern@...italocean.com>
> Signed-off-by: David Ahern <dahern@...italocean.com>
> ---
>  tools/lib/bpf/libbpf.c   |  2 ++
>  tools/lib/bpf/libbpf.h   |  9 +++++-
>  tools/lib/bpf/libbpf.map |  2 ++
>  tools/lib/bpf/netlink.c  | 63 +++++++++++++++++++++++++++++++++++-----
>  4 files changed, 67 insertions(+), 9 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 8f480e29a6b0..32fc970495d9 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -6366,6 +6366,8 @@ static const struct bpf_sec_def section_defs[] = {
>  		.is_attach_btf = true,
>  		.expected_attach_type = BPF_LSM_MAC,
>  		.attach_fn = attach_lsm),
> +	BPF_EAPROG_SEC("xdp_egress",		BPF_PROG_TYPE_XDP,
> +						BPF_XDP_EGRESS),
>  	BPF_PROG_SEC("xdp",			BPF_PROG_TYPE_XDP),
>  	BPF_PROG_SEC("perf_event",		BPF_PROG_TYPE_PERF_EVENT),
>  	BPF_PROG_SEC("lwt_in",			BPF_PROG_TYPE_LWT_IN),
> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
> index f1dacecb1619..3feb1242f78e 100644
> --- a/tools/lib/bpf/libbpf.h
> +++ b/tools/lib/bpf/libbpf.h
> @@ -453,14 +453,16 @@ struct xdp_link_info {
>  	__u32 drv_prog_id;
>  	__u32 hw_prog_id;
>  	__u32 skb_prog_id;
> +	__u32 egress_core_prog_id;
>  	__u8 attach_mode;
>  };
>  
>  struct bpf_xdp_set_link_opts {
>  	size_t sz;
>  	int old_fd;
> +	__u8  egress;
>  };
> -#define bpf_xdp_set_link_opts__last_field old_fd
> +#define bpf_xdp_set_link_opts__last_field egress
>  
>  LIBBPF_API int bpf_set_link_xdp_fd(int ifindex, int fd, __u32 flags);
>  LIBBPF_API int bpf_set_link_xdp_fd_opts(int ifindex, int fd, __u32 flags,
> @@ -468,6 +470,11 @@ LIBBPF_API int bpf_set_link_xdp_fd_opts(int ifindex, int fd, __u32 flags,
>  LIBBPF_API int bpf_get_link_xdp_id(int ifindex, __u32 *prog_id, __u32 flags);
>  LIBBPF_API int bpf_get_link_xdp_info(int ifindex, struct xdp_link_info *info,
>  				     size_t info_size, __u32 flags);
> +LIBBPF_API int bpf_get_link_xdp_egress_id(int ifindex, __u32 *prog_id,
> +					  __u32 flags);
> +LIBBPF_API int bpf_get_link_xdp_egress_info(int ifindex,
> +					    struct xdp_link_info *info,
> +					    size_t info_size, __u32 flags);

Isn't the kernel returning both program types in the same message when
dumping an interface? So do we really need a separate getter instead of
just populating xdp_link_info with the egress ID in the existing getter?

-Toke