Static Variables

Hi all,

where static variables will be stored , in data segment or stack segment or in Heap?


Suri

i guess it depends on your OS/compiler combo...
but never in the stack segment!

since you talk about segments, it is 16bit code, no?

for 32bit, afaik all data goes on the heap and you could say "data segment == codesegment == heap".

[disclaimer]
i am not a compiler pro, so this might be completely wrong...
[/disclaimer]

anyway, why do you care?

Static variables go to your data segment, along with your global variables. The stack segment is for local non-static variables and arguments passed to functions. The heap is used for carving out dynamically allocated variables (for example, when you use malloc(), calloc(), strdup() etc.)

As MHirsch pointed out, on a 32 bit compiler, segments don't really exist because of the flat memory model. However, something similar does exists, they are called sections. Most object files have at least 3 sections within them (i.e.)
data: for initialized global variables
bss: for uninitialized global variables
text: for the actual code itself.
With a 16 bit compiler, each section may occupy its own segment in memory, depending on the compiler settings. BTW the above section info holds true for both gcc and turbo-c. You can see what it puts in each section by generating a map file when you compile a program. In gcc, the option goes something like -Wl,-Map,foo.map and in turbo-c, it is an option in the menu somewhere.

The linker takes all the obj files and merges the sections individually (i.e. all text sections together, all data sections together etc.) to produce the final executable.

As an aside, in OpenBSD, they are making an effort in the upcoming versions to mark the data, heap and stack areas of a program in memory as non-executable. This will reduce attacks caused by buffer overflows. Some CPUs (such as Sparc and Alpha) support this natively, but Intels don't and so this has to be handled by the OS.

Hi Scorpion4server,

Thanks for great explanation . Thanks for ur support .

as per u r reply :

In OpenBSD, they are making an effort in the upcoming versions to mark the data, heap and stack areas of a program in memory as non-executable. This will reduce attacks caused by buffer overflows.

Actually i haven't undestood it properly . Can u clarify me in detail .



Suri

i won´t explain the details here, but:

if you don´t do correct input buffer length checking, one could send a string of 1000 chars into a variable of size 100. once pushed on the stack, it will overwrite the back-jump address of the calling function. if you do this "correctly", it will execute the program code that you put into the string.... HACKED! This is called a "buffer overflow"

to prevent this, some OSs don´t allow code on the stack to be executed. (for linux there is a patch and a kernel module that can do the same. but i read somewhere that there is programs that rely on code on the stack being executable - bad programming...)

Yep, M. Hirsch described the situation pretty accurately there. For a more technical article, check out http://www.insecure.org/stf/smashstack.txt

i didn´t feel like posting that kind of info here. but now that i think about it...
I bet there is few script kiddies here and more admins/programmers that will take advantage of this kind of information.

I´ll start a post in the lounge to see what people think about it...

> if you don´t do correct input buffer length checking, one could send a string of 1000 chars into a variable of size 100

i thought that's exactly what causes a segmentation fault error? why doesn't that cause a a segmentation fault?

segfaults occur if you have an invalid address, but you supply the right "code" and the address is valid since code on the stack or in the data "segment" is allowed. That´s the trick. Of course, after the program executed your code, it will probably hang, quit or segfault. But then it´s too late