Hi,
I am making an (x86) OS and have a few questions
a) what size should the stack be for a process? I was thinking 16K (4 pages) but I don't really know. even with the sources to linux I can't work out the stack size for a new process in Linux.
b) how do u stop a stack overflow using a flat memory model? I was thinking having a supervisor page underneath the stack pages so that it would page fault.
Stack Questions
-
anton
RE:Stack Questions
You don't have to wory abour stack under Linux: it has a growing stack, that means that if there is a stack overflow, kernel will add more pages to the stack.
Anton
Anton
-
tom1000000
RE:Stack Questions
Oh well I'm a bit confused.
Say ESP starts at 4000 0000h, what happens if you deliberately create a stack overflow? Linux can't keep adding to the stack forever.
Also what happens with threads? I am under the impression that threads all have the same address space but different stacks (and register values obviously). Where do these extra stacks go?
I am trying to understand this in relation to creating a new OS.
Say ESP starts at 4000 0000h, what happens if you deliberately create a stack overflow? Linux can't keep adding to the stack forever.
Also what happens with threads? I am under the impression that threads all have the same address space but different stacks (and register values obviously). Where do these extra stacks go?
I am trying to understand this in relation to creating a new OS.
-
carbonBased
RE:Stack Questions
Well, really, you _can_ add stack forever - or at least until you run out of physical and virtual memory. Obviously you'd want a cut-off point, if you're dynamically allocating stack. Perhaps you set your OSs max stack to, for example, 50 pages. Or check to see if the application is in a "stack expanding loop"... where all it's doing is continually overrunning the stack, and terminate if so.
As for the threads, yes, I do believe most OSs have threads in the same address space. Otherwise, there really isn't much distinction (if any?) between a process and a thread. What do you mean "where do the extra stacks go?", though?
Hmm... actually, I think I know what you mean, now. How about this; when creating a thread, copy the current page directory and tables, except for the pages referencing the stack. Those pages will be setup separately for the new thread, thus allowing each process and thread to all have their stack at the same linear address (say, 0xf0000000, for example).
An alternative, of course, is simply to allocate a new stack somewhere else in linear memory... there's no rule that says all processes have to have the exact same linear memory layout. Of course, in this situation you'd still have to alter the page directories and tables so that the parent processes stack is read only. I don't think a thread should be able to screw with the parents stack
Jeff
As for the threads, yes, I do believe most OSs have threads in the same address space. Otherwise, there really isn't much distinction (if any?) between a process and a thread. What do you mean "where do the extra stacks go?", though?
Hmm... actually, I think I know what you mean, now. How about this; when creating a thread, copy the current page directory and tables, except for the pages referencing the stack. Those pages will be setup separately for the new thread, thus allowing each process and thread to all have their stack at the same linear address (say, 0xf0000000, for example).
An alternative, of course, is simply to allocate a new stack somewhere else in linear memory... there's no rule that says all processes have to have the exact same linear memory layout. Of course, in this situation you'd still have to alter the page directories and tables so that the parent processes stack is read only. I don't think a thread should be able to screw with the parents stack
Jeff
-
anton
RE:Stack Questions
Threads have there stacks in one address space, else threads would have been pointless, they would be like forked processes.
Anton.
Anton.
-
carbonBased
RE:Stack Questions
That's exactly what I said in my reply. Threads should be in the same address space, or else there's no difference between a thread and a process.
The thing is, the stack itself can be anywhere withen that address space. There's no reason, that I can see, to map each thread's stack into each other thread's address space. Should threads be able to mess up other threads stacks?
I would maintain the same address spaces, except the stack; have each threads stack at the same linear address (as each process, in my OS, anyway, has its stack at the same linear address).
Perhaps it's fruitless to do so, but to me, it'd afford a little bit more security. It would only add an initial complication when starting a new thread (and use some more memory for a couple page tables and the page directory (most pt's could be reused).
Jeff
The thing is, the stack itself can be anywhere withen that address space. There's no reason, that I can see, to map each thread's stack into each other thread's address space. Should threads be able to mess up other threads stacks?
I would maintain the same address spaces, except the stack; have each threads stack at the same linear address (as each process, in my OS, anyway, has its stack at the same linear address).
Perhaps it's fruitless to do so, but to me, it'd afford a little bit more security. It would only add an initial complication when starting a new thread (and use some more memory for a couple page tables and the page directory (most pt's could be reused).
Jeff
-
carbonBased
RE:Stack Questions
If you're interested, the KOS system uses an expanding stack. The double fault handler is a task switch gate (which is essential, because any exception will cause a double fault (and then a triple fault) in the case of a stack fault, because (the nature of the exception is...) the ss:esp combo in invalid).
The double fault exception then checks to see if the fault happened withen the stack area, and if so, maps another page to the end of the stack.
This system also relys on having an empty, unmapped page (unpresent) at the end of the stack, to "grow into" and cause the actual fault.
Check the KOS docs for more information,
Jeff
The double fault exception then checks to see if the fault happened withen the stack area, and if so, maps another page to the end of the stack.
This system also relys on having an empty, unmapped page (unpresent) at the end of the stack, to "grow into" and cause the actual fault.
Check the KOS docs for more information,
Jeff