Created attachment 332456 [details] Patch to make constant (under hardened) structure non-constant net-dialup/martian-modem-20100123 fails to compile with hardened-sources (and even if it would compile it would not run): With hardened-sources structures with function pointers become implicitly constant unless __no_const is appended (and, moreover, they get stored in a region which cannot be modified). Thus a cheap workaround is to patch the sources to tell hardened-sources that the corresponding structure would not become constant. I attach a patch which does tihs. A better solution would be wrap every write access to the corresponding structure with corresponding calls to the hardened functions to allow modification. However, since part of the code is closed source, one would have to make sure that this part does not access the structure (or have to patch this also). I did not check whether this better solution is possible.
Perhaps instead of #ifdef __no_const as in my suggested patch it is cleaner to use #ifdef CONFIG_GRKERNSEC since there is no guarantee that __no_const is defined as a macro (after all, the hardened patches are realized as compiler plugins).
(In reply to Martin Väth from comment #1) > Perhaps instead of > > #ifdef __no_const > > as in my suggested patch it is cleaner to use > > #ifdef CONFIG_GRKERNSEC > > since there is no guarantee that __no_const is defined as a macro > (after all, the hardened patches are realized as compiler plugins). #ifdef __no_const is fine.
while __no_const will 'fix' the problem with this particular type, there're no guarantees that the closed source part of the module would not try to modify some other constified data. there's a reason why CONSTIFY_PLUGIN is part of vermagic and with binary modules you should not in general enable it in your kernel.
(In reply to PaX Team from comment #3) > while __no_const will 'fix' the problem with this particular type, there're > no guarantees that the closed source part of the module would not try to > modify some other constified data. This just has to be tried: If it works then it works (and it seems to work)... > with binary modules you should not in general enable it in your kernel. Meanwhile this plugin at least can be switched off (which IIRC was not the case when I reported the bug). Anyway it means to give up this protection for the whole kernel just because of a single module. So, if it works, the suggested patch is more secure than switching off the plugin globally.
Given comment #3, there's nothing for us to do here.
