Messages in this thread | | | Date | Thu, 3 Feb 2000 18:48:56 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: Bug in mremap()? was: Re: Bug in realloc ????? (glibc2.1.2) |
| |
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:
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/mremap-waste-virtual-stack-space-1.gz
>- 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/
| |