Packet access from bpf_perf_event_output

Packet access from bpf_perf_event_output

[Zvi Effron]

Hi XDPeople!

In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
bpf_perf_event_output says:

/*
 * Note that this helper is not restricted to tracing use cases
 * and can be used with programs attached to TC or XDP as well,
 * where it allows for passing data to user space listeners. Data
 * can be:
 *
 * * Only custom structs,
 * * Only the packet payload, or
 * * A combination of both.
 */

This seems to imply that for both TC and XDP, the packet can be used
for passing data. When I try this, the verifier rejects the program
with "helper access to the packet is not allowed". Looking through the
kernel it doesn't look like bpf_perf_output_event has been tagged with
the appropriate metadata to allow it to access the packet structure,
either for TC or for XDP. Neither bpf_skb_event_output_proto nor
bpf_xdp_event_output_proto have pkt_acess set to true. Is the
documentation incorrect, should that metadata be updated to allow
packet access, or is there something I'm missing?

Thank you!
--Zvi

Re: Packet access from bpf_perf_event_output

[Y Song]

On Sun, Jun 17, 2018 at 6:07 PM, Zvi Effron <zeffron@riotgames.com> wrote:
> Hi XDPeople!
>
> In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
> bpf_perf_event_output says:
>
> /*
>  * Note that this helper is not restricted to tracing use cases
>  * and can be used with programs attached to TC or XDP as well,
>  * where it allows for passing data to user space listeners. Data
>  * can be:
>  *
>  * * Only custom structs,
>  * * Only the packet payload, or
>  * * A combination of both.
>  */
>
> This seems to imply that for both TC and XDP, the packet can be used
> for passing data. When I try this, the verifier rejects the program
> with "helper access to the packet is not allowed". Looking through the
> kernel it doesn't look like bpf_perf_output_event has been tagged with
> the appropriate metadata to allow it to access the packet structure,
> either for TC or for XDP. Neither bpf_skb_event_output_proto nor

The implementation is in net/core/filter.c

