On 2 Feb 2000, Andreas Jaeger wrote:
>We've to differentiate two problems here (as Andrea already
>explained):
>- mremap using higher and higher addresses
Yes, and Wolfram patch to address the mremap virtual stack space waste is
correct (but it's against 2.0.x so doesn't apply). This is the 2.2.14
version:
>- the stack growing in the heap
Yes.
As just said (but not yet on l-k thus I repeat) it's not possible to get
this case always right even changing the stack segment selector to use a
LDT segment descriptor for the stack (different than the one for the data)
because movl will continue to pass through the DS segment selector and so
through the GDT user-data segment descriptor. We could instead make a
perfect stack/heap barrier if it would be possible to generate a trap
while decreasing the esp value (and that's not possible AFIK (and I guess
for good reasons since I guess it would be way way way too slow to
implement such check for the hardware), of course I am open to correction
about this since I have not read the whole PDF specs line by line, but I
never read anything talking about traps decreasing esp).
Anyway the only point for this change is to help good citizens that only
want to get a segfault if there's a stack overflow in the common case.
It's not a security issues and we have no problems if bad citizens can
stack overflow silenty, since they will harm themselfs only ;).
So while I think it worth to help good citizens, I don't think it worth to
play very dirty in IA32 speicic code _even_ if would be possible (also
because doing so we would be slower for tasks that needs more user stack
than the one of the fast path that we can set in a startup GDT entry).
This patch will change the common code base to put a not-mapped GAP
between the heap and the stack. The gap is 128pages as default but it's a
tunable sysctl. That should be enough to segfault good citizens. It won't
have a performance impact (I don't think the cacheline waste for the
sysctl read will be noticeable).
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/silent-stack-overflow-1.gz
It will cause the testcase to segfault.
BTW, setting the gap to zero via sysctl will undo the effect of the patch
of course and it will be exactly like not having applyed the patch at all.
Please test it out and feedback. Thanks.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:10 EST