Posted Nov 4, 2010 9:35 UTC (Thu) by Lionel_Debroux (subscriber, #30014)
Parent article: KS2010: Security
I'm employed as a programmer in user-space, but I don't know _that_ much about security, and I'd like to learn further, for both user-space and kernel-space (since kernels are supposed to protect programs against each other, and protect themselves against potentially malicious user-space).
So it happened that I recently looked through the grsecurity patch, after seeing "spender", i.e. one of its developers, mentioning it multiple times in LWN comments.
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.
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.