lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 28 Apr 2020 09:14:15 -0700
From:   Alexei Starovoitov <>
To:     Masahiro Yamada <>
Cc:     Alexei Starovoitov <>, bpf <>,
        Networking <>,
        Daniel Borkmann <>,
        Martin KaFai Lau <>,
        Linux Kernel Mailing List <>
Subject: Re: BPFilter: bit size mismatch between bpfiter_umh and vmliux

On Tue, Apr 28, 2020 at 3:54 AM Masahiro Yamada <> 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
> the embedded bpfilter_umh is 64bit ELF.
> You can reproduce it by the following command on the
> mainline kernel.
>$ make ARCH=i386 defconfig
>$ scripts/config -e BPFILTER
>$ scripts/config -e BPFILTER_UMH
>$ make $(nproc) ARCH=i386
>    ...
>$ file vmlinux
> vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> statically linked,
> BuildID[sha1]=7ac691c67b4fe9b0cd46b45a2dc2d728d7d87686, not stripped
>$ 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.

Powered by blists - more mailing lists