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
On Tue, Apr 28, 2020 at 3:54 AM Masahiro Yamada <[email protected]> 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.
Hi Alexei,
On Wed, Apr 29, 2020 at 1:14 AM Alexei Starovoitov
<[email protected]> wrote:
> >
> > 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.
Thanks for the comments.
This issue will be fixed by this:
https://patchwork.kernel.org/patch/11515997/
and the Makefile will be cleaned up by this:
https://patchwork.kernel.org/patch/11515995/
They are parts of the big series of Makefile cleanups.
So, I will apply the whole to kbuild tree.
Thanks.
--
Best Regards
Masahiro Yamada
On Thu, Apr 30, 2020 at 9:06 PM Masahiro Yamada <[email protected]> wrote:
>
> Hi Alexei,
>
> On Wed, Apr 29, 2020 at 1:14 AM Alexei Starovoitov
> <[email protected]> wrote:
> > >
> > > 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.
>
>
> Thanks for the comments.
>
>
> This issue will be fixed by this:
> https://patchwork.kernel.org/patch/11515997/
>
> and the Makefile will be cleaned up by this:
> https://patchwork.kernel.org/patch/11515995/
>
>
> They are parts of the big series of Makefile cleanups.
> So, I will apply the whole to kbuild tree.
thank you.
I saw the patches, but didn't have time to test or comment on them.
To be fair umh logic was bit rotting a bit, but that will change soon.