Can having an invalid stack pointer (even momentarily) cause you to lose data?

1
votes

Let's say that -- for some strange reason -- the stack pointer, ESP, for some function gets decremented momentarily and then incremented again:

;; ... we're saving registers ...
push EAX
push EBX
push ECX
push EDX

add ESP, 4        ;; Whoops!
sub ESP, 4        ;; Ah, we're fine; we restored it... or are we?

Now, it's perfectly possible for an interrupt to get triggered immediately before your sub instruction.

If I understand correctly, an interrupt will cause the CPU to push a few values onto the stack.

Does that mean your stack will now be corrupted? Or does the OS somehow (how?) use a different stack/memory to store the context of the program? Or does it depend on the privilege level of the CPU? (If so, how?)

4
assemblyx86stackinterruptcorruption
I'll go look it up, interrupts using the same stack as user-mode processes is definitely not what I've learned. – harold
@harold: Yeah thanks, that's precisely what made me wonder -- I was looking things up on OSDev and noticed it said interrupts push a few things on the stack, which made me second-guess myself... – user541686
Ok I found it, the stack switch is done first and then the "stuff" is pushed onto the new stack. But that happens only on a privilege level change. – harold
@harold: Interrupts cause a privilege level change, though, don't they? – user541686
Usually, but not necessarily. – harold

4 Answers

3
votes

Subtracting then adding on x86 would be fine. It's how local variables are handled. However, do the reverse and you could have data corruption if an interrupt occurs. The add would free the space, then the sub would allocate it again (with the contents no longer being guaranteed the same).

1
votes

With a shared stack (program and interrupts) at no time do you want to have the stack pointer itself pointing at information you do not want to be changed or lost. An interrupt can come along and modify that information. So subtracting, meaning moving the stack pointer farther away from important data, is fine, when finished with that new allocation, you can return the stack pointer with the understanding that that new data is no longer available. You also need to be careful with aligment when messing with the stack pointer itself. IN this case a sub then an add is okay, an add then a sub can cause lost data.

1
votes

If the above code is in the beginning of an ISR, whose interrupt descriptor is marked as "interrupt gate" as opposed to "trap gate" and you haven't yet manually enabled interrupts inside the ISR (with STI or POPF), there will be no problem because in this case the CPU automatically clears FLAGS.IF when entering the ISR.

Also, if the interrupt causes a transition between protection levels, the CPU pushes stuff (EFLAGS, return address and old SS:ESP) onto the new stack, the old stack is untouched.

0
votes

This post seems to contradict the answers above, stating that it this is in fact safe:

Aren't you screwed if an interrupt occurs?

Those of you who have programmed in DOS are likely squirming at this point about the possibility of interrupts. Ordinarily, reusing the stack pointer like this is a really bad idea because you have no idea when an interrupt might strike, and when one does, the CPU dutifully pushes the current program counter and flags onto the stack. If you have reused ESP, this would cause random data structures to be trashed. In this kind of environment, ESP must always point to valid and sufficient stack space to service an interrupt, and whenever this does not hold, interrupts must be disabled. Running with interrupts disabled for a long time lowers system responsiveness (lost interrupts and bad latency), and isn't practical for a big routine.

However, we're running in protected mode here.

When running in user space in Win32, interrupts do not push onto the user stack, but onto a kernel stack instead. If you think about it, it isn't possible for the user stack to be used. If the thread were out of stack space, or even just had an invalid stack, when the CPU tried to push EIP and EFLAGS, it would page fault, and you can't page fault in an interrupt handler. Thus, the scheduler can do any number of context switches while a no-stack routine is running, and any data structures that are being pointed to be ESP will not be affected.