On Fri, Oct 21, 2016 at 6:46 PM, PaX Team <[email protected]> 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. _______________________________________________ WireGuard mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/wireguard
