All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Vincent Li <mchun.li@gmail.com>
Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
	xdp-newbies@vger.kernel.org, daniel@iogearbox.net,
	andriin@fb.com, dsahern@gmail.com
Subject: Re: XDP invalid memory access
Date: Fri, 17 Jan 2020 12:07:02 +0100	[thread overview]
Message-ID: <87blr2qr3d.fsf@toke.dk> (raw)
In-Reply-To: <alpine.OSX.2.21.2001161059220.5400@jiadeimac.local>

Vincent Li <mchun.li@gmail.com> writes:

> On Thu, 16 Jan 2020, Toke Høiland-Jørgensen wrote:
>
> Hi Toke,
>
>> 
>> You could also try the xdp-loader in xdp-tools:
>> https://github.com/xdp-project/xdp-tools
>> 
>> It's somewhat basic still, but should be able to at least load a basic
>> program - please file a bug report if it fails.
>
> I tried the xdp-tools xdp-loader, when the optlen is global variable, I 
> got:
> # xdp-loader load enp3s0 tcp_option.o
> Couldn't load BPF program: Relocation failed
>
> if I move the optlen, i variable to local variable, I got:
>
> # xdp-loader load enp3s0 tcp_option.o
> Couldn't load eBPF object: Invalid argument(-22)

OK, I tried this, and there were a couple of issues:

- The xdp-loader didn't set the BPF program type to XDP, and since your
  section name doesn't have an xdp_ prefix libbpf couldn't auto-detect
  it. I've pushed a fix for this to the xdp-tools repo so the loader
  will always set the program type to XDP now.

- There are a couple of bugs in your program:

First, when compiling with warnings turned on, I get this:

tcp_options.c:64:29: error: variable 'op' is uninitialized when used here [-Werror,-Wuninitialized]
                        if (op[i] == TCPOPT_EOL ) {
                            ^~
tcp_options.c:43:23: note: initialize the variable 'op' to silence this warning
        const __u8 *op;
                      ^
                       = 0

after fixing that (adding this line after the optlen = assignment):

                op = (const __u8 *)(tcphdr + 1);

the verifier then complains about out-of-bounds reading of the packet
data (pass -vv to xdp-loader to get the full debug output from libbpf).
You are not checking that the op pointer doesn't read out-of-bounds.

I fixed that by adding a couple of bounds checks inside the for loop.
The whole thing now looks like this:

                optlen = tcphdr->doff*4 - sizeof(*tcphdr);
                op = (const __u8 *)(tcphdr + 1);
                for (i = 0; i < optlen; ) {
                        if ((void *)op + i + 1 > data_end)
                                return 0;
                        if (op[i] == TCPOPT_EOL ) {
                                char fmt[] = "XDP: tcp source : %d tcp option eol\n";
                                bpf_trace_printk(fmt, sizeof(fmt), (int)tcphdr->source);
                                return 1;
                        }
                        if (op[i] < 2)
                                i++;
                        else
                                i += ((void *)op + 2 < data_end && op[i+1]) ? : 1;
                }


With this, I can successfully load the program using xdp-loader. Turning
the variables back into globals still doesn't work, but I think that
error message should be fairly obvious:

libbpf: invalid relo for 'op' in special section 0xfff2; forgot to initialize global var?..

-Toke

  parent reply	other threads:[~2020-01-17 11:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 22:11 XDP invalid memory access Vincent Li
2020-01-15 22:21 ` Toke Høiland-Jørgensen
2020-01-15 22:31   ` Vincent Li
2020-01-16  0:40     ` David Ahern
2020-01-16  1:34       ` Vincent Li
2020-01-16  3:19         ` Vincent Li
2020-01-16  4:22           ` David Ahern
2020-01-16  2:24 ` Maciej Fijalkowski
2020-01-16  9:45   ` Toke Høiland-Jørgensen
2020-01-16 19:06     ` Vincent Li
2020-01-16 19:20       ` Andrii Nakryiko
2020-01-16 22:10         ` Vincent Li
2020-01-17 11:07       ` Toke Høiland-Jørgensen [this message]
2020-01-17 18:14         ` Vincent Li
2020-01-16 17:44   ` Vincent Li
2020-01-16 18:58   ` Vincent Li

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87blr2qr3d.fsf@toke.dk \
    --to=toke@redhat.com \
    --cc=andriin@fb.com \
    --cc=daniel@iogearbox.net \
    --cc=dsahern@gmail.com \
    --cc=maciej.fijalkowski@intel.com \
    --cc=mchun.li@gmail.com \
    --cc=xdp-newbies@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.