All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Alexei Starovoitov <ast@kernel.org>, bpf <bpf@vger.kernel.org>
Cc: Networking <netdev@vger.kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: BPFilter: bit size mismatch between bpfiter_umh and vmliux
Date: Tue, 28 Apr 2020 19:53:55 +0900	[thread overview]
Message-ID: <CAK7LNARHd0DXRLONf6vH_ghsYZjzoduzkixqNDpVqqPx0yHbHg@mail.gmail.com> (raw)

Hi.

I have a question about potential bit size
mismatch between vmlinux and bpfilter_umh.


net/bpfilter/bpfilter_umh is compiled for the
default machine bit of the compiler.
This may not match to the kernel bit size.


This happens in the following scenario.

GCC can be compiled as bi-arch.
If you use GCC that defaults to 64-bit,
you can give -m32 flag to produce the 32 bit code.

When you build the kernel for 32-bit, -m32 is
properly passed for building the kernel space objects.
However, it is missing while building the userspace
objects for bpfilter_umh.


For example, my build host is x86_64 Ubuntu.

If I build the kernel for i386
with CONFIG_BPFILTER_UMH=y,
the embedded bpfilter_umh is 64bit ELF.

You can reproduce it by the following command on the
mainline kernel.

masahiro@oscar:~/ref/linux$ make ARCH=i386 defconfig
masahiro@oscar:~/ref/linux$ scripts/config -e BPFILTER
masahiro@oscar:~/ref/linux$ scripts/config -e BPFILTER_UMH
masahiro@oscar:~/ref/linux$ make $(nproc) ARCH=i386
   ...
masahiro@oscar:~/ref/linux$ file vmlinux
vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically linked,
BuildID[sha1]=7ac691c67b4fe9b0cd46b45a2dc2d728d7d87686, not stripped
masahiro@oscar:~/ref/linux$ file net/bpfilter/bpfilter_umh
net/bpfilter/bpfilter_umh: ELF 64-bit LSB executable, x86-64, version
1 (GNU/Linux), statically linked,
BuildID[sha1]=baf1ffe26f4c030a99a945fc22924c8c559e60ac, for GNU/Linux
3.2.0, not stripped




At least, the build was successful,
but does this work at runtime?

If this is a bug, I can fix it cleanly.

I think the bit size of the user mode helper
should match to the kernel bit size. Is this correct?


I noticed this while I was working on userspace
build cleanups.
https://patchwork.kernel.org/patch/11505207/


-- 
Best Regards
Masahiro Yamada

             reply	other threads:[~2020-04-28 10:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28 10:53 Masahiro Yamada [this message]
2020-04-28 16:14 ` BPFilter: bit size mismatch between bpfiter_umh and vmliux Alexei Starovoitov
2020-05-01  4:05   ` Masahiro Yamada
2020-05-01  5:15     ` Alexei Starovoitov

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=CAK7LNARHd0DXRLONf6vH_ghsYZjzoduzkixqNDpVqqPx0yHbHg@mail.gmail.com \
    --to=masahiroy@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@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.