* [WireGuard] Error building against grsec-enabled kernel @ 2016-10-19 13:03 Toke Høiland-Jørgensen 2016-10-19 14:18 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2016-10-19 13:03 UTC (permalink / raw) To: WireGuard mailing list I'm getting build errors when building WireGuard against a grsec-enabled kernel (on Arch linux): DKMS make.log for wireguard-0.0.20161014 for kernel 4.7.8.201610161720-1-gr= sec (x86_64) Wed 19 Oct 14:59:25 CEST 2016 make: Entering directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/build' LD /var/lib/dkms/wireguard/0.0.20161014/build/built-in.o CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/main.o /var/lib/dkms/wireguard/0.0.20161014/build/main.o: warning: objtool: mod_ex= it(): can't find starting instruction CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/noise.o CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/device.o /var/lib/dkms/wireguard/0.0.20161014/build/device.c:330:29: error: constifi= ed variable =E2=80=98link_ops=E2=80=99 placed into writable section ".data.= .read_mostly" static struct rtnl_link_ops link_ops __read_mostly =3D { ^~~~~~~~ make[1]: *** [scripts/Makefile.build:290: /var/lib/dkms/wireguard/0.0.20161= 014/build/device.o] Error 1 make: *** [Makefile:1465: _module_/var/lib/dkms/wireguard/0.0.20161014/buil= d] Error 2 make: Leaving directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/build' Any idea how to fix this? -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-19 13:03 [WireGuard] Error building against grsec-enabled kernel Toke Høiland-Jørgensen @ 2016-10-19 14:18 ` Toke Høiland-Jørgensen 2016-10-19 16:07 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2016-10-19 14:18 UTC (permalink / raw) To: WireGuard mailing list Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > I'm getting build errors when building WireGuard against a grsec-enabled > kernel (on Arch linux): > > DKMS make.log for wireguard-0.0.20161014 for kernel 4.7.8.201610161720-1-= grsec (x86_64) > Wed 19 Oct 14:59:25 CEST 2016 > make: Entering directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/bui= ld' > LD /var/lib/dkms/wireguard/0.0.20161014/build/built-in.o > CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/main.o > /var/lib/dkms/wireguard/0.0.20161014/build/main.o: warning: objtool: mod_= exit(): can't find starting instruction > CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/noise.o > CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/device.o > /var/lib/dkms/wireguard/0.0.20161014/build/device.c:330:29: error: consti= fied variable =E2=80=98link_ops=E2=80=99 placed into writable section ".dat= a..read_mostly" > static struct rtnl_link_ops link_ops __read_mostly =3D { > ^~~~~~~~ > make[1]: *** [scripts/Makefile.build:290: /var/lib/dkms/wireguard/0.0.201= 61014/build/device.o] Error 1 > make: *** [Makefile:1465: _module_/var/lib/dkms/wireguard/0.0.20161014/bu= ild] Error 2 > make: Leaving directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/buil= d' > > Any idea how to fix this? OK, so turns out just getting rid of the __read_mostly fixes things. This could conceivably be conditioned on CONSTIFY_PLUGIN in the upstream source? :) -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-19 14:18 ` Toke Høiland-Jørgensen @ 2016-10-19 16:07 ` Toke Høiland-Jørgensen 2016-10-19 22:35 ` Jason A. Donenfeld 2016-10-20 2:19 ` Jason A. Donenfeld 0 siblings, 2 replies; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2016-10-19 16:07 UTC (permalink / raw) To: WireGuard mailing list Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > >> I'm getting build errors when building WireGuard against a grsec-enabled >> kernel (on Arch linux): >> >> DKMS make.log for wireguard-0.0.20161014 for kernel 4.7.8.201610161720-1= -grsec (x86_64) >> Wed 19 Oct 14:59:25 CEST 2016 >> make: Entering directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/bu= ild' >> LD /var/lib/dkms/wireguard/0.0.20161014/build/built-in.o >> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/main.o >> /var/lib/dkms/wireguard/0.0.20161014/build/main.o: warning: objtool: mod= _exit(): can't find starting instruction >> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/noise.o >> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/device.o >> /var/lib/dkms/wireguard/0.0.20161014/build/device.c:330:29: error: const= ified variable =E2=80=98link_ops=E2=80=99 placed into writable section ".da= ta..read_mostly" >> static struct rtnl_link_ops link_ops __read_mostly =3D { >> ^~~~~~~~ >> make[1]: *** [scripts/Makefile.build:290: /var/lib/dkms/wireguard/0.0.20= 161014/build/device.o] Error 1 >> make: *** [Makefile:1465: _module_/var/lib/dkms/wireguard/0.0.20161014/b= uild] Error 2 >> make: Leaving directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/bui= ld' >> >> Any idea how to fix this? > > OK, so turns out just getting rid of the __read_mostly fixes things. > This could conceivably be conditioned on CONSTIFY_PLUGIN in the upstream > source? :) ... but though I managed to get it to build, there's an overflow somewhere in the RX path with causes PAX to kill the interrupt handler (and thus crash the kernel). Don't have a backtrace, sorry :( -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-19 16:07 ` Toke Høiland-Jørgensen @ 2016-10-19 22:35 ` Jason A. Donenfeld 2016-10-20 2:19 ` Jason A. Donenfeld 1 sibling, 0 replies; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-19 22:35 UTC (permalink / raw) To: Toke Høiland-Jørgensen; +Cc: WireGuard mailing list Hey Toke, Good to see you in this neck of the woods! Yes -- the __read_mostly annotation needs to go away for grsec. I had this building and running a few months ago on there. I'll revive that work. I'm at a conference right now (codeblue.jp) giving a talk on WireGuard, but I'll dig up my grsec build system ASAP and get back to you. In the mean time, if you can muster a backtrace, this of course would be excellent. Talk soon, Jason ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-19 16:07 ` Toke Høiland-Jørgensen 2016-10-19 22:35 ` Jason A. Donenfeld @ 2016-10-20 2:19 ` Jason A. Donenfeld 2016-10-21 0:24 ` PaX Team 1 sibling, 1 reply; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-20 2:19 UTC (permalink / raw) To: Pipacs; +Cc: Toke Høiland-Jørgensen, WireGuard mailing list Hey PaX Team, People are trying to run WireGuard with PaX and running into problems. I wasn't able to reproduce any issues with CONFIG_PAX_SIZE_OVERFLOW=3Dy, but I did find issues with CONFIG_PAX_SIZE_OVERFLOW_EXTRA=3Dy. The resulting stack trace didn't seem to hit any WireGuard code, but it's possible that WireGuard is triggering some other bug in the kernel that might interest you: [ 21.286622] PAX: size overflow detected in function ipv6_frag_rcv net/ipv6/reassembly.c:459 cicus.188_740 max, count: 21, decl: mac_header; num: 0; context: sk_buff; [ 21.286777] CPU: 0 PID: 82 Comm: kworker/0:2 Not tainted 4.7.8-grsec #3 [ 21.286816] Workqueue: wireguard-crypt-wg0 ffffffff810ccd20 [ 21.286862] 0000000000000000 98fa0e0487e67b73 0000000000000286 0000000000000000 [ 21.286921] ffffffff81195536 ffffffff814b18b8 98fa0e0487e67b73 ffffffff814b18b8 [ 21.286986] 00000000000001cb ffffffff81124253 ffff880002d7fb00 ffff880003c03d10 [ 21.287047] Call Trace: [ 21.287061] <IRQ> [<ffffffff81195536>] ? dump_stack+0x70/0xca [ 21.287103] [<ffffffff81124253>] ? report_size_overflow+0x63/0x80 [ 21.287142] [<ffffffff81332769>] ? ipv6_frag_rcv+0x1589/0x1710 [ 21.287180] [<ffffffff81310006>] ? ipv6_dev_get_saddr+0x1b6/0x270 [ 21.287218] [<ffffffff813083cf>] ? ip6_input_finish+0xcf/0x3b0 [ 21.287254] [<ffffffff81308d56>] ? ip6_input+0xc6/0xe0 [ 21.287287] [<ffffffff81308ab8>] ? ipv6_rcv+0x408/0x5e0 [ 21.287322] [<ffffffff8129a103>] ? ip_rcv+0x343/0x500 [ 21.287358] [<ffffffff812315ce>] ? __netif_receive_skb_core+0x49e/0xa10 [ 21.287395] [<ffffffff812324d8>] ? process_backlog+0xa8/0x160 [ 21.287432] [<ffffffff81237c70>] ? net_rx_action+0x300/0x4b0 [ 21.287470] [<ffffffff81048711>] ? __do_softirq+0x101/0x230 [ 21.287508] [<ffffffff8134ee7c>] ? do_softirq_own_stack+0x1c/0x30 [ 21.287544] <EOI> [<ffffffff81048504>] ? do_softirq.part.15+0x34/0x50 [ 21.287591] [<ffffffff810485f4>] ? __local_bh_enable_ip+0x84/0xa0 [ 21.287627] [<ffffffff810cce0d>] ? padata_serial_worker+0xed/0x130 [ 21.287691] [<ffffffff8105e167>] ? process_one_work+0x177/0x440 [ 21.287734] [<ffffffff8105e48b>] ? worker_thread+0x5b/0x4d0 [ 21.287803] [<ffffffff813485e5>] ? __schedule+0x275/0x610 [ 21.287846] [<ffffffff8105e430>] ? process_one_work+0x440/0x440 [ 21.287887] [<ffffffff81064ec4>] ? kthread+0xe4/0x110 [ 21.287933] [<ffffffff8134cffe>] ? _raw_spin_unlock_irq+0xe/0x50 [ 21.287973] [<ffffffff8134dd7e>] ? ret_from_fork+0x1e/0x50 [ 21.288006] [<ffffffff81064de0>] ? __kthread_parkme+0x80/0x80 [ 21.288045] Kernel panic - not syncing: Aiee, killing interrupt handler! [ 21.288199] Kernel Offset: disabled [ 21.288239] ---[ end Kernel panic - not syncing: Aiee, killing interrupt handler! Regards, Jason On Thu, Oct 20, 2016 at 1:07 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok= e.dk> wrote: > Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > >> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: >> >>> I'm getting build errors when building WireGuard against a grsec-enable= d >>> kernel (on Arch linux): >>> >>> DKMS make.log for wireguard-0.0.20161014 for kernel 4.7.8.201610161720-= 1-grsec (x86_64) >>> Wed 19 Oct 14:59:25 CEST 2016 >>> make: Entering directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/b= uild' >>> LD /var/lib/dkms/wireguard/0.0.20161014/build/built-in.o >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/main.o >>> /var/lib/dkms/wireguard/0.0.20161014/build/main.o: warning: objtool: mo= d_exit(): can't find starting instruction >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/noise.o >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/device.o >>> /var/lib/dkms/wireguard/0.0.20161014/build/device.c:330:29: error: cons= tified variable =E2=80=98link_ops=E2=80=99 placed into writable section ".d= ata..read_mostly" >>> static struct rtnl_link_ops link_ops __read_mostly =3D { >>> ^~~~~~~~ >>> make[1]: *** [scripts/Makefile.build:290: /var/lib/dkms/wireguard/0.0.2= 0161014/build/device.o] Error 1 >>> make: *** [Makefile:1465: _module_/var/lib/dkms/wireguard/0.0.20161014/= build] Error 2 >>> make: Leaving directory '/usr/lib/modules/4.7.8.201610161720-1-grsec/bu= ild' >>> >>> Any idea how to fix this? >> >> OK, so turns out just getting rid of the __read_mostly fixes things. >> This could conceivably be conditioned on CONSTIFY_PLUGIN in the upstream >> source? :) > > ... but though I managed to get it to build, there's an overflow > somewhere in the RX path with causes PAX to kill the interrupt handler > (and thus crash the kernel). Don't have a backtrace, sorry :( > > -Toke > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > http://lists.zx2c4.com/mailman/listinfo/wireguard ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-20 2:19 ` Jason A. Donenfeld @ 2016-10-21 0:24 ` PaX Team 2016-10-21 2:32 ` Jason A. Donenfeld 0 siblings, 1 reply; 15+ messages in thread From: PaX Team @ 2016-10-21 0:24 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On 20 Oct 2016 at 11:19, Jason A. Donenfeld wrote: > Hey PaX Team, > > People are trying to run WireGuard with PaX and running into problems. > I wasn't able to reproduce any issues with CONFIG_PAX_SIZE_OVERFLOW=3Dy, > but I did find issues with CONFIG_PAX_SIZE_OVERFLOW_EXTRA=3Dy. that's because sk_buff.mac_header is in one of those hash tables that gets used by the extra feature only. in any case, whoever can reproduce this should print out the value of head->mac_header before the increment. my guess based on past experience on similar network problems is that the field is probably invalid (ffff or similar) and adding to it will trigger the size overflow check. this in turn means that there's usually some higher level logic bug and you'll have to talk to netdev guys as i'm way out of my depths at that point ;). > The resulting stack trace didn't seem to hit any WireGuard code, but it'= s > possible that WireGuard is triggering some other bug in the kernel > that might interest you: > > [ 21.286622] PAX: size overflow detected in function ipv6_frag_rcv > net/ipv6/reassembly.c:459 cicus.188_740 max, count: 21, decl: > mac_header; num: 0; context: sk_buff; > [ 21.286777] CPU: 0 PID: 82 Comm: kworker/0:2 Not tainted 4.7.8-grsec = #3 > [ 21.286816] Workqueue: wireguard-crypt-wg0 ffffffff810ccd20 > [ 21.286862] 0000000000000000 98fa0e0487e67b73 0000000000000286 > 0000000000000000 > [ 21.286921] ffffffff81195536 ffffffff814b18b8 98fa0e0487e67b73 > ffffffff814b18b8 > [ 21.286986] 00000000000001cb ffffffff81124253 ffff880002d7fb00 > ffff880003c03d10 > [ 21.287047] Call Trace: > [ 21.287061] <IRQ> [<ffffffff81195536>] ? dump_stack+0x70/0xca > [ 21.287103] [<ffffffff81124253>] ? report_size_overflow+0x63/0x80 > [ 21.287142] [<ffffffff81332769>] ? ipv6_frag_rcv+0x1589/0x1710 > [ 21.287180] [<ffffffff81310006>] ? ipv6_dev_get_saddr+0x1b6/0x270 > [ 21.287218] [<ffffffff813083cf>] ? ip6_input_finish+0xcf/0x3b0 > [ 21.287254] [<ffffffff81308d56>] ? ip6_input+0xc6/0xe0 > [ 21.287287] [<ffffffff81308ab8>] ? ipv6_rcv+0x408/0x5e0 > [ 21.287322] [<ffffffff8129a103>] ? ip_rcv+0x343/0x500 > [ 21.287358] [<ffffffff812315ce>] ? __netif_receive_skb_core+0x49e/0x= a10 > [ 21.287395] [<ffffffff812324d8>] ? process_backlog+0xa8/0x160 > [ 21.287432] [<ffffffff81237c70>] ? net_rx_action+0x300/0x4b0 > [ 21.287470] [<ffffffff81048711>] ? __do_softirq+0x101/0x230 > [ 21.287508] [<ffffffff8134ee7c>] ? do_softirq_own_stack+0x1c/0x30 > [ 21.287544] <EOI> [<ffffffff81048504>] ? do_softirq.part.15+0x34/0x= 50 > [ 21.287591] [<ffffffff810485f4>] ? __local_bh_enable_ip+0x84/0xa0 > [ 21.287627] [<ffffffff810cce0d>] ? padata_serial_worker+0xed/0x130 > [ 21.287691] [<ffffffff8105e167>] ? process_one_work+0x177/0x440 > [ 21.287734] [<ffffffff8105e48b>] ? worker_thread+0x5b/0x4d0 > [ 21.287803] [<ffffffff813485e5>] ? __schedule+0x275/0x610 > [ 21.287846] [<ffffffff8105e430>] ? process_one_work+0x440/0x440 > [ 21.287887] [<ffffffff81064ec4>] ? kthread+0xe4/0x110 > [ 21.287933] [<ffffffff8134cffe>] ? _raw_spin_unlock_irq+0xe/0x50 > [ 21.287973] [<ffffffff8134dd7e>] ? ret_from_fork+0x1e/0x50 > [ 21.288006] [<ffffffff81064de0>] ? __kthread_parkme+0x80/0x80 > [ 21.288045] Kernel panic - not syncing: Aiee, killing interrupt handl= er! > [ 21.288199] Kernel Offset: disabled > [ 21.288239] ---[ end Kernel panic - not syncing: Aiee, killing > interrupt handler! > > Regards, > Jason > > On Thu, Oct 20, 2016 at 1:07 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@= toke.dk> wrote: > > Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > > > >> Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> writes: > >> > >>> I'm getting build errors when building WireGuard against a grsec-ena= bled > >>> kernel (on Arch linux): > >>> > >>> DKMS make.log for wireguard-0.0.20161014 for kernel 4.7.8.2016101617= 20-1-grsec (x86_64) > >>> Wed 19 Oct 14:59:25 CEST 2016 > >>> make: Entering directory '/usr/lib/modules/4.7.8.201610161720-1-grse= c/build' > >>> LD /var/lib/dkms/wireguard/0.0.20161014/build/built-in.o > >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/main.o > >>> /var/lib/dkms/wireguard/0.0.20161014/build/main.o: warning: objtool:= mod_exit(): can't find starting instruction > >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/noise.o > >>> CC [M] /var/lib/dkms/wireguard/0.0.20161014/build/device.o > >>> /var/lib/dkms/wireguard/0.0.20161014/build/device.c:330:29: error: c= onstified variable =E2=80=98link_ops=E2=80=99 placed into writable section= ".data..read_mostly" > >>> static struct rtnl_link_ops link_ops __read_mostly =3D { > >>> ^~~~~~~~ > >>> make[1]: *** [scripts/Makefile.build:290: /var/lib/dkms/wireguard/0.= 0.20161014/build/device.o] Error 1 > >>> make: *** [Makefile:1465: _module_/var/lib/dkms/wireguard/0.0.201610= 14/build] Error 2 > >>> make: Leaving directory '/usr/lib/modules/4.7.8.201610161720-1-grsec= /build' > >>> > >>> Any idea how to fix this? > >> > >> OK, so turns out just getting rid of the __read_mostly fixes things. FWIW, i've been carrying such a local patch on my gentoo box too ;). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 0:24 ` PaX Team @ 2016-10-21 2:32 ` Jason A. Donenfeld 2016-10-21 8:02 ` PaX Team 0 siblings, 1 reply; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-21 2:32 UTC (permalink / raw) To: Pipacs Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On Fri, Oct 21, 2016 at 9:24 AM, PaX Team <pageexec@gmail.com> wrote: > in any case, whoever can reproduce this should print out the value of > head->mac_header before the increment. my guess based on past experience > on similar network problems is that the field is probably invalid (ffff > or similar) and adding to it will trigger the size overflow check. this > in turn means that there's usually some higher level logic bug and you'll > have to talk to netdev guys as i'm way out of my depths at that point ;). Fixed: https://git.zx2c4.com/WireGuard/commit/?id=867c815c31c754bf97b5fb29afd295b7cf195159 >> >> OK, so turns out just getting rid of the __read_mostly fixes things. > > FWIW, i've been carrying such a local patch on my gentoo box too ;). Got a good #ifdef for PAX that I should use to conditionally not use __read_mostly in case PAX is in use? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 2:32 ` Jason A. Donenfeld @ 2016-10-21 8:02 ` PaX Team 2016-10-21 8:47 ` Jason A. Donenfeld 0 siblings, 1 reply; 15+ messages in thread From: PaX Team @ 2016-10-21 8:02 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On 21 Oct 2016 at 11:32, Jason A. Donenfeld wrote: > On Fri, Oct 21, 2016 at 9:24 AM, PaX Team <pageexec@gmail.com> wrote: > > in any case, whoever can reproduce this should print out the value of > > head->mac_header before the increment. my guess based on past experience > > on similar network problems is that the field is probably invalid (ffff > > or similar) and adding to it will trigger the size overflow check. this > > in turn means that there's usually some higher level logic bug and you'll > > have to talk to netdev guys as i'm way out of my depths at that point ;). > > Fixed: > https://git.zx2c4.com/WireGuard/commit/?id=867c815c31c754bf97b5fb29afd295b7cf195159 are you sure it was for satisfying PaX only and not a bug itself? :) with the ffff initial value you were basically off by one (unsigned arithmetic wraps so it's as if you had initialized the fields to -1 instead of 0), didn't that matter somewhere beyond the size overflow checks? > >> >> OK, so turns out just getting rid of the __read_mostly fixes things. > > > > FWIW, i've been carrying such a local patch on my gentoo box too ;). > > Got a good #ifdef for PAX that I should use to conditionally not use > __read_mostly in case PAX is in use? if you ask me, you should just get rid of __read_mostly unconditionally (which is what i do in PaX as it interferes with constification) as rtnl_link_ops extends over several cache lines so any concerns with false sharing with writable data would at most affect only a few fields that are rarely used (or the fields could be reordered and/or aligned for such affect). otherwise you'll need to have your own #ifdef based on CONSTIFY_PLUGIN as suggested originally by Toke. cheers, PaX Team ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 8:02 ` PaX Team @ 2016-10-21 8:47 ` Jason A. Donenfeld 2016-10-21 9:46 ` PaX Team 2016-10-21 9:53 ` Toke Høiland-Jørgensen 0 siblings, 2 replies; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-21 8:47 UTC (permalink / raw) To: Pipacs Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On Fri, Oct 21, 2016 at 5:02 PM, PaX Team <pageexec@gmail.com> wrote: > are you sure it was for satisfying PaX only and not a bug itself? :) Blurg. I was overly hasty. Note to self: do not prepare conf presentations and push code at the same time. Indeed this /should/ be ~0, which means "unset". I can't see any bugs by making it 0, but it would make things "semantically incorrect", I think. So the bug is actually in the ipv6 fragmentation code. I just sent a patch upstream and CC'd you and Emese. > > if you ask me, you should just get rid of __read_mostly unconditionally (which > is what i do in PaX as it interferes with constification) as rtnl_link_ops extends > over several cache lines so any concerns with false sharing with writable data > would at most affect only a few fields that are rarely used (or the fields could > be reordered and/or aligned for such affect). otherwise you'll need to have your > own #ifdef based on CONSTIFY_PLUGIN as suggested originally by Toke. I'll use CONFIG_PAX_CONSTIFY_PLUGIN. Upstream uses __read_mostly for that structure always, everywhere else. They'll probably enforce their uniformity, so I'll stick a conditional redefinition of __read_mostly in compat.h. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 8:47 ` Jason A. Donenfeld @ 2016-10-21 9:46 ` PaX Team 2016-10-22 7:56 ` Jason A. Donenfeld 2016-10-21 9:53 ` Toke Høiland-Jørgensen 1 sibling, 1 reply; 15+ messages in thread From: PaX Team @ 2016-10-21 9:46 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On 21 Oct 2016 at 17:47, Jason A. Donenfeld wrote: > On Fri, Oct 21, 2016 at 5:02 PM, PaX Team <pageexec@gmail.com> wrote: > > are you sure it was for satisfying PaX only and not a bug itself? :) > > Blurg. I was overly hasty. Note to self: do not prepare conf > presentations and push code at the same time. Indeed this /should/ be > ~0, which means "unset". I can't see any bugs by making it 0, but it > would make things "semantically incorrect", I think. > > So the bug is actually in the ipv6 fragmentation code. I just sent a > patch upstream and CC'd you and Emese. thanks, i'm wondering if the tree should be audited for similar cases as we have open issues that have the same symptom (and ideally such fields changes would be done in accessor functions...). btw, your second submission has a few extra hunks disclosing debug code and full paths on your system, you probably didn't intend it ;). > I'll use CONFIG_PAX_CONSTIFY_PLUGIN. in general, plugin dependence should be expressed by plugin specific defines (CONSTIFY_PLUGIN in your case) and not by the config option as the two may not always correlate (e.g., it used to be possible to compile the kernel with a plugin-incapable gcc while enabling plugin dependent features and in such cases depending on the config option could produce unintended results). > Upstream uses __read_mostly for that structure always, everywhere else. FYI, i added detection for such cases in the plugin but it'd also be possible to simply override these interfering section attributes. i went with the compile error instead of the fixup as this way people pay attention (and i'm forced to fix the fallout in PaX) but it's also less convenient for out-of-tree code... ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 9:46 ` PaX Team @ 2016-10-22 7:56 ` Jason A. Donenfeld 0 siblings, 0 replies; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-22 7:56 UTC (permalink / raw) To: Pipacs Cc: Emese Revfy, Toke Høiland-Jørgensen, Brad Spengler, WireGuard mailing list On Fri, Oct 21, 2016 at 6:46 PM, PaX Team <pageexec@gmail.com> wrote: > thanks, i'm wondering if the tree should be audited for similar cases as we > have open issues that have the same symptom (and ideally such fields changes > would be done in accessor functions...). Toke mentioned a v4 related overflow too. I'll look into this and see if I can reproduce it. > btw, your second submission has a > few extra hunks disclosing debug code and full paths on your system, you probably > didn't intend it ;). I know. :( I resubmitted (again). Brain damage. > in general, plugin dependence should be expressed by plugin specific defines > (CONSTIFY_PLUGIN in your case) and not by the config option as the two may > not always correlate (e.g., it used to be possible to compile the kernel with > a plugin-incapable gcc while enabling plugin dependent features and in such > cases depending on the config option could produce unintended results). Okay, done: https://git.zx2c4.com/WireGuard/commit/?id=e74fdd02ab8fd5325f2534067dbfbd3a7254c12a > FYI, i added detection for such cases in the plugin but it'd also be possible to > simply override these interfering section attributes. i went with the compile > error instead of the fixup as this way people pay attention (and i'm forced > to fix the fallout in PaX) but it's also less convenient for out-of-tree code... Linux has never really supported out-of-tree code, in order to motivate mainline submission. Hopefully WireGuard will be mainline anyway soon enough. I think the error behavior is probably the right one, for weeding out issues as they appear. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 8:47 ` Jason A. Donenfeld 2016-10-21 9:46 ` PaX Team @ 2016-10-21 9:53 ` Toke Høiland-Jørgensen 2016-10-22 8:03 ` Jason A. Donenfeld 1 sibling, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2016-10-21 9:53 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Emese Revfy, Pipacs, Brad Spengler, WireGuard mailing list "Jason A. Donenfeld" <Jason@zx2c4.com> writes: > On Fri, Oct 21, 2016 at 5:02 PM, PaX Team <pageexec@gmail.com> wrote: >> are you sure it was for satisfying PaX only and not a bug itself? :) > > Blurg. I was overly hasty. Note to self: do not prepare conf > presentations and push code at the same time. Indeed this /should/ be > ~0, which means "unset". I can't see any bugs by making it 0, but it > would make things "semantically incorrect", I think. > > So the bug is actually in the ipv6 fragmentation code. I just sent a > patch upstream and CC'd you and Emese. Wooh! FYI I was seeing the bug being triggered on IPv4 as well... -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-21 9:53 ` Toke Høiland-Jørgensen @ 2016-10-22 8:03 ` Jason A. Donenfeld 2016-10-22 13:10 ` Toke Høiland-Jørgensen 0 siblings, 1 reply; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-22 8:03 UTC (permalink / raw) To: Toke Høiland-Jørgensen Cc: Emese Revfy, Pipacs, Brad Spengler, WireGuard mailing list Hi Toke, On Fri, Oct 21, 2016 at 6:53 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok= e.dk> wrote: > Wooh! FYI I was seeing the bug being triggered on IPv4 as well... Think you could try to acquire a backtrace? I'm not able to reproduce this. Jason ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-22 8:03 ` Jason A. Donenfeld @ 2016-10-22 13:10 ` Toke Høiland-Jørgensen 2016-10-23 10:23 ` Jason A. Donenfeld 0 siblings, 1 reply; 15+ messages in thread From: Toke Høiland-Jørgensen @ 2016-10-22 13:10 UTC (permalink / raw) To: Jason A. Donenfeld Cc: Emese Revfy, Pipacs, Brad Spengler, WireGuard mailing list "Jason A. Donenfeld" <Jason@zx2c4.com> writes: > Hi Toke, > > On Fri, Oct 21, 2016 at 6:53 PM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@t= oke.dk> wrote: >> Wooh! FYI I was seeing the bug being triggered on IPv4 as well... > > Think you could try to acquire a backtrace? I'm not able to reproduce > this. Yup, here you go: [ 161.303946] PAX: size overflow detected in function __netif_receive_skb_= core include/linux/skbuff.h:2045 cicus.1788_555 min, count: 84, decl: mac_l= en; num: 0; context: sk_buf f; = = [ 161.492637] Kernel panic - not syncing: Aiee,= killing interrupt handler! [ 161.572979] CPU: 0 PID: 166 Comm: kworker/0:2 Tainted: G O = 4.7.9.201610200819-1-grsec #1 [ 161.683444] Hardware name: Shuttle Inc. DS47D/FS47D, BIOS 1.03 08/09/2013 [ 161.764756] Workqueue: wireguard-crypt-wg0 ffffffff8114cc70 [ 161.831672] d2e8090500000002 d2e809059eef7236 0000000000000086 00000000= 00000000 [ 161.920683] ffff880100203c40 ffffffff81330c53 0000000000000002 d2e80905= 9eef7236 [ 162.009812] ffffffff819196b8 ffff880100203ce0 ffff880100203cd0 ffffffff= 8114f0ba [ 162.098838] Call Trace: [ 162.128078] <IRQ> [<ffffffff81330c53>] dump_stack+0x76/0xd3 [ 162.196943] [<ffffffff8114f0ba>] panic+0xdb/0x26f [ 162.254360] [<ffffffff8107843e>] do_exit+0x8fe/0xb70 [ 162.314888] [<ffffffff81078757>] do_group_exit+0x37/0xc0 [ 162.379579] [<ffffffff811f03c8>] report_size_overflow+0x78/0x90 [ 162.451557] [<ffffffff81550cf0>] __netif_receive_skb_core+0xd70/0xe10 [ 162.529767] [<ffffffff81554d85>] ? napi_gro_receive+0x75/0xd0 [ 162.599654] [<ffffffffa008e69e>] ? rtl8169_poll+0x8e/0x6a0 [r8169] [ 162.674744] [<ffffffff81553c0b>] __netif_receive_skb+0x1b/0x80 [ 162.745670] [<ffffffff815561b5>] process_backlog+0xa5/0x170 [ 162.813478] [<ffffffff8155601c>] net_rx_action+0x24c/0x340 [ 162.880246] [<ffffffff81079606>] __do_softirq+0x106/0x240 [ 162.945975] [<ffffffff816a9a1c>] do_softirq_own_stack+0x1c/0x30 [ 163.017945] <EOI> [<ffffffff81079119>] do_softirq.part.2+0x39/0x50 [ 163.094170] [<ffffffff810791b9>] __local_bh_enable_ip+0x89/0xb0 [ 163.166150] [<ffffffff8114cd5b>] padata_serial_worker+0xeb/0x130 [ 163.239161] [<ffffffff81093e54>] process_one_work+0x184/0x3e0 [ 163.309049] [<ffffffff81094108>] worker_thread+0x58/0x4e0 [ 163.374774] [<ffffffff810940b0>] ? process_one_work+0x3e0/0x3e0 [ 163.446747] [<ffffffff8109aeaa>] kthread+0xea/0x120 [ 163.506228] [<ffffffff816a85fe>] ret_from_fork+0x1e/0x50 [ 163.570919] [<ffffffff8109adc0>] ? kthread_worker_fn+0x1c0/0x1c0 [ 163.643942] Kernel Offset: disabled [ 163.685729] ---[ end Kernel panic - not syncing: Aiee, killing interrupt= handler! -Toke ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [WireGuard] Error building against grsec-enabled kernel 2016-10-22 13:10 ` Toke Høiland-Jørgensen @ 2016-10-23 10:23 ` Jason A. Donenfeld 0 siblings, 0 replies; 15+ messages in thread From: Jason A. Donenfeld @ 2016-10-23 10:23 UTC (permalink / raw) To: Toke Høiland-Jørgensen Cc: Emese Revfy, Pipacs, Brad Spengler, WireGuard mailing list Hi, I've switched to using the same strategy of tun.c, and simply resetting all the fields, even if this is semantically incorrect, as the rest of the kernel seems to do this in fact: https://git.zx2c4.com/WireGuard/commit/?id=95a869e45905766878cc4fee1a27a1c933786361 This should make WireGuard run fine on PaX. That, combined with the previous PaX-motivated commit, should make WireGuard work with Grsecurity kernels without any modification necessary. This work will be part of the next snapshot I tag. Jason ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-10-23 10:22 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-19 13:03 [WireGuard] Error building against grsec-enabled kernel Toke Høiland-Jørgensen 2016-10-19 14:18 ` Toke Høiland-Jørgensen 2016-10-19 16:07 ` Toke Høiland-Jørgensen 2016-10-19 22:35 ` Jason A. Donenfeld 2016-10-20 2:19 ` Jason A. Donenfeld 2016-10-21 0:24 ` PaX Team 2016-10-21 2:32 ` Jason A. Donenfeld 2016-10-21 8:02 ` PaX Team 2016-10-21 8:47 ` Jason A. Donenfeld 2016-10-21 9:46 ` PaX Team 2016-10-22 7:56 ` Jason A. Donenfeld 2016-10-21 9:53 ` Toke Høiland-Jørgensen 2016-10-22 8:03 ` Jason A. Donenfeld 2016-10-22 13:10 ` Toke Høiland-Jørgensen 2016-10-23 10:23 ` Jason A. Donenfeld
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.