Real mode stack

[alexfru]

I think *not sure* SS should be 0x9C00 and SP should be 0xFFFF, so the stack will be at 0x9C00:0xFFFF which is a safe place I guess.

SP should not be 0xFFFF. Make it 0xFFFC, 0xFFFE, or 0 (yep, 0, remember than PUSH first decrements SP and only then writes to memory? So, 0 is good). Make it aligned.

Even allowing for your correction to align the stack correctly, I'm not convinced that it is a good idea to let the stack intrude on the UMA in this way.

Note, I didn't say anything about SS.

[alexfru]

As alexfru wrote, one should make it 'align'. What does that mean? Align it to the start of a new segment?

Aligned = a multiple of the word size (a multiple of 2 bytes for 16-bit modes). It yields better performance. And there could be portability issues. AFAIR, some SSE instructions outright require their memory operands properly aligned (address being a multiple of the size of the memory operand, 8 or 16 bytes or something like that).

[iansjack]

And even in real mode the stack can't keep going down and down. There is a limit to how far down it can go. If a program is so badly written that the stack is going to get that big just make sure that there is no code or data it could collide with. Mind, if the stack does grow that big there are going to be problems anyway.

[Antti]

In reality you should only need a very minimal stack in real mode, and life gets easier once you get to protected and long modes.

In real mode, it is important to have have a stack that is not too small. I would not say "a very minimal stack" is safe. Normally there are interrupts enabled and BIOS interrupt handlers use the stack. How much they use it? What is the exact limit? I do not know the exact limit so I reserve "enough space".

[iansjack]

"very minimal" was probably the wrong phrase to use. But what you need to do in real mode, before going to protected mode, is minimal and very predictable. So it is easy to determine how much stack you need. And it is probable, at this stage, that you have plenty of available space for that stack.

If your real mode code is so unpredictable that there is a danger of the stack underflowing then I think you have big design problems.

[madanra]

This Stack Overflow question suggests 4KiB should be sufficient for the BIOS, though without any references provided. In my bootloader I allow just over 4KiB, which seemed like a good idea at the time. On reflection, a larger stack may better - if you're doing anything that's that memory sensitive, it's probably sensible to work out a way of delaying it until you're in protected/long mode, and you have access to all the RAM.

[Antti]

But what you need to do in real mode, before going to protected mode, is minimal and very predictable. So it is easy to determine how much stack you need.

It is exactly the opposite. It is not predictable at all. Different BIOS implementations do things differently. Also, if your boot loader does anything useful, the work being done in real mode is more than just minimal.

[Combuster]

Basically, what this boils down to is that real mode lacks formal requirements (to know what the stack size should be) and no protection (so we can't trap a stack overflow)

For this reason, safe guesses is all that you can do really. Typical stack locations are from 0x7C00 downward (giving you 30k before running into something else - well above all recommendations), or 0x10000 downward (same size). You could give the stack a full segment and let wraparound contain it, but that's guaranteed overkill. 0x9C00 gives 7K of stack space, which seems arbitrary but is sufficient in most if not all cases. 0x9C000 however is a really bad idea as that's potential EBDA territory.

[azblue]

I personally don't like the way it's designed, there are security problems like there is no end of stack so it keeps going down, down and down until it collides with something really important and we have a crash

I don't see how that can be an x86 flaw; Intel gave us the option to define stack segments that expand down to whatever limit we choose; we choose to toss out genuine stack segments and just use data segments. That's not a flaw in the x86 design; it's a flaw in convention.

[azblue]

Actually, this prompts what I believe is a good question: Is it a good idea to abandon the typical flat mode and create a genuine downward-expanding stack segment with some limit much less than 4GB? (Say, 500MB? 1GB?)

[alexfru]

Actually, this prompts what I believe is a good question: Is it a good idea to abandon the typical flat mode and create a genuine downward-expanding stack segment with some limit much less than 4GB? (Say, 500MB? 1GB?)

If the stack is movable, you now need to either use far pointers or recalculate pointers because now SS != DS and pointers to on-stack variables won't work as simple offsets into the segment pointed to by SS when used with DS. Extra code, extra calculations/checks. Do you want it?

Extra code, calculations and checks if you abandon the hardware stack altogether. Do you want it?

If you still write crap in place of code and still have no idea how much stack it might need, why bother?

[Brendan]

HI,

Actually, this prompts what I believe is a good question: Is it a good idea to abandon the typical flat mode and create a genuine downward-expanding stack segment with some limit much less than 4GB? (Say, 500MB? 1GB?)

Maybe, depending on whether or not you think the advantages outweigh the disadvantages.

Advantages include:

• Potentially better error reports when an application crashes.

Disadvantages include:

• Needing a segment for every thread (and needing something like a GDT entry per CPU that's modified during task switches so you don't end up with a "max. 8000 threads per computer" limit)
• Breaking multi-threaded code generated by most compilers (e.g. one thread can't access a variable on another thread's stack)
• Making fast system call instructions which assume a flat stack segment unusable (SYSENTER and SYSCALL)
• Portability (e.g. not possible in 64-bit code at all)
• Won't do anything at all for some cases (any case were a different pointer is used to access data on the stack)

Note: If you're thinking of doing this, then you might also want to consider having a "per process CS" (especially on systems that don't support "no-execute" page protection).


Cheers,

Brendan

[Combuster]

An other problem is that you can no longer use GCC (or rather, almost all i386 compilers) for a separate stack segment anymore. That's because things like -fomit-frame-pointer will use EBP as a register for anything and use SS where you expect DS, and same for when you pass an address to something that's on the stack, it will probably end up in a different register and use DS where you would expect SS.

Instead people apply paging and use an unallocated page at the bottom of the stack to trap stack overflows.

[qw]

Bender, you seem to think that room for the stack should be included in the binary. Do you?

[Bender]

Bender, you seem to think that room for the stack should be included in the binary. Do you?

No, but i feel it's the safest option, I don't really oppose anyone on setting the stack to somewhere safe-and-sound memory location, but as i see it these locations can vary from machine to machine, so i always set the stack to some free space included inside the binary. (preferably at the start if there are any stack overflows).