netdev - Re: BPFilter: bit size mismatch between bpfiter

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CAADnVQ+RvDq9qvNgSkwaMO8QcDG1gCm-SkGgNHyy1gVC3_0w=A@mail.gmail.com>
Date:   Tue, 28 Apr 2020 09:14:15 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Alexei Starovoitov <ast@...nel.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: BPFilter: bit size mismatch between bpfiter_umh and vmliux

On Tue, Apr 28, 2020 at 3:54 AM Masahiro Yamada <masahiroy@...nel.org> 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@...ar:~/ref/linux$ make ARCH=i386 defconfig
> masahiro@...ar:~/ref/linux$ scripts/config -e BPFILTER
> masahiro@...ar:~/ref/linux$ scripts/config -e BPFILTER_UMH
> masahiro@...ar:~/ref/linux$ make $(nproc) ARCH=i386
>    ...
> masahiro@...ar:~/ref/linux$ file vmlinux
> vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> statically linked,
> BuildID[sha1]=7ac691c67b4fe9b0cd46b45a2dc2d728d7d87686, not stripped
> masahiro@...ar:~/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.