Re: BPFilter: bit size mismatch between bpfiter_umh and vmliux
From: Alexei Starovoitov
Date: Tue Apr 28 2020 - 12:14:30 EST
On Tue, Apr 28, 2020 at 3:54 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> 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?
yes. they should match.
In theory we can have -m32 umh running on 64-bit kernel,
but I wouldn't bother adding support for such thing
until there is a use case.
Running 64-bit umh on 32-bit kernel is no go.