Re: [ebtables PATCH 2/2] configure.ac: add option --enable-kernel-64-userland-32

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, May 25, 2021 at 01:52:27PM +0200, Thomas De Schampheleire wrote:
> Hello,
> 
> El lun, 24 may 2021 a las 17:26, Pablo Neira Ayuso
> (<pablo@netfilter.org>) escribió:
> >
> > On Tue, May 18, 2021 at 08:17:30PM +0200, Thomas De Schampheleire wrote:
> > > From: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
> > >
> > > The ebtables build system seems to assume that 'sparc64' is the
> > > only case where KERNEL_64_USERSPACE_32 is relevant, but this is not true.
> > > This situation can happen on many architectures, especially in embedded
> > > systems. For example, an Aarch64 processor with kernel in 64-bit but
> > > userland built for 32-bit Arm. Or a 64-bit MIPS Octeon III processor, with
> > > userland running in the 'n32' ABI.
> > >
> > > While it is possible to set CFLAGS in the environment when calling the
> > > configure script, the caller would need to know to not only specify
> > > KERNEL_64_USERSPACE_32 but also the EBT_MIN_ALIGN value.
> > >
> > > Instead, add a configure option. All internal details can then be handled by
> > > the configure script.
> >
> > Are you enabling
> >
> > CONFIG_NETFILTER_XTABLES_COMPAT
> >
> > in your kernel build?
> >
> > KERNEL_64_USERSPACE_32 was deprecated long time ago in favour of
> > CONFIG_NETFILTER_XTABLES_COMPAT.
> 
> The option you refer to (CONFIG_NETFILTER_XTABLES_COMPAT) was
> introduced with commit 47a6959fa331fe892a4fc3b48ca08e92045c6bda
> (5.13-rc1). Before that point, it seems CONFIG_COMPAT was the relevant
> flag.

Sorry, I got confused by this recent commit, it's indeed CONFIG_COMPAT
the right toggle in old kernels.

> The checks on CONFIG_COMPAT were already introduced with commit
> 81e675c227ec60a0bdcbb547dc530ebee23ff931 in 2.6.34.x.
> 
> I have seen this problem on Linux 4.1 and 4.9, on an Aarch64 CPU with
> 64-bit kernel and userspace compiled as 32-bit ARM. In both kernels,
> CONFIG_COMPAT was set.

Hm, then ebtables compat is buggy.

> So I am a bit surprised that I bump into this issue after upgrading
> ebtables from 2.0.10-4 to 2.0.11 where the padding was removed.
> According to your mail and the commits mentioned, it is supposed to
> work without ebtables making specific provisions for the 32/64 bit
> type difference.
> 
> When I apply the patches I submitted to this list, I get correct
> behavior. Without them, the kernel complains and ebtables fails.

I understand. If this old userspace infrastructure is restored, then
ebtables compat kernel might not ever be fixed.