[WireGuard] Error building against grsec-enabled kernel

[WireGuard] Error building against grsec-enabled kernel

[Toke Høiland-Jørgensen]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Toke Høiland-Jørgensen]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Toke Høiland-Jørgensen]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[PaX Team]

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 ;).

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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?

Re: [WireGuard] Error building against grsec-enabled kernel

[PaX Team]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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.

Re: [WireGuard] Error building against grsec-enabled kernel

[PaX Team]

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...

Re: [WireGuard] Error building against grsec-enabled kernel

[Toke Høiland-Jørgensen]

"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

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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.

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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

Re: [WireGuard] Error building against grsec-enabled kernel

[Toke Høiland-Jørgensen]

"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

Re: [WireGuard] Error building against grsec-enabled kernel

[Jason A. Donenfeld]

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