[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 at 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