[WireGuard] Error building against grsec-enabled kernel
Jason A. Donenfeld
Jason at zx2c4.com
Sat Oct 22 09:56:53 CEST 2016
On Fri, Oct 21, 2016 at 6:46 PM, PaX Team <pageexec at 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.
More information about the WireGuard
mailing list