Decreasing Stackpointer?

[Jockey1976]

This is probably a stupid question but, however, I cant figure out why the stack-pointer is decreasing instead of increasing. Is it just by mere accident or is there a advantage?

[AR]

The stack expands down on the x86. The advantage is that usually programs are structured Code+Data+BSS+Heap at the start then free space then the stack at the end, the stack grows down and the heap grows up which keeps them seperated for as long as possible.

[HOS]

This brings up a question that i have not fully resolved yet. lets say my kernel's stack is at 0xD000_0000 and moves downward. fine. now i move past the first page i have allocated for the stack and i get a page fault. ok. what do i do? allocate a new page and go on? alright.... but what if i subtract 5000 bytes for local storage in a function? then should i map in two pages for the stack space? then what if i get a page fault at my stack pointer minus say 50 pages? how should i know if this is a page fault because a function subtracted that much from esp to reserve local storage (so i should give it the memory) or a page fault because of a malicious process or bad pointer or something? how do the rest of you all deal with this?

[Candy]

unix-way: assume they substracted that much, check if they can use that much stack space, if so, allocate.

windows-way: crash. (seriously! you have to call alloca() on each 4k of memory you use)

[Colonel Kernel]

windows-way: crash. (seriously! you have to call alloca() on each 4k of memory you use)

Are you sure...? Or are you thinking of pre-NT Windows?

I'd like to try that as an experiment...

[Candy]

Local crash of course, it kills your app.

[Colonel Kernel]

I couldn't repro the problem on WinXP (using Cygwin).

Repro.zip

Unless I'm doing something wrong (or maybe they fixed it).

[HOS]

unix-way: assume they substracted that much, check if they can use that much stack space, if so, allocate.

this way sounds good to me, but i wonder about a possible improvement: if it was in fact a stack increase(esp decrease) that caused the page fault, would the address being read/written to ever be less than the value (or that task's value) of esp?

what i mean is, if a function is going to use local variables it first subtracts from esp then references memory from it upward right? so would memory below esp ever get referenced?

if not, could we crash the app if the attempted memory access is below esp and allocate if equal to or greater than esp? (assuming downward-expanding stack)

[Ytinasni]

Unless I'm doing something wrong (or maybe they fixed it).

Stack checking on windows XP(and possibly 2000?) happens every 0x10000 bytes, (16 pages, not 1 page as it was on earlier versions of windows)

They aren't going to 'fix' it, because it is done delibrately.

[Colonel Kernel]

Stack checking on windows XP(and possibly 2000?) happens every 0x10000 bytes, (16 pages, not 1 page as it was on earlier versions of windows)

Thanks for the info! I realized the original repro was probably just using stack space initially allocated by printf(), so I changed _CrashMe() to call itself recursively a given number of times, and after 400 or so invocations it segfaults. Makes sense...

[AR]

In your interrupt handler for the pagefault it should be entirely possible to read ESP and use its value to (de)allocate memory. Just use the registers that were pushed by PUSHA and compare it with a value for the size of the stack or the ESP from the last task switch.

[proxy]

one thing to note is that some instructions like pusha will write the values THEN decrement esp so you have to take tha tinto account, i beleive linux gives stack adjustments 20 bytes of leaway because of this.

proxy