sr (nobody.delete@this.nowhere.com) on October 5, 2021 11:16 am wrote:
> rwessel (rwessel.delete@this.yahoo.com) on October 4, 2021 4:57 pm wrote:
>
> > How does any of that help? You still need to pass pointers to
> > both areas around with limited ability to distinguish the users.
>
> Segmentation done fully has some obvious benefits but it's also obvious that it will inevitable complicate
> programming. So Intel did design it's segmentation so that some segmentation without any effort is possible,
> to use segmentation only to hardware divide stack from other data area in flat address range.
>
> And as it is done with stack in expand-down segment with inverted addressing(from top address to bottom)
> with expand up data segment with normal addressing so that way configured segmented addressing is basically
> 100% same as with without segmentation at all with usual memory allocation - stack to top of addressing
> and data in bottom so they grow towards each others. With segmentation it still retains hardware boundary
> between stack and other data - at some time it was thought as important thing to have.
>


Again, it doesn't do that.

You either have both the stack and data in the same (linear) address space, and there's no real protection between the two. The same effect can be achieved but putting some guard pages between the data and stack areas.

Or you put them in separate segments, and then while there's (a small amount of) protection, you're stuck passing around far pointers all over the place. And the protection is limited, as soon as you pass around far pointers, code will just start loading the stack selector into DS, and accessing it that way.

Or, perhaps you introduce some programming model where data is not allocated on the "real" stack, and you never have pointers to the "real" stack. That can be done a couple of different ways. SPARC and IPF, for example, had separate stacks for saving registers, and those were and least moderately inaccessible to normal code. There was then a parallel stack for function activation records. So a subroutine call generally moved stuff to both stacks (register saves to the register stack, "auto" allocations to the data stack) - in both of those cases subroutine calls only saved return addresses to registers (so saving callee-save registers saved return addresses). That does require an additional register for the parallel stack pointer, and pre-x86-64, that was often a bit of an issue (aa lot of code even avoided using ebp for stack stuff so that it was available for other purposes). For both SPARC and IPF, significant hardware existed to minimize the cost of maintaining two stacks - on something like x86, you'd have to do all that manually.

Or you can allocate activation records on the heap, but that significantly increases overhead (OTOH it would fix most of the small-stack related problems with recursion in many languages).

But even if you did that, it would only protect against accidental stack modifications. Malicious code could still trivially manipulate the x86 stack, either by coding an SS override on an instruction, or by moving the contents of SS to DS.

You appear to be wanting to protect the stack. That's certainly a reasonable goal, but very little such protection is available from the x86 segmentation mechanism. And what little there is can either be fairly trivially replicated with guard pages, or requires significant changes to the programming model used by most code (while still only providing a modest amount of protection).