All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rafael David Tinoco <rafaeldtinoco@ubuntu.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>,
	Vamsi Kodavanty <vamsi@araalinetworks.com>,
	bpf <bpf@vger.kernel.org>
Subject: Re: [BPF CO-RE clarification] Use CO-RE on older kernel versions.
Date: Wed, 17 Mar 2021 01:39:19 -0300	[thread overview]
Message-ID: <CFD47A17-D20D-49FB-A357-5476C8EE02AF@ubuntu.com> (raw)
In-Reply-To: <CAEf4BzYDNQwTBmd_gG5isqfy0JPrW+ticu=NUvqhvbYmLOWC-g@mail.gmail.com>

Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:

> On Wed, Mar 10, 2021 at 2:45 PM Rafael David Tinoco
> <rafaeldtinoco@ubuntu.com> wrote:
>>> From what I see all the CO-RE relocations applied successfully (even
>>> though all the offsets stayed the same, so presumably you compiled
>>> your BPF program with vmlinux.h from the exact same kernel you are
>>> running it on?). Are you sure that vmlinux image you are providing
>>> corresponds to the actual kernel you are running on?
>>
>> Yep, I have created the following:
>>
>> https://pastebin.ubuntu.com/p/h58YyNr4HR/
>
> Ok, I have no idea, tbh. Maybe `pahole -j` is subtly modifying vmlinux
> is some way (but then why would kernel start and only fail to
> load/verify your BPF program?). It's also clear that CO-RE is doing
> exactly the same instruction patching, so shouldn't be some invalid
> CO-RE relocation applied, I think. So no idea and not sure how to
> investigate this.
>
> But I think I'd never do `pahole -J` on actual vmlinux image you are
> going to run. It's much safer and more convenient to make a copy,
> generate .BTF and then extract just .BTF section into a small binary,
> which can be provided separately.
>

FOUND the cause of the issue...

Compiling the EXACT same kernel with different building scripts
(deb-pkg vs debian/rules in my case) resulted in a very similar
kernel (same .config, same autoconf.h, no visible changes).

Unfortunately one of the kernels worked fined (reading the BTF
extracted section OR same section within a vmlinux entire
file).. but the other did not.

Instrumenting this bad 4.15 kernel (out of debian/rules build)
I found that the following sanity checks took place in kernel:

bpf_check():

if (log->len_total < 128 || log->len_total > UINT_MAX >> 8 || !log->level  
|| !log->ubuf)

and a simple change in libbpf (mitigation of course):

   attr.log_buf = 0;
   attr.log_level = 0;
   attr.log_size = 0;

before

fd = sys_bpf_prog_load(&attr, sizeof(attr));

made the code to also run in this second kernel (built with the
debian/rules building scripts):

https://pastebin.ubuntu.com/p/scJDM3D9Zr/

Now I still have to discover why log_buf is miss-behaving in this
kernel being built with debian/rules* scripts and not with the
vanilla building scripts (despite config file being the same).

(FYIO, documenting it here for others also)...




  reply	other threads:[~2021-03-17  4:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06 18:02 [BPF CO-RE clarification] Use CO-RE on older kernel versions Vamsi Kodavanty
2021-01-06 23:55 ` Andrii Nakryiko
2021-01-07 18:12   ` Vamsi Kodavanty
2021-01-07 18:52     ` Andrii Nakryiko
2021-01-07 22:45       ` Vamsi Kodavanty
2021-01-07 23:32         ` Andrii Nakryiko
2021-01-08  0:16           ` Vamsi Kodavanty
2021-01-08  1:31             ` Vamsi Kodavanty
2021-03-03 18:14               ` Rafael David Tinoco
2021-03-04  7:05                 ` Andrii Nakryiko
2021-03-04 13:10                   ` Arnaldo Carvalho de Melo
2021-03-05  6:32                   ` Rafael David Tinoco
     [not found]                     ` <67E3C788-2835-4793-8A9C-51C5D807C294@ubuntu.com>
2021-03-10  6:00                       ` Fwd: " Rafael David Tinoco
2021-03-10 19:19                       ` Andrii Nakryiko
2021-03-10 22:45                         ` Rafael David Tinoco
2021-03-12 18:36                           ` Andrii Nakryiko
2021-03-17  4:39                             ` Rafael David Tinoco [this message]
2021-03-17 14:31                               ` Rafael David Tinoco
2021-03-19  4:36                                 ` Andrii Nakryiko
2021-03-19  4:42                                   ` Rafael David Tinoco

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=CFD47A17-D20D-49FB-A357-5476C8EE02AF@ubuntu.com \
    --to=rafaeldtinoco@ubuntu.com \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=vamsi@araalinetworks.com \
    /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.