user space stack size

[FlashBurn]

One other thing, why do you want 2 guard pages? Is there an advantage to using 2 rather than 1?

One for the bottom and one for the top!

Huh? Address space layout randomization doesn't prevent someone from writing working code, just prevents them from writing exploits. Return-to-Libc attacks are one of the biggest classes at the moment.

I don´t know if you got the thing I said right or if I misunderstand you. I mean that writing code to secure the system of buffer overflows and such things, prevent the a app programmer to not write code that doesn´t has such leaks.

Another point is, that I want to get the damn thing working So I will do the best I can get, but I do not want to make things too complicated.

Maybe I need to explain my idea of guard pages.

The 1st thread will get, e.g. 16kb of stack:

Code: Select all

0x500000 - 0x501000 stack guard page
0x501000 - 0x505000 stack mem
0x505000 - 0x506000 stack guard page

(Incidentally, I have an app here which allocates ~32kb of RAM on the stack in one go regularly; it would quite readily jump past any guard pages unintentionally)

But what happens if the thread only got a stack of 16kb and the heap is so big that it is just before the stack. So when this app now writes at a position which is far away from its stack it will overwrite the heap and I don´t think that any operating system can do anything about such a problem.

This is only an example:

Code: Select all

0x00400000 - 0xBFFFC000 heap
0xBFFFC000 - 0xC0000000 stack

[/code]

Code: Select all

[midir]

(Incidentally, I have an app here which allocates ~32kb of RAM on the stack in one go regularly; it would quite readily jump past any guard pages unintentionally)

I thought all languages tested pages one by one when they allocate any significant amount of stack space, using some equivalent of __chkstk or __alloca_probe.

See e.g.,
http://support.microsoft.com/kb/100775 for a description of how it works in Windows
and
http://www.jbox.dk/sanos/source/lib/chkstk.asm.html for an implementation.

This is something I recently encountered in my OS when I had an array whose size was not known until runtime as a function-local variable. To prevent exceeding the stack, GCC inserted an automatic call to __chkstk and the linker kept complaining it was undefined, until I gave it one.

One for the bottom and one for the top!

There's probably no need. The stack will grow downwards through normal use, but if it goes out the top, then clearly it's catastrophically corrupt and the program will crash a millisecond later anyway.

[midir]

Actually, beg pardon, I noticed (24 hours later) that apparently that stack-probing thing is Windows-specific:
http://wiki.osdev.org/How_kernel,_compi ... 2C____main

[FlashBurn]

Does someone know how linux does it? I think I will take a little different approach, I make the stack, e.g. 16kb big and after 16kb comes the guard page and all pages between the mapped pages and the guard page, become a special flag, so when a paging exception occurs I only have to map in a new page. So a program doesn´t need to probe the stack.

I also realized that I made a wrong assumption, the stack grows downwards, but a buffer "grows" upwards. So the guard page above the stack could stop some (not all) buffer overflows.

[skyking]

Linux does not seem to do anything special about the stack. The stack segment is allowed to grow as specified by the RLIMIT_STACK parameter beside that stack is just memory and the stack pointer can point to anywhere you like (but preferably to address space where you have read write access). If you read/write where you don't have proper access you'll get SIGSEGV. You can find out the memory map via /proc/<pid>/maps and modify it via mmap/munmap/mprotect syscalls.

If you have a lot of threads you may as you stated run into problems where the stack cannot grow since it would run in to another threads stack, to solve this you have to handle the possibility that the stack becomes non-continuous (which could be quite tricky).

Btw, guard pages on both sides will be there automatically since the guard is just something you place between memory block. The guard below a memory block will work as guard for the memory block located below this guard.

[FlashBurn]

Btw, guard pages on both sides will be there automatically since the guard is just something you place between memory block. The guard below a memory block will work as guard for the memory block located below this guard.

The idea is not bad, but it would also waste 4kb every time you call the kernel for more memory. And if you every time only need a 4kb block you would waste half of the address space (worst case).

@offtopic
As I read yesterday, Linux still has no true thread support?!

[Kitsune]

@offtopic
As I read yesterday, Linux still has no true thread support?!

From what I know, Linux has had true threading support since 2.6, with the Native POSIX Thread Library (NPTL, as opposed to LinuxThreads before that).

Before 2.6, the different threading implementations on Linux basically used very ugly and horrifying hacks.

[FlashBurn]

NPTL uses a similar approach to LinuxThreads, in that the primary abstraction known by the kernel is still a process, and new threads are created with the clone() system call (called from the NPTL library).

I don´t know if this is right, but as I understand it, it is the same as before. But I have to admit that I don´t get whole picture how this is working.

@back to topic
I haven´t had a look at the gcc documentation, but is there a switch or something like that for changing the stack size? Or is this a problem for the OS?