static const struct bpf_func_proto *
xdp_func_proto(enum bpf_func_id func_id, const struct bpf_prog *prog)
{
        switch (func_id) {
        case BPF_FUNC_perf_event_output:
                return &bpf_xdp_event_output_proto;
......

BPF_CALL_5(bpf_xdp_event_output, struct xdp_buff *, xdp, struct bpf_map *, map,
           u64, flags, void *, meta, u64, meta_size)
{
        u64 xdp_size = (flags & BPF_F_CTXLEN_MASK) >> 32;

        if (unlikely(flags & ~(BPF_F_CTXLEN_MASK | BPF_F_INDEX_MASK)))
                return -EINVAL;
        if (unlikely(xdp_size > (unsigned long)(xdp->data_end - xdp->data)))
                return -EFAULT;

        return bpf_event_output(map, flags, meta, meta_size, xdp->data,
                                xdp_size, bpf_xdp_copy);
}

static const struct bpf_func_proto bpf_xdp_event_output_proto = {
        .func           = bpf_xdp_event_output,
        .gpl_only       = true,
        .ret_type       = RET_INTEGER,
        .arg1_type      = ARG_PTR_TO_CTX,
        .arg2_type      = ARG_CONST_MAP_PTR,
        .arg3_type      = ARG_ANYTHING,
        .arg4_type      = ARG_PTR_TO_MEM,
        .arg5_type      = ARG_CONST_SIZE_OR_ZERO,
};

Both tracing and networking uses the same func id
BPF_FUNC_perf_event_output, but depending on program type,
the implementation of the helper is different.

> bpf_xdp_event_output_proto have pkt_acess set to true. Is the
> documentation incorrect, should that metadata be updated to allow
> packet access, or is there something I'm missing?
>
> Thank you!
> --Zvi

Re: Packet access from bpf_perf_event_output

[Jesper Dangaard Brouer]

On Sun, 17 Jun 2018 18:07:02 -0700
Zvi Effron <zeffron@riotgames.com> wrote:

> Hi XDPeople!
> 
> In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
> bpf_perf_event_output says:
> 
> /*
>  * Note that this helper is not restricted to tracing use cases
>  * and can be used with programs attached to TC or XDP as well,
>  * where it allows for passing data to user space listeners. Data
>  * can be:
>  *
>  * * Only custom structs,
>  * * Only the packet payload, or
>  * * A combination of both.
>  */
> 
> This seems to imply that for both TC and XDP, the packet can be used
> for passing data. When I try this, the verifier rejects the program
> with "helper access to the packet is not allowed". Looking through the
> kernel it doesn't look like bpf_perf_output_event has been tagged with
> the appropriate metadata to allow it to access the packet structure,
> either for TC or for XDP. Neither bpf_skb_event_output_proto nor
> bpf_xdp_event_output_proto have pkt_acess set to true. Is the
> documentation incorrect, should that metadata be updated to allow
> packet access, or is there something I'm missing?

Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that
implement this (but it didn't reach the merge window).  Thus, I assume
that this works...

 http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

Re: Packet access from bpf_perf_event_output

[Zvi Effron]

On Mon, Jun 18, 2018 at 12:41 AM Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Sun, 17 Jun 2018 18:07:02 -0700
> Zvi Effron <zeffron@riotgames.com> wrote:
>
> > Hi XDPeople!
> >
> > In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
> > bpf_perf_event_output says:
> >
> > /*
> >  * Note that this helper is not restricted to tracing use cases
> >  * and can be used with programs attached to TC or XDP as well,
> >  * where it allows for passing data to user space listeners. Data
> >  * can be:
> >  *
> >  * * Only custom structs,
> >  * * Only the packet payload, or
> >  * * A combination of both.
> >  */
> >
> > This seems to imply that for both TC and XDP, the packet can be used
> > for passing data. When I try this, the verifier rejects the program
> > with "helper access to the packet is not allowed". Looking through the
> > kernel it doesn't look like bpf_perf_output_event has been tagged with
> > the appropriate metadata to allow it to access the packet structure,
> > either for TC or for XDP. Neither bpf_skb_event_output_proto nor
> > bpf_xdp_event_output_proto have pkt_acess set to true. Is the
> > documentation incorrect, should that metadata be updated to allow
> > packet access, or is there something I'm missing?
>
> Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that
> implement this (but it didn't reach the merge window).  Thus, I assume
> that this works...
>
>  http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau

Thank you for the example. I was trying to pass the packet as the
event metadata, but it looks like the correct way is to simply pass
the length as the upper 32 bits of the flags. Might be beneficial to
update the documentation in bpf.h to say that instead of just having
some samples with comments. But that example in the samples folder
with the comment explaining the flags in more detail is super useful.

Interestingly, even without trying that, I'm now getting ENOTSUPP even
if continue outputting the string I was before without any packet
data. As far as I can tell, that means I'm somehow hitting the
implementation of bpf_perf_output() in kernel/bpf/core.c instead of
the one in kernel/trace/bpf_trace.c. I'm not sure what changed as I
was able to emit events before. I've tried rebuilding my VM to negate
any changes made by installing bcc (I'm using Fedora-29 from rawhide,
last known good from 2018-06-04).

I'll keep investigating, but if anyone has any ideas, they'd be appreciated.

Thank you!
--Zvi

> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer

Re: Packet access from bpf_perf_event_output

[Toke Høiland-Jørgensen]

Zvi Effron <zeffron@riotgames.com> writes:

> On Mon, Jun 18, 2018 at 12:41 AM Jesper Dangaard Brouer
> <brouer@redhat.com> wrote:
>>
>> On Sun, 17 Jun 2018 18:07:02 -0700
>> Zvi Effron <zeffron@riotgames.com> wrote:
>>
>> > Hi XDPeople!
>> >
>> > In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
>> > bpf_perf_event_output says:
>> >
>> > /*
>> >  * Note that this helper is not restricted to tracing use cases
>> >  * and can be used with programs attached to TC or XDP as well,
>> >  * where it allows for passing data to user space listeners. Data
>> >  * can be:
>> >  *
>> >  * * Only custom structs,
>> >  * * Only the packet payload, or
>> >  * * A combination of both.
>> >  */
>> >
>> > This seems to imply that for both TC and XDP, the packet can be used
>> > for passing data. When I try this, the verifier rejects the program
>> > with "helper access to the packet is not allowed". Looking through the
>> > kernel it doesn't look like bpf_perf_output_event has been tagged with
>> > the appropriate metadata to allow it to access the packet structure,
>> > either for TC or for XDP. Neither bpf_skb_event_output_proto nor
>> > bpf_xdp_event_output_proto have pkt_acess set to true. Is the
>> > documentation incorrect, should that metadata be updated to allow
>> > packet access, or is there something I'm missing?
>>
>> Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that
>> implement this (but it didn't reach the merge window).  Thus, I assume
>> that this works...
>>
>>  http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau
>
> Thank you for the example. I was trying to pass the packet as the
> event metadata, but it looks like the correct way is to simply pass
> the length as the upper 32 bits of the flags. Might be beneficial to
> update the documentation in bpf.h to say that instead of just having
> some samples with comments. But that example in the samples folder
> with the comment explaining the flags in more detail is super useful.
>
> Interestingly, even without trying that, I'm now getting ENOTSUPP even
> if continue outputting the string I was before without any packet
> data. As far as I can tell, that means I'm somehow hitting the
> implementation of bpf_perf_output() in kernel/bpf/core.c instead of
> the one in kernel/trace/bpf_trace.c. I'm not sure what changed as I
> was able to emit events before. I've tried rebuilding my VM to negate
> any changes made by installing bcc (I'm using Fedora-29 from rawhide,
> last known good from 2018-06-04).
>
> I'll keep investigating, but if anyone has any ideas, they'd be
> appreciated.

Are you passing BPF_F_CURRENT_CPU in flags from XDP? Perf does not
support sending messages to perf fds that are bound to a different CPU.
And since you don't control which CPU the XDP program is run on (unless
you pin all RXQs to the same CPU), you need to handle this.

BPF_F_CURRENT_CPU makes perf index the map of perf fds by the CPU num,
so you'll need to fill the map with as many fds as you have CPUs. The
userspace component of the example will do this. I guess I should resend
the patch now that rc1 is out...

-Toke

Re: Packet access from bpf_perf_event_output

[Zvi Effron]

On Mon, Jun 18, 2018 at 3:47 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>
> Zvi Effron <zeffron@riotgames.com> writes:
>
> > On Mon, Jun 18, 2018 at 12:41 AM Jesper Dangaard Brouer
> > <brouer@redhat.com> wrote:
> >>
> >> On Sun, 17 Jun 2018 18:07:02 -0700
> >> Zvi Effron <zeffron@riotgames.com> wrote:
> >>
> >> > Hi XDPeople!
> >> >
> >> > In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
> >> > bpf_perf_event_output says:
> >> >
> >> > /*
> >> >  * Note that this helper is not restricted to tracing use cases
> >> >  * and can be used with programs attached to TC or XDP as well,
> >> >  * where it allows for passing data to user space listeners. Data
> >> >  * can be:
> >> >  *
> >> >  * * Only custom structs,
> >> >  * * Only the packet payload, or
> >> >  * * A combination of both.
> >> >  */
> >> >
> >> > This seems to imply that for both TC and XDP, the packet can be used
> >> > for passing data. When I try this, the verifier rejects the program
> >> > with "helper access to the packet is not allowed". Looking through the
> >> > kernel it doesn't look like bpf_perf_output_event has been tagged with
> >> > the appropriate metadata to allow it to access the packet structure,
> >> > either for TC or for XDP. Neither bpf_skb_event_output_proto nor
> >> > bpf_xdp_event_output_proto have pkt_acess set to true. Is the
> >> > documentation incorrect, should that metadata be updated to allow
> >> > packet access, or is there something I'm missing?
> >>
> >> Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that
> >> implement this (but it didn't reach the merge window).  Thus, I assume
> >> that this works...
> >>
> >>  http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau
> >
> > Thank you for the example. I was trying to pass the packet as the
> > event metadata, but it looks like the correct way is to simply pass
> > the length as the upper 32 bits of the flags. Might be beneficial to
> > update the documentation in bpf.h to say that instead of just having
> > some samples with comments. But that example in the samples folder
> > with the comment explaining the flags in more detail is super useful.
> >
> > Interestingly, even without trying that, I'm now getting ENOTSUPP even
> > if continue outputting the string I was before without any packet
> > data. As far as I can tell, that means I'm somehow hitting the
> > implementation of bpf_perf_output() in kernel/bpf/core.c instead of
> > the one in kernel/trace/bpf_trace.c. I'm not sure what changed as I
> > was able to emit events before. I've tried rebuilding my VM to negate
> > any changes made by installing bcc (I'm using Fedora-29 from rawhide,
> > last known good from 2018-06-04).
> >
> > I'll keep investigating, but if anyone has any ideas, they'd be
> > appreciated.
>
> Are you passing BPF_F_CURRENT_CPU in flags from XDP? Perf does not
> support sending messages to perf fds that are bound to a different CPU.
> And since you don't control which CPU the XDP program is run on (unless
> you pin all RXQs to the same CPU), you need to handle this.
>
> BPF_F_CURRENT_CPU makes perf index the map of perf fds by the CPU num,
> so you'll need to fill the map with as many fds as you have CPUs. The
> userspace component of the example will do this. I guess I should resend
> the patch now that rc1 is out...

That's exactly what it was. I'd forgotten I'd recently bumped the CPU
count on the VM to 2. XDP program was running on CPU 1, but I'd only
configured the map to hold an fd for CPU 0.

Thanks for all of the help, everyone!

--Zvi

> -Toke

Re: Packet access from bpf_perf_event_output

[Toke Høiland-Jørgensen]

Zvi Effron <zeffron@riotgames.com> writes:

> On Mon, Jun 18, 2018 at 3:47 AM Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>
>> Zvi Effron <zeffron@riotgames.com> writes:
>>
>> > On Mon, Jun 18, 2018 at 12:41 AM Jesper Dangaard Brouer
>> > <brouer@redhat.com> wrote:
>> >>
>> >> On Sun, 17 Jun 2018 18:07:02 -0700
>> >> Zvi Effron <zeffron@riotgames.com> wrote:
>> >>
>> >> > Hi XDPeople!
>> >> >
>> >> > In /include/uapi/linux/bpf.h, (in 4.18-rc1) the comment describing
>> >> > bpf_perf_event_output says:
>> >> >
>> >> > /*
>> >> >  * Note that this helper is not restricted to tracing use cases
>> >> >  * and can be used with programs attached to TC or XDP as well,
>> >> >  * where it allows for passing data to user space listeners. Data
>> >> >  * can be:
>> >> >  *
>> >> >  * * Only custom structs,
>> >> >  * * Only the packet payload, or
>> >> >  * * A combination of both.
>> >> >  */
>> >> >
>> >> > This seems to imply that for both TC and XDP, the packet can be used
>> >> > for passing data. When I try this, the verifier rejects the program
>> >> > with "helper access to the packet is not allowed". Looking through the
>> >> > kernel it doesn't look like bpf_perf_output_event has been tagged with
>> >> > the appropriate metadata to allow it to access the packet structure,
>> >> > either for TC or for XDP. Neither bpf_skb_event_output_proto nor
>> >> > bpf_xdp_event_output_proto have pkt_acess set to true. Is the
>> >> > documentation incorrect, should that metadata be updated to allow
>> >> > packet access, or is there something I'm missing?
>> >>
>> >> Toke (Cc'ed) recently posted a samples/bpf/ program to the kernel that
>> >> implement this (but it didn't reach the merge window).  Thus, I assume
>> >> that this works...
>> >>
>> >>  http://lkml.kernel.org/r/152830792912.21161.3609946361971472545.stgit@alrua-kau
>> >
>> > Thank you for the example. I was trying to pass the packet as the
>> > event metadata, but it looks like the correct way is to simply pass
>> > the length as the upper 32 bits of the flags. Might be beneficial to
>> > update the documentation in bpf.h to say that instead of just having
>> > some samples with comments. But that example in the samples folder
>> > with the comment explaining the flags in more detail is super useful.
>> >
>> > Interestingly, even without trying that, I'm now getting ENOTSUPP even
>> > if continue outputting the string I was before without any packet
>> > data. As far as I can tell, that means I'm somehow hitting the
>> > implementation of bpf_perf_output() in kernel/bpf/core.c instead of
>> > the one in kernel/trace/bpf_trace.c. I'm not sure what changed as I
>> > was able to emit events before. I've tried rebuilding my VM to negate
>> > any changes made by installing bcc (I'm using Fedora-29 from rawhide,
>> > last known good from 2018-06-04).
>> >
>> > I'll keep investigating, but if anyone has any ideas, they'd be
>> > appreciated.
>>
>> Are you passing BPF_F_CURRENT_CPU in flags from XDP? Perf does not
>> support sending messages to perf fds that are bound to a different CPU.
>> And since you don't control which CPU the XDP program is run on (unless
>> you pin all RXQs to the same CPU), you need to handle this.
>>
>> BPF_F_CURRENT_CPU makes perf index the map of perf fds by the CPU num,
>> so you'll need to fill the map with as many fds as you have CPUs. The
>> userspace component of the example will do this. I guess I should resend
>> the patch now that rc1 is out...
>
> That's exactly what it was. I'd forgotten I'd recently bumped the CPU
> count on the VM to 2. XDP program was running on CPU 1, but I'd only
> configured the map to hold an fd for CPU 0.

Awesome! And yeah, that is an annoying bug to have to track down; I ran
into the same thing when writing the example. Which is why I immediately
thought about it when you mentioned the symptom ;)

> Thanks for all of the help, everyone!

You're very welcome!

-Toke