xdp-newbies.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Capture xdp packets in an fentry BPF hook
@ 2020-02-19 14:38 Eelco Chaudron
  2020-02-19 20:36 ` Alexei Starovoitov
  0 siblings, 1 reply; 6+ messages in thread
From: Eelco Chaudron @ 2020-02-19 14:38 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Xdp, bpf, Toke Høiland-Jørgensen, Jesper Dangaard Brouer

Hi Alexei at al.,

I'm getting closer to finally have an xdpdump tool that uses the bpf 
fentry/fexit tracepoints, but I ran into a final hurdle...

To stuff the packet into a perf ring I'll need to use the 
bpf_perf_event_output(), but unfortunately, this is a program of trace 
type, and not XDP so the packet data is not added automatically :(

Secondly even trying to pass the actual packet data as a reference to 
bpf_perf_event_output() will not work as the verifier wants the data to 
be on the fp.

Even worse, the trace program gets the XDP info not thought the ctx, but 
trough the fentry/fexit input value, i.e.:

	SEC("fentry/func")
	int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...

	struct net_device {
	    int ifindex;
	} __attribute__((preserve_access_index));

	struct xdp_rxq_info {
	    struct net_device *dev;
	    __u32 queue_index;
	} __attribute__((preserve_access_index));

	struct xdp_buff {
	    void *data;
	    void *data_end;
	    void *data_meta;
	    void *data_hard_start;
	    unsigned long handle;
	    struct xdp_rxq_info *rxq;
	} __attribute__((preserve_access_index));

Hence even trying to copy in bytes to a local buffer is not allowed by 
the verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;

Can you let me know how you envisioned a BPF entry hook to capture 
packets from XDP. Am I missing something, or is there something missing 
from the infrastructure?

Thanks,

Eelco

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Capture xdp packets in an fentry BPF hook
  2020-02-19 14:38 Capture xdp packets in an fentry BPF hook Eelco Chaudron
@ 2020-02-19 20:36 ` Alexei Starovoitov
  2020-02-19 22:14   ` Toke Høiland-Jørgensen
  2020-02-20 13:17   ` Eelco Chaudron
  0 siblings, 2 replies; 6+ messages in thread
From: Alexei Starovoitov @ 2020-02-19 20:36 UTC (permalink / raw)
  To: Eelco Chaudron
  Cc: Alexei Starovoitov, Xdp, bpf, Toke Høiland-Jørgensen,
	Jesper Dangaard Brouer

