Needless to say, most changes in the grsecurity patch go over my head, but some hunks looked simple to _me_ at least. Namely, the hunks related to:
* making "const" dozens of struct instances, e.g. *_ops structs: IIUC, on some architectures, they can end up pushed to a read-only area protected by the MMU, so that attempts to rewrite it yield some low-level exception, hopefully ending up in the offending program being killed;
* making "const" more struct fields - compilers complain about direct attempts to change the values within the kernel itself, so it can be an early thinko/typo catcher;
* adding more "__user" annotations - IIUC, it can help human programmers and static code checkers to know that the parameters marked "__user" contain input from, or output to, user space;
* changing some variables from "int" to "unsigned int" - IIUC, this can be related to integer overflows ?
* "asm volatile" instead of just "asm" - looks like "volatile" can prevent the compiler from meddling up with the assembly fed to it, not sure why it should do that.
Searching about "grsecurity const" led me to http://www.grsecurity.net/~spender/more_const_fixes.diff , for an older version of the kernel, and to another discussion on LWN, http://lwn.net/Articles/346299/ , more than one year ago. This discussion precisely mentions instances of one struct type made const, and spender pointing to more structs that could be made const.
So in the end, I'd like to ask: what are the downsides to making those *_ops structs const, or adding more annotations, in mainline kernels ?
I say this in a respectful way: I'm not able to imagine by myself reasons why e.g. "const-ified" *_ops structs are not part of the mainline kernels.
Thanks in advance for enlightening me ;)
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds