[grsec] Q. 'const'antify the members of a structure

[J. R. Okajima]

pageexec at freemail.hu:
> you're talking about the human point of view, but that's only part of the
> whole picture, the machine point of view is quite different in fact. in
> particular it's up to the toolchain and runtime environment to actually
> enforce the const (read-only) property of code/data. as you may have inferred
> it by now, PaX (and in particular KERNEXEC) does exactly that. even vanilla
> kernels have been able to do this partially (DEBUG_RODATA) for a while now.

Do you mean that there is such environment which puts these const
members in a readonly section?
Although I agree that 'static const int *p = brabra' will be layouted in
readonly section, I am afraid 'struct {const int *p} foo' will not.
If you declare 'static const struct {const int *p} foo = {.p = brabra}',
then it will go to readonly. This is my main question.
At least in x86 32/64, 'p' in 'struct {const int *p} foo' can be
assigned indirectly.


> try that under KERNEXEC (or even DEBUG_RODATA) and report back the results ;).

After applying the grsec patch, DEBUG_RODATA is not selectable since it
depends upon BROKEN, is it?


> what makes you think that we don't do that? there are many things in PaX
> that assume certain 'invariants' in the kernel that have to be verified
> *manually* for each release. that's one reason why porting PaX is not a
> trivial business for example. so you can rest assured that we are very
> much aware of what dangers the 'forking' of such an ops structure presents
> and we check for changes each time we make a forward port.

If my mail made you offended, I should apology. That is not what I
meant. I know developing these patches has to be a hard work. I just
wanted to say that introducing a tiny code will make your un-trivial
business easier.


J. R. Okajima