On Wed, Feb 19, 2020 at 03:38:40PM +0100, Eelco Chaudron wrote:
> Hi Alexei at al.,
> 
> I'm getting closer to finally have an xdpdump tool that uses the bpf
> fentry/fexit tracepoints, but I ran into a final hurdle...
> 
> To stuff the packet into a perf ring I'll need to use the
> bpf_perf_event_output(), but unfortunately, this is a program of trace type,
> and not XDP so the packet data is not added automatically :(
> 
> Secondly even trying to pass the actual packet data as a reference to
> bpf_perf_event_output() will not work as the verifier wants the data to be
> on the fp.
> 
> Even worse, the trace program gets the XDP info not thought the ctx, but
> trough the fentry/fexit input value, i.e.:
> 
> 	SEC("fentry/func")
> 	int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...
> 
> 	struct net_device {
> 	    int ifindex;
> 	} __attribute__((preserve_access_index));
> 
> 	struct xdp_rxq_info {
> 	    struct net_device *dev;
> 	    __u32 queue_index;
> 	} __attribute__((preserve_access_index));
> 
> 	struct xdp_buff {
> 	    void *data;
> 	    void *data_end;
> 	    void *data_meta;
> 	    void *data_hard_start;
> 	    unsigned long handle;
> 	    struct xdp_rxq_info *rxq;
> 	} __attribute__((preserve_access_index));
> 
> Hence even trying to copy in bytes to a local buffer is not allowed by the
> verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;
> 
> Can you let me know how you envisioned a BPF entry hook to capture packets
> from XDP. Am I missing something, or is there something missing from the
> infrastructure?

Tracing of XDP is missing a helper similar to bpf_skb_output() for skb.
Its first arg will be 'struct xdp_buff *' and .arg1_type = ARG_PTR_TO_BTF_ID
then it will work similar to bpf_skb_output() in progs/kfree_skb.c.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Capture xdp packets in an fentry BPF hook
  2020-02-19 20:36 ` Alexei Starovoitov
@ 2020-02-19 22:14   ` Toke Høiland-Jørgensen
  2020-02-19 22:20     ` Alexei Starovoitov
  2020-02-20 13:17   ` Eelco Chaudron
  1 sibling, 1 reply; 6+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-02-19 22:14 UTC (permalink / raw)
  To: Alexei Starovoitov, Eelco Chaudron
  Cc: Alexei Starovoitov, Xdp, bpf, Jesper Dangaard Brouer

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Wed, Feb 19, 2020 at 03:38:40PM +0100, Eelco Chaudron wrote:
>> Hi Alexei at al.,
>> 
>> I'm getting closer to finally have an xdpdump tool that uses the bpf
>> fentry/fexit tracepoints, but I ran into a final hurdle...
>> 
>> To stuff the packet into a perf ring I'll need to use the
>> bpf_perf_event_output(), but unfortunately, this is a program of trace type,
>> and not XDP so the packet data is not added automatically :(
>> 
>> Secondly even trying to pass the actual packet data as a reference to
>> bpf_perf_event_output() will not work as the verifier wants the data to be
>> on the fp.
>> 
>> Even worse, the trace program gets the XDP info not thought the ctx, but
>> trough the fentry/fexit input value, i.e.:
>> 
>> 	SEC("fentry/func")
>> 	int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...
>> 
>> 	struct net_device {
>> 	    int ifindex;
>> 	} __attribute__((preserve_access_index));
>> 
>> 	struct xdp_rxq_info {
>> 	    struct net_device *dev;
>> 	    __u32 queue_index;
>> 	} __attribute__((preserve_access_index));
>> 
>> 	struct xdp_buff {
>> 	    void *data;
>> 	    void *data_end;
>> 	    void *data_meta;
>> 	    void *data_hard_start;
>> 	    unsigned long handle;
>> 	    struct xdp_rxq_info *rxq;
>> 	} __attribute__((preserve_access_index));
>> 
>> Hence even trying to copy in bytes to a local buffer is not allowed by the
>> verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;
>> 
>> Can you let me know how you envisioned a BPF entry hook to capture packets
>> from XDP. Am I missing something, or is there something missing from the
>> infrastructure?
>
> Tracing of XDP is missing a helper similar to bpf_skb_output() for skb.
> Its first arg will be 'struct xdp_buff *' and .arg1_type = ARG_PTR_TO_BTF_ID
> then it will work similar to bpf_skb_output() in progs/kfree_skb.c.

What about freplace? Since that is also using the tracing
infrastructure, will the replacing program also be considered a tracing
program by the verifier? Or is it possible to load a program with an XDP
type, but still use it for freplace?

-Toke

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Capture xdp packets in an fentry BPF hook
  2020-02-19 22:14   ` Toke Høiland-Jørgensen
@ 2020-02-19 22:20     ` Alexei Starovoitov
  2020-02-19 22:34       ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 6+ messages in thread
From: Alexei Starovoitov @ 2020-02-19 22:20 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen
  Cc: Eelco Chaudron, Alexei Starovoitov, Xdp, bpf, Jesper Dangaard Brouer

On Wed, Feb 19, 2020 at 2:14 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>
> > On Wed, Feb 19, 2020 at 03:38:40PM +0100, Eelco Chaudron wrote:
> >> Hi Alexei at al.,
> >>
> >> I'm getting closer to finally have an xdpdump tool that uses the bpf
> >> fentry/fexit tracepoints, but I ran into a final hurdle...
> >>
> >> To stuff the packet into a perf ring I'll need to use the
> >> bpf_perf_event_output(), but unfortunately, this is a program of trace type,
> >> and not XDP so the packet data is not added automatically :(
> >>
> >> Secondly even trying to pass the actual packet data as a reference to
> >> bpf_perf_event_output() will not work as the verifier wants the data to be
> >> on the fp.
> >>
> >> Even worse, the trace program gets the XDP info not thought the ctx, but
> >> trough the fentry/fexit input value, i.e.:
> >>
> >>      SEC("fentry/func")
> >>      int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...
> >>
> >>      struct net_device {
> >>          int ifindex;
> >>      } __attribute__((preserve_access_index));
> >>
> >>      struct xdp_rxq_info {
> >>          struct net_device *dev;
> >>          __u32 queue_index;
> >>      } __attribute__((preserve_access_index));
> >>
> >>      struct xdp_buff {
> >>          void *data;
> >>          void *data_end;
> >>          void *data_meta;
> >>          void *data_hard_start;
> >>          unsigned long handle;
> >>          struct xdp_rxq_info *rxq;
> >>      } __attribute__((preserve_access_index));
> >>
> >> Hence even trying to copy in bytes to a local buffer is not allowed by the
> >> verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;
> >>
> >> Can you let me know how you envisioned a BPF entry hook to capture packets
> >> from XDP. Am I missing something, or is there something missing from the
> >> infrastructure?
> >
> > Tracing of XDP is missing a helper similar to bpf_skb_output() for skb.
> > Its first arg will be 'struct xdp_buff *' and .arg1_type = ARG_PTR_TO_BTF_ID
> > then it will work similar to bpf_skb_output() in progs/kfree_skb.c.
>
> What about freplace? Since that is also using the tracing
> infrastructure, will the replacing program also be considered a tracing
> program by the verifier? Or is it possible to load a program with an XDP
> type, but still use it for freplace?

Please see freplace example in progs/fexit_bpf2bpf.c
freplace is not a separate type of program.
It's not tracing and it's not networking.
It's an extension of the target program.
If target prog is xdp prog the extension will have access
to the same struct xdp_md and the same xdp helpers.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Capture xdp packets in an fentry BPF hook
  2020-02-19 22:20     ` Alexei Starovoitov
@ 2020-02-19 22:34       ` Toke Høiland-Jørgensen
  0 siblings, 0 replies; 6+ messages in thread
From: Toke Høiland-Jørgensen @ 2020-02-19 22:34 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Eelco Chaudron, Alexei Starovoitov, Xdp, bpf, Jesper Dangaard Brouer

Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:

> On Wed, Feb 19, 2020 at 2:14 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>>
>> Alexei Starovoitov <alexei.starovoitov@gmail.com> writes:
>>
>> > On Wed, Feb 19, 2020 at 03:38:40PM +0100, Eelco Chaudron wrote:
>> >> Hi Alexei at al.,
>> >>
>> >> I'm getting closer to finally have an xdpdump tool that uses the bpf
>> >> fentry/fexit tracepoints, but I ran into a final hurdle...
>> >>
>> >> To stuff the packet into a perf ring I'll need to use the
>> >> bpf_perf_event_output(), but unfortunately, this is a program of trace type,
>> >> and not XDP so the packet data is not added automatically :(
>> >>
>> >> Secondly even trying to pass the actual packet data as a reference to
>> >> bpf_perf_event_output() will not work as the verifier wants the data to be
>> >> on the fp.
>> >>
>> >> Even worse, the trace program gets the XDP info not thought the ctx, but
>> >> trough the fentry/fexit input value, i.e.:
>> >>
>> >>      SEC("fentry/func")
>> >>      int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...
>> >>
>> >>      struct net_device {
>> >>          int ifindex;
>> >>      } __attribute__((preserve_access_index));
>> >>
>> >>      struct xdp_rxq_info {
>> >>          struct net_device *dev;
>> >>          __u32 queue_index;
>> >>      } __attribute__((preserve_access_index));
>> >>
>> >>      struct xdp_buff {
>> >>          void *data;
>> >>          void *data_end;
>> >>          void *data_meta;
>> >>          void *data_hard_start;
>> >>          unsigned long handle;
>> >>          struct xdp_rxq_info *rxq;
>> >>      } __attribute__((preserve_access_index));
>> >>
>> >> Hence even trying to copy in bytes to a local buffer is not allowed by the
>> >> verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;
>> >>
>> >> Can you let me know how you envisioned a BPF entry hook to capture packets
>> >> from XDP. Am I missing something, or is there something missing from the
>> >> infrastructure?
>> >
>> > Tracing of XDP is missing a helper similar to bpf_skb_output() for skb.
>> > Its first arg will be 'struct xdp_buff *' and .arg1_type = ARG_PTR_TO_BTF_ID
>> > then it will work similar to bpf_skb_output() in progs/kfree_skb.c.
>>
>> What about freplace? Since that is also using the tracing
>> infrastructure, will the replacing program also be considered a tracing
>> program by the verifier? Or is it possible to load a program with an XDP
>> type, but still use it for freplace?
>
> Please see freplace example in progs/fexit_bpf2bpf.c
> freplace is not a separate type of program.
> It's not tracing and it's not networking.
> It's an extension of the target program.
> If target prog is xdp prog the extension will have access
> to the same struct xdp_md and the same xdp helpers.

Ah, great! It would seem I had not really looked at those examples,
other than to notice they were there. Thanks for the pointer, and sorry
for being dense! :)

-Toke

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Capture xdp packets in an fentry BPF hook
  2020-02-19 20:36 ` Alexei Starovoitov
  2020-02-19 22:14   ` Toke Høiland-Jørgensen
@ 2020-02-20 13:17   ` Eelco Chaudron
  1 sibling, 0 replies; 6+ messages in thread
From: Eelco Chaudron @ 2020-02-20 13:17 UTC (permalink / raw)
  To: Alexei Starovoitov
  Cc: Alexei Starovoitov, Xdp, bpf, Toke Høiland-Jørgensen,
	Jesper Dangaard Brouer



On 19 Feb 2020, at 21:36, Alexei Starovoitov wrote:

> On Wed, Feb 19, 2020 at 03:38:40PM +0100, Eelco Chaudron wrote:
>> Hi Alexei at al.,
>>
>> I'm getting closer to finally have an xdpdump tool that uses the bpf
>> fentry/fexit tracepoints, but I ran into a final hurdle...
>>
>> To stuff the packet into a perf ring I'll need to use the
>> bpf_perf_event_output(), but unfortunately, this is a program of 
>> trace type,
>> and not XDP so the packet data is not added automatically :(
>>
>> Secondly even trying to pass the actual packet data as a reference to
>> bpf_perf_event_output() will not work as the verifier wants the data 
>> to be
>> on the fp.
>>
>> Even worse, the trace program gets the XDP info not thought the ctx, 
>> but
>> trough the fentry/fexit input value, i.e.:
>>
>> 	SEC("fentry/func")
>> 	int BPF_PROG(trace_on_entry, struct xdp_buff *xdp)...
>>
>> 	struct net_device {
>> 	    int ifindex;
>> 	} __attribute__((preserve_access_index));
>>
>> 	struct xdp_rxq_info {
>> 	    struct net_device *dev;
>> 	    __u32 queue_index;
>> 	} __attribute__((preserve_access_index));
>>
>> 	struct xdp_buff {
>> 	    void *data;
>> 	    void *data_end;
>> 	    void *data_meta;
>> 	    void *data_hard_start;
>> 	    unsigned long handle;
>> 	    struct xdp_rxq_info *rxq;
>> 	} __attribute__((preserve_access_index));
>>
>> Hence even trying to copy in bytes to a local buffer is not allowed 
>> by the
>> verifier, i.e. __u8 *data = (u8 *)(long)xdp->data;
>>
>> Can you let me know how you envisioned a BPF entry hook to capture 
>> packets
>> from XDP. Am I missing something, or is there something missing from 
>> the
>> infrastructure?
>
> Tracing of XDP is missing a helper similar to bpf_skb_output() for 
> skb.
> Its first arg will be 'struct xdp_buff *' and .arg1_type = 
> ARG_PTR_TO_BTF_ID
> then it will work similar to bpf_skb_output() in progs/kfree_skb.c.

Thanks for clarifying the needs for a new helper. I will be on PTO next 
week but will work on a bpf_xdp_output() helper when I get back.

Cheers,

Eelco

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-02-20 13:17 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-19 14:38 Capture xdp packets in an fentry BPF hook Eelco Chaudron
2020-02-19 20:36 ` Alexei Starovoitov
2020-02-19 22:14   ` Toke Høiland-Jørgensen
2020-02-19 22:20     ` Alexei Starovoitov
2020-02-19 22:34       ` Toke Høiland-Jørgensen
2020-02-20 13:17   ` Eelco Chaudron

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).