Hello, El vie, 28 may 2021 a las 19:10, Florian Westphal (<fw@xxxxxxxxx>) escribió: > > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > > > 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. > > It was only ever tested with i686 binary on amd64 arch. I have verified now again with the same procedure, i.e. build ebtables 2.0.11 without proposed patches or special flags, on following platforms: 1. x86_64 kernel 5.4.x + i686 userspace: ebtables works correctly 2. aarch64 kernel 4.1.x + 32-bit ARM userspace: ebtables fails as described As mentioned before, in both cases CONFIG_COMPAT=y . > > Thomas, does unmodified 32bit iptables work on those arch/kernel > combinations? Yes, iptables 1.8.6 is used successfully without special provisioning for bitness. We are using Buildroot 2021.02 to compile. > > > > 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. > > ebtables-userspace compat fixups predate the ebtables kernel side > support, it was autoenabled on sparc64 in the old makefile: > > ifeq ($(shell uname -m),sparc64) > CFLAGS+=-DEBT_MIN_ALIGN=8 -DKERNEL_64_USERSPACE_32 > endif Yes, in the proposed changes to ebtables userspace, this kind of logic is restored, but not based on the machine type but with an autoconf flag. > > I don't even know if the ebtables compat support is compiled in on > non-amd64. Can you be more specific what you are referring to here? For the kernel part, a long time ago you already created commit 81e675c227ec60a0bdcbb547dc530ebee23ff931 which is supposed to add compatibility when CONFIG_COMPAT=y. This code is still present in the 4.1.x I tested above. So at this moment it seems to me that the kernel compat support is effectively compiled in, and supports x86(_64) but does not support the Aarch64/ARM combination (and perhaps others). How to proceed now? Thanks, Thomas
