-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ppc64 pseries_defconfig ld.lld errors #602
Comments
What's special about these symbols that leads to LLD discarding them? Is there a linker script involved that LLD is not handling the same way as BFD? |
This big-endian configuration doesn't work, even if ld.bfd is used:
.opd is some ELFv1 stuff. |
This is interesting... Building without
However, trying to link all of those files with
Wonder what changes the ABI version. |
Took me a while to figure this out. TLDR: |
I don't know that we need a build error for this right out the gate since as far as I am aware, I am the only one who has tried this :) If there isn't support in ld.lld for elfv1, I think we can just close this as it is a moot point. |
I sent With that patch, we could tackle this issue using something like this: diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index f310c32e88a4..97af461e8b8e 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -143,7 +143,13 @@ endif
endif
CFLAGS-$(CONFIG_PPC64) := $(call cc-option,-mtraceback=no)
-ifndef CONFIG_CC_IS_CLANG
+ifdef CONFIG_CC_IS_CLANG
+ifdef CONFIG_LD_IS_LLD
+ifdef CONFIG_CPU_BIG_ENDIAN
+$(error ld.lld does not support PowerPC big endian due to lack of elfv1 support)
+endif
+endif
+else
ifdef CONFIG_CPU_LITTLE_ENDIAN
CFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2,$(call cc-option,-mcall-aixdesc))
AFLAGS-$(CONFIG_PPC64) += $(call cc-option,-mabi=elfv2) |
I guess |
Yes, fair point :) If I end up sending that along, I'll add it. |
In the datapath, the ip6gre_tunnel_lookup() is used and it internally uses fallback tunnel device pointer, which is fb_tunnel_dev. This pointer variable should be set to NULL when a fb interface is deleted. But there is no routine to set fb_tunnel_dev pointer to NULL. So, this pointer will be still used after interface is deleted and it eventually results in the use-after-free problem. Test commands: ip netns add A ip netns add B ip link add eth0 type veth peer name eth1 ip link set eth0 netns A ip link set eth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set eth0 up ip netns exec A ip link add ip6gre1 type ip6gre local fc:0::1 \ remote fc:0::2 ip netns exec A ip -6 a a fc:100::1/64 dev ip6gre1 ip netns exec A ip link set ip6gre1 up ip netns exec A ip -6 a a fc:0::1/64 dev eth0 ip netns exec A ip link set ip6gre0 up ip netns exec B ip link set lo up ip netns exec B ip link set eth1 up ip netns exec B ip link add ip6gre1 type ip6gre local fc:0::2 \ remote fc:0::1 ip netns exec B ip -6 a a fc:100::2/64 dev ip6gre1 ip netns exec B ip link set ip6gre1 up ip netns exec B ip -6 a a fc:0::2/64 dev eth1 ip netns exec B ip link set ip6gre0 up ip netns exec A ping fc:100::2 -s 60000 & ip netns del B Splat looks like: [ 73.087285][ C1] BUG: KASAN: use-after-free in ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.088361][ C1] Read of size 4 at addr ffff888040559218 by task ping/1429 [ 73.089317][ C1] [ 73.089638][ C1] CPU: 1 PID: 1429 Comm: ping Not tainted 5.7.0+ #602 [ 73.090531][ C1] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 73.091725][ C1] Call Trace: [ 73.092160][ C1] <IRQ> [ 73.092556][ C1] dump_stack+0x96/0xdb [ 73.093122][ C1] print_address_description.constprop.6+0x2cc/0x450 [ 73.094016][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.094894][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.095767][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.096619][ C1] kasan_report+0x154/0x190 [ 73.097209][ C1] ? ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.097989][ C1] ip6gre_tunnel_lookup+0x1064/0x13f0 [ip6_gre] [ 73.098750][ C1] ? gre_del_protocol+0x60/0x60 [gre] [ 73.099500][ C1] gre_rcv+0x1c5/0x1450 [ip6_gre] [ 73.100199][ C1] ? ip6gre_header+0xf00/0xf00 [ip6_gre] [ 73.100985][ C1] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 73.101830][ C1] ? ip6_input_finish+0x5/0xf0 [ 73.102483][ C1] ip6_protocol_deliver_rcu+0xcbb/0x1510 [ 73.103296][ C1] ip6_input_finish+0x5b/0xf0 [ 73.103920][ C1] ip6_input+0xcd/0x2c0 [ 73.104473][ C1] ? ip6_input_finish+0xf0/0xf0 [ 73.105115][ C1] ? rcu_read_lock_held+0x90/0xa0 [ 73.105783][ C1] ? rcu_read_lock_sched_held+0xc0/0xc0 [ 73.106548][ C1] ipv6_rcv+0x1f1/0x300 [ ... ] Suggested-by: Eric Dumazet <eric.dumazet@gmail.com> Fixes: c12b395 ("gre: Support GRE over IPv6") Signed-off-by: Taehee Yoo <ap420073@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
@q66 told me that @leahneukirchen has a patch to drop ELFv1 legacy from |
that's my patch, @leahneukirchen just pulled it in from the previous patches for a previous kernel |
Thanks for clarification! https://www.kernel.org/doc/html/latest/process/changes.html requires GCC 4.9. GCC gained support for -mabi=elfv2 in 2013. Perhaps we can make -mabi=elfv2 unconditional and entirely drop -mcall-aixdesc (not supported by Clang as of 12.0.0). |
the patch should still fall back to ELFv1 and there were efforts upstream to add the ELFv2 option previously, first one some years back (which got abandoned later) and IIRC there's a second one that was under review just recently (not sure what became of it) |
@q66 was there a thread for the upstream discussions that you can link to? This is still reproducible with |
Big endian ELFv2 support was sent upstream but the commit message of the second patch in the series mentions that LLVM did not receive testing so it was restricted to GCC and binutils in Kconfig: https://lore.kernel.org/r/20210611093959.821525-1-npiggin@gmail.com/ It does not look like it was ever picked up. |
We should ask @mpe on the list whether big endian could be moved to ELFv2 (via that patch). @nathanchance found https://lore.kernel.org/all/20210611093959.821525-1-npiggin@gmail.com/, but mentioned that there's some Kconfig changes we need to make+test. @nathanchance can you provide more info? @mandlebug mentioned that FreeBSD switched their BE ppc64 build to ELFv2. |
https://lore.kernel.org/all/20210611093959.821525-3-npiggin@gmail.com/ mentions:
Let's hop on that thread and help test. |
This should not be visible in mainline after https://git.kernel.org/linus/9d90161ca5c7234e80e14e563d198f322ca0c1d0. Closing this up for now. |
To reproduce (on current mainline or -next):
The text was updated successfully, but these errors were encountered: