Interview questions: Stack direction
A couple of days ago I noticed a link on del.icio.us popular to a list of programming interview questions from, allegedly, Google and Microsoft. Anyway, for the sake of having something to put up here, I’m going to post my solutions to a few…Hopefully someone will tell me if I’ve gone wrong along the way ![]()
Stack Growth : How would you find out if a machine’s stack grows up or down in memory?
Well, it’s fairly simple to write a C program to test this. Obviously I’m assuming that a C compiler is available. The following program creates an integer (a) on the stack, then passes a pointer to a down to the function sub. sub creates another integer on the stack (b), then compares the address of a to the address of b. If b’s address is greater then a’s, then the stack is growing up, if it’s less, then it’s growing down.
#include <stdio .h>
void sub(int *a) {
int b;
if (&b > a) {
printf("Stack grows up.");
} else {
printf("Stack grows down.");
}
}
main () {
int a;
sub(&a);
}
That said, perhaps there’s an easier way. I’m not aware of any standard tool which could tell me directly, though I wouldn’t be surprised if there were one. A bit of searching turned up a shell script which does the same thing but does the compilation for you, which is cute (but obviously OS dependent). Wikipedia tells me that most modern OSes grow the stack down which is odd given the security advantages of doing it up.
For what it’s worth, it goes down both on my Mac and a Linux box I have an account on. I’ll have to check Windows next time I have a chance.
May 15th, 2007 at 2:17 pm
Why can’t we declare two integers in the main() function and check if the stack grows up or down? Any reason for creating a separate sub() function?
May 15th, 2007 at 6:41 pm
Which integer of the two would we expect to be higher / lower in this case? I’m not sure there’s anything to say they would go into main’s stack frame in a particular order, especially if the compiler is trying to optimise (but I’m no expert).
With the sub function, we know for sure that the second integer will be in a different stack frame, which must be either higher or lower (and hence everything in it will be higher or lower).
Am I missing something?
May 16th, 2007 at 4:00 am
oh ok.
June 29th, 2007 at 3:42 pm
Nice one!
Thx
October 23rd, 2007 at 1:28 pm
What are the security advantages of doing(stack growth) it up ? Can you give me a clear link ?
I think, that link did not have any details about the advantages of doing it Up.
I find that in the wikipedia link provided in the above article, it is talking about stack overflow which would be present for implementations involving stack growth in upward direction. Even the crash can happen for implementations involving stack growth in upward direction.
But, there is no mention of specific disadvantage mentioned w.r.t Stack growing in upward direction.
I find these lines only in wikipedia w.r.t disadvantages . There is no mention of disadvantage w.r.t stack growing in downward direction ->
“A disadvantage of stack based memory allocation is that a thread’s stack size can be as small as a few dozen kilobytes. Allocating more memory on the stack than is available can result in a crash due to stack overflow. Another disadvantage is that the memory stored on the stack is automatically deallocated when the function that created it returns, and thus the function must copy the data if they should be available to other parts of the program after it returns. ”
Thx,
Karthik Balaguru
October 23rd, 2007 at 1:31 pm
Corrected Query :
What are the security advantages of doing(stack growth) it up ? Can you give me a clear link ?
I think, that link did not have any details about the advantages of doing it Up.
I find that in the wikipedia link provided in the above article, it is talking about stack overflow which would be present for implementations involving stack growth in downward direction.
That can happen for stack growing in upward direction also.
Even the crash can happen for implementations involving stack growth in both downward and upward direction.
But, there is no mention of specific disadvantage mentioned w.r.t Stack growing in upward direction.
I find these lines only in wikipedia w.r.t disadvantages . There is no mention of disadvantage w.r.t stack growing in downward direction ->
“A disadvantage of stack based memory allocation is that a thread’s stack size can be as small as a few dozen kilobytes. Allocating more memory on the stack than is available can result in a crash due to stack overflow. Another disadvantage is that the memory stored on the stack is automatically deallocated when the function that created it returns, and thus the function must copy the data if they should be available to other parts of the program after it returns. ”
Thx in advans,
Karthik Balaguru
October 23rd, 2007 at 1:44 pm
Hi,
Can you share your views for this hot discussion w.r.t “direction of stack growth” -
http://groups.google.co.in/group/comp.arch.embedded/browse_thread/thread/1243efba95ebc0/9aaf2f6c899007a9?hl=en&
snapshot of the query :
Why some processors have stack growing downwards and others have stack growing upwards ?
Any advantages/disadvantages w.r.t both these designs. Which is the best model ?
I serached the internet, but i did not find a good link that explains these stuffs in detail.
Thx in advans,
Karthik Balaguru
October 23rd, 2007 at 6:22 pm
Looks like the Wikipedia page has been rearranged a bit. The text below gives a bit of an idea of the suggested advantages. Sounds like it’s not really a significant defence however, given that it just changes the required mode of attack.
http://en.wikipedia.org/wiki/Stack_buffer_overflow#Stacks_that_grow_up
Stacks that grow up
Within the topic of stack buffer overflows an often discussed but rarely seen architecture is one in which the stack grows in the opposite direction. This change in architecture is frequently suggested as a solution to the stack buffer overflow problem because any overflow of a stack buffer that occurs within the same stack frame can not overwrite the return pointer. Further investigation of this claimed protection finds it to be a naïve solution at best. Any overflow that occurs in a buffer from a previous stack frame will still overwrite a return pointer and allow for malicious exploitation of the bug. For instance, in the example above, the return pointer for foo will not be overwritten because the overflow actually occurs within the stack frame for strcpy. However, because the buffer that overflows during the call to strcpy resides in a previous stack frame, the return pointer for strcpy will have a numerically higher memory address than the buffer. This means that instead of the return pointer for foo being overwritten, the return pointer for strcpy will be overwritten. At most this means that growing the stack in the opposite direction will change some details of how stack buffer overflows are exploitable, but it will not reduce significantly in the number of exploitable bugs.
April 23rd, 2008 at 10:13 am
Very late to the party, but here’s food for thought:
I’ve been thinking about this recently, since I am prepping for upcoming interviews and re-exercising some old coding muscles.
Anyway, this is more or less the solution I came up with… but, unless I am mistaken… it’s not guaranteed to work by the C standard. The C standard (accoring to my sources, possibly dated) only guarantees comparisons of pointers by use of < will work “as expected” when comparing pointers inside the same array.
There are no guarantees that it will work in the way it is being used to solve this problem.
Have recent standards provided guarantees what happens when arbitrary pointers are compared?