Summary: | net-firewall/iptables: x32/n32 ABIs: iptables -L: can't initialize iptables table `filter': Invalid argument | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | daemontux <daemontux86> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | jstein, kyle.leet, luke-jr+gentoobugs, mips, srcshelton, thican |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.netfilter.org/show_bug.cgi?id=1025 | ||
See Also: |
http://bugs.debian.org/690548 http://bugzilla.netfilter.org/show_bug.cgi?id=1025 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 393673 | ||
Attachments: |
strace -s 4096 -o log iptables -L
kernel config working kernel.config Test case A Test case B emerge --info |
Description
daemontux
2013-06-05 10:26:48 UTC
it's working fine for me with linux-3.8.3 and iptables-1.4.19.1 attach your kernel .config as well as the log from doing: strace -s 4096 -o log iptables -L Created attachment 352296 [details]
strace -s 4096 -o log iptables -L
Created attachment 352298 [details]
kernel config
Present with net-firewall/iptables-1.4.19.1. Same failure in the strace that daemontux provided in Comment 2. No idea how Vapier got this to work on his x32 system. Forcing the application to compile as m32 or m64 instead of mx32 (same sort of thing as bug 466840 comment 2) definitely works. Hope this helps! Created attachment 352462 [details]
working kernel.config
here's my kernel config w/linux-3.8.3
running in a native x32 chroot:
# qlist -Iv iptables
net-firewall/iptables-1.4.19.1
# file -L `which iptables`
/sbin/iptables: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.4.0, stripped
# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- 0.0.0.0/0 0.0.0.0/0
DROP udp -- 0.0.0.0/0 0.0.0.0/0
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:138
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:137
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:620
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
DROP udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:111
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
DROP all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
I am able to reproduce this the stock x32 stage3 and net-firewall/iptables-1.4.20. The syscall that is traced above Nov 04 00:17:17 x32 kernel: ip_tables: : 3900 != 3896 The problem appears to be 8 byte alignment for the structure ( kernel side is: http://lxr.linux.no/linux+v3.12/+code=compat_ipt_get_entries) as the sizeof struct ipt_get_entries is 40, not 36. Adding -fpack-struct to the CFLAGS got this to work for me. > Adding -fpack-struct to the CFLAGS got this to work for me.
-fpack-struct=4 aligns the structures when setting stuff like the policy and the like. It seems for work well for a test box that does DNAT,SNAT, MASQ, REDIRECT, MANGLING amongst other things.
The same thing happens with gcc 4.7.2 as well as 4.8.1. Is this perhaps a GCC bug?
(In reply to cjanderson from comment #8) > > Adding -fpack-struct to the CFLAGS got this to work for me. > -fpack-struct=4 aligns the structures when setting stuff like the policy and > the like. It seems for work well for a test box that does DNAT,SNAT, MASQ, > REDIRECT, MANGLING amongst other things. I believe it's a kernel bug. The underlying system is amd64, but the pointer sizes don't line up. I've been just compiling iptables separately for amd64 and it works. I'm glad someone's found a fix though. Maybe it should be part of the ebuild? (In reply to Kyle Sanderson from comment #9) > I believe it's a kernel bug. The underlying system is amd64, but the pointer > sizes don't line up. I've been just compiling iptables separately for amd64 > and it works. I'm glad someone's found a fix though. Maybe it should be part > of the ebuild? I thought that it was kernel side, but could not really find anything in the kernel. But I did find something odd when compiling with 32 and 64 bits when you have a 64 bit structure that is in the array. Thats hard to explain, so I attach two example files, one called a.c and the other b.c. The only difference between the two i the line "unsigned long long a,b;" in a.c becomes a "char a,b" in b.c. When you run these using -m32 -m64 and -mx32 you get the following: a.c b.c gcc -m32 -> 36 36 gcc -m64 -> 40 36 gcc -mx32 -> 40 36 I have not looked into why the 64 bit kernel expects the structure ipt_entries to be 36 bytes and not 40. Created attachment 362724 [details]
Test case A
Created attachment 362726 [details]
Test case B
Due to the lack of interest in this bug, I thought I might add some commentary. AFIK, the kernel doesn't understand x32, as this is one of the models/modes supported by a 64bit kernel. And, for all intents and purposes, x32 is a 32 bit address space, ie. pointers as far as the applications developer is concerned. Given this gross over simplification, then, should not the x32 case for the test case a.c read 36 and 36? Or have I missed something? And as the kernel is expecting 36 bytes for a similar structure, which is the one for which this error is generated, it would appear that the problem is with the compiler. I am not familiar with x32 ABI, but have you seen comment 10 in Debian's bug report 690548 [1]? Isn't that the same problem and if Jan is right, you cannot run iptables x32 with a x64 kernel? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690548#10 (In reply to Thomas D. from comment #15) > Isn't that the same problem and if Jan is right, you cannot run iptables x32 > with a x64 kernel? > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690548#10 I believe that the assertion made in the debian bug is that even when COMPAT_... is enabled, and even when the x32 magical thunking (compat_...) is done in an AMD64 bit kernel that supports x32 is that you will not be able to run a 32 bit iptables on the aforementioned kernel. If this is correct, then why can I take a stock stage3 for i486, emerge iptables, the thing works? I believe that the sizeof the structure is correct in the kernel, viz 36, and the problem lies with the generation of the x32 code, based on the fact that the user side structure is somehow incorrect. Created attachment 376200 [details] emerge --info Hello everyone, Getting this same error with x32 ABIs, I followed cjanderson's advice (comment 7), `CFLAGS="-march=corei7-avx -O2 -pipe -ggdb -fpack-struct" CXXFLAGS="${CFLAGS}" emerge -vat iptables' and as expected, iptables works fine now … unlike ip6tables: # ip6tables -L -nv ERROR: 0 not a valid target) But this is strange, because both /sbin/iptables and /sbin/ip6tables are symlink to /sbin/xtables-multi, so, I don't understand why one works unlike the other. I can provide more informations if you need it. Best regards. (In reply to Thibaud "thican" CANALE from comment #17) > Created attachment 376200 [details] > emerge --info > > Hello everyone, > > Getting this same error with x32 ABIs, I followed cjanderson's advice > (comment 7), > > `CFLAGS="-march=corei7-avx -O2 -pipe -ggdb -fpack-struct" > CXXFLAGS="${CFLAGS}" emerge -vat iptables' > > and as expected, iptables works fine now … unlike ip6tables: > > # ip6tables -L -nv > ERROR: 0 not a valid target) > > But this is strange, because both /sbin/iptables and /sbin/ip6tables are > symlink to /sbin/xtables-multi, so, I don't understand why one works unlike > the other. > > I can provide more informations if you need it. > > Best regards. Same problem I have on my newly installed system. -fpack-struct solves just like yours. ip6tables give the same error. # ip6tables -L -nv > ERROR: 0 not a valid target) Used stage3-x32-20140325.tar.bz2 for the install. iptables version is 1.4.20 Kernel gentoo-sources version 3.12.13 Hello, I think we should add this bug to the tracker “x32 porting issues” bug 393673, and mark this bug as “confirmed”. the getsockopt(SOL_IP, IPT_SO_GET_INFO) call in iptables (libiptc/libiptc.c:TC_INIT) is failing because sizeof(struct ipt_get_entries) is 40 but the kernel wants 36 (net/ipv4/netfilter/ip_tables.c:compat_get_entries). this is because the alignment of entrytable is set to 8 while the kernel uses 4. putting __attribute__((packed)) on that struct in linux/netfilter_ipv4/ip_tables.h gets past that error. but then it all falls down when it tries to parse that structured return. most likely due to the other structs not being packed in the same way. moved the report upstream. i've added the struct pack hack for x32 for now: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35a3bea74f790d3fd69cab4b40f245078dd6bf18 Running MIPS/N32 here, but don't have netfilter stuff loaded into this kernel. Ran the two test cases, though, and here's the output: # ./a ipt_get_entries is 40 bytes # ./b ipt_get_entries is 36 bytes # file ./a ./a: ELF 32-bit MSB executable, MIPS, N32 MIPS-IV version 1, dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux 2.6.32, not stripped Running 'iptables -L' by itself yields this, which I think is because I'm missing the kernel options: # iptables -L iptables v1.4.21: can't initialize iptables table `filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (In reply to Joshua Kinard from comment #22) try extending the existing pack struct hack for n32 to see if it works for you (In reply to SpanKY from comment #23) > (In reply to Joshua Kinard from comment #22) > > try extending the existing pack struct hack for n32 to see if it works for > you Looks like MIPS doesn't need the patch, even for N32: # iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination It's an old bug, but I've just realised that net-firewall/iptables-1.8.5 provides an 'iptables' implementation which works on AMD64/x32. However, this version still fails with: ``` $ sudo ip6tables-save # Generated by ip6tables-save v1.8.5 on Sun Aug 23 20:48:43 2020 *nat ERROR: 0 not a valid target) Aborted ``` ... when built on x32. I've solved this by having an AMD64 chroot to build pure 64bit binary packages, and then merge these onto the (multilib) x32 system by emerging the package with CHOST set. It would be excellent to not have to do this any longer! The remaining packages I'm aware of as well as iptables are iproute2 and miniupnpd as dependencies. |