kernel stack guard page

[kornos]

Hello Pax Team

Please enlight me with this one:

This behaviour : https://lkml.org/lkml/2015/1/5/148
is related to the problem you (magistrally) exposed in this thread: https://lkml.org/lkml/2011/6/6/306
or it is a different issue?

Thanks very much.

[PaX Team]

yes, it sounds like the exact issue with Linus' approach that i had pointed out at the time but i also doubt that you can get it fixed properly now. and whatever workaround you may do on the ASAN side, please make sure it works under the PaX approach as well (which is also pretty much what older SuSE kernels had if i'm not mistaken). last but not least, feel free to CC me on these mails next time .

[kornos]

After reading your emails then, i thought Linus would fix the problems, you presented a very convincing case.
I didn't follow the ulterior patches.

I was pretty stupified that today he still got this kind of attitude towards others: https://lkml.org/lkml/2015/1/4/148 , but his attitude regarding his own s**t is just to cover it up, as you pointed in various emails.

Too bad.

Later edit: more fixups? : https://lkml.org/lkml/2015/1/5/659

Best regards

[PaX Team]

yeah like i predicted, first he pretends he's never heard of the problem with his approach and then doesn't fix it properly but piles up more hacks on it... now write a program that expects precise stack rlimits where his new hack will break down .

[kornos]

Yet another one?

https://lkml.org/lkml/2015/2/16/725

[PaX Team]

yes.

[Neokernsec]

Argh. I hate this sort of "duck and cover" approach.

This reminds me of the ugly days of early Commodore Amiga "development". Rather than addressing bugs, Commodore advised a work-around. Naturally, the work-around was fragile and defective in its way, so developers did their own work-arounds. And so even when the bugs were fixed, the legacy of Commodore's short-sighted response to it ensure that this "bug" lived on for years even after they eventually "fixed" it.

[nschellenberger]

Sorry for the necro, but I was just hit by sometthing like this as well in some third party code which is reading /proc/self/maps to find the main thread stack mapping.

I haven't worked in the Linux kernel for some years so please forgive me if there is some "obvious" solution, but is there no way to directly ask the kernel for the actual base address and available gap size for the main stack? If not, what are the design issues involved, and are any of them currently relevent to an ARMv7 platform? I'm very tempted to just hack in a syscall to get the stack base and gap size without having to grot through text output and apply a bunch of heuristics (e.g. knowing about the guard area position and size) to guess at something the kernel already knows.... I realize that later introduction of a mapping between the lowest current stack address and the next lower mapping,or a change in stack rlimit could make these values change over process runtime, but it would be good enough for many uses, including my immediate needs. Is there something fundamental I'm missing?

[PaX Team]

is this a question about grsec or vanilla kernels? 'cos i'm pretty sure we get this right and our version of procfs doesn't spread lies in the process 'maps' files .

[nschellenberger]

TL;DR I don't think grsec is doing the wrong thing here. I'm just trying to port/placate a piece of third party code which is attempting to do some horrible things to its stack....

We're integrating said piece of software into our environment, which has a grsec kernel with PAX_ASLR and PAX_RANDMMAP turned on. The specific problem is that this software is making what I believe to be the unwarranted assumption that if the stack rlim_cur is RLIMIT_INFINITY then it can assume that the stack runs backwards from the high address in the [stack] line of /proc/self/maps for at least 8MB. It then proceeds to try to validate this assumption by walking backward, reading a byte from each page in order to force it to be allocated, and finally tries to set up its own guard page mapping one page before the real kernel guard page (so that it can catch overflows for its own purposes).

Empirically for our environment the rlimit being returned for the main thread stack is RLIMIT_INFINITY (I assume, but may be mistaken, that none of the other folks on our project has done anything special to cause that) but, with a random mmap_base, the gap available for the main thread stack is very seldom anything like 8MB. I rather suspect that it also isn't anything like that even on a non-grsec kernel, but that the software in question "gets away with it" because there tend to be at least 8MB worth of contiguous readable mappings which are actually from loaded shared objects, and that its manual guard page actually ends up somewhere entirely inappropriate....

In the process of trying to come up with something that makes this all play together nicely, I looked at how the VM_GROWSDOWN stack segment is set up, (some of) how it's grown, and how it's reported in /proc/*/maps. If I understand it correctly -- and admittedly I probably don't -- it seems to me that the stack mapping (and by extension the [stack] line in /proc/*/maps [stack]) will only describe the current vma as it stands, and not the space for the vma to grow into; and also that the guard page is only going to show up if it actually gets touched (and a mapping is therefore created). However, I may easily be misunderstanding that -- particularly since I still haven't figured out how the guard page gets created/handled for ARMv7.

Anyway, FWIW, I just found it odd that such fundamental bits of information as the main thread stack base and usable size are apparently only available by using file I/O to grot through multiple lines of text -- of which at most only two are germane to the problem at hand -- and even then rely on knowing a) how the kernel will grow the stack and b) how big the guard area will be. That seems like an awful lot of work to fetch two well known integers.... I also found it slightly odd that the rlimit being returned doesn't provide a useful indication of the actual space available -- but since that's notionally under user control, it's arguably not the kernel's problem. (And it's entrely possible that it's self-inflicted somewhere on our part -- I'm pretty new to this project.)

Again, it's been a long time since I've had to fiddle with the Linux kernel, so I may have enitrely the wrong then of the stick. Or stack. Whichever.