Am I growing the stack correctly?

[theycallmeloopy]

I'm making an OS using GCC on Cygwin, NASM, and GRUB. I'm in pmode and I've reprogrammed the PICs and set up a GDT and IDT. I can respond to keyboard interrupts.

Next I want to make my own kernel stack. I'm guessing GCC has already set one up for me and that if I push too much data I'll start overwriting my kernel. Is that right?

Here's how I think I should proceed:

1) Write some basic memory management routines involving paging.

2) Mark my kernel code area as used.

3) Put a guard page just above my kernel code (end of stack) and just above the stack (start of stack).

4) If I get a protection fault because my stack is full, allocate more space and point my stack pointer there. Add more guard pages. If I push too far again, allocate more space. If I pop too far, move the stack pointer back to the previously allocated area.

Is this even close? I'm really new to all of this and I don't know if I'm using the right terminology. Also, where should I store information about where the parts of my stack begin and end? On the heap using a custom malloc() or something?

I just wanted to run this past experienced OS devvers before trying to implement it and getting it wrong. Thanks for your patience and help.

[Pype.Clicker]

GCC didn't prepare anything. If you haven't reloaded esp, you're still in GRUB's stack.

The best way to reserve space for your stack will be to declare a large "resd" array in .bss section in your ASM startup file.

Code: Select all

section .bss
stack:
      resd STACK_SIZE
.end:

section .text
_kernel_entry_point
      mov esp, stack.end
      ; do more initialisation stuff
      call kmain
      cli
      hlt

Now, at the "page guard" idea, beware ... Take a sit, a cup of steamy drink and a moment to think about it.

<Fenring> What's going to happen when your kernel will try to write to the guard page ? hmmmm ah ... A page fault. What does the CPU do when an exception occurs ? it pushes the eip and cs values on the stack ... but how will it do it if the top of the stack cannot be accessed ? hmmmm ahh ...
</Fenring>

I guess you bet it. Using page fault trap cannot be used on kernel stacks. Only in usermode stacks. What you can use instead is segments protection, which will give you a stack fault exception which you can catch through a task gate exception handler.

[theycallmeloopy]

Thanks, Pype. I think I understand what you are saying. I do have a couple more questions:

What happens when an exception occurs in user mode? Do the ip and cs not get pushed, or are they pushed somewhere other than the user mode stack? How do you avoid the same problem?

Also, I've heard some people here recommend against segmentation. Is it "safe enough" just to give myself a fairly-sized kernel stack and leave it at that? Are there any pitfalls to avoid having my stack grow too much?

Thanks again.

[Pype.Clicker]

when an exception occurs in 'user mode', nothing is pushed on the user stack.
- either the exception descriptor is a TASK gate in which case a task call occurs and the exception is handled on the new tasks' stack (the handler will have to check TSS.backlink to learn about the faulty task, then inspect that task's TSS to get the required context information)

- or the descriptor is a TRAP gate, in which case the CPU retrieves SS0 and ESP0 from the current TSS and pushes what it needs to push there.

All this (and much more) are comprehensively detailed in the Holy Intel Manual

[Pype.Clicker]

@segmentation and stuff ... well, if you can make sure enough that a kernel stack overflow will **never** occur, that's nice for you. Personnally i wouldn't like to count on this (would it only be for the case of an endless nested invocation of exception handlers)

We need to know what we want here. Personally i prefer to use every option my target architecture offers to make my life easy, which includes using segments to protect against kernel stack overflow, yes ... and if i had to port Clicker to another architecture, i would search for another trick to protect stack on that very architecture ...

And if you wonder why i don't simply use a TASK gate for page fault, just compare the overhead for processing a TASK switch vs a TRAP and then give a look at the amount of #PG that occurs everyday on a well-written program because of virtual memory, copy-on-write, etc.

I think you get my point

[theycallmeloopy]

Thanks for the tips. I will investigate these options.

I guess I got a little ahead of myself. Everything I know about the GDT, IDT, and PICs I got from reading the Intel manuals. There's no reason I shouldn't read as much (or all) of it as I can before continuing.