sr (nobody.delete@this.nowhere.com) on September 25, 2021 10:34 am wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on September 23, 2021 12:01 pm wrote:
>
> > It's just that segments or capabilities isn't it. Too much pain for no real gain.
>
> I understand that people get frustrated with limits like 64KB segment size limit -
> but what's the problem with 386's segmentation model? Segment size is free and code,
> stack and data segments can overlap. Isn't that segmentation done right? 32 bit x86
> always uses segmentation, it doesn't effect to anything if configured that way.
>
> But if want to use it something - divide code from data and stack - gave given part of code
> only access to where it needs it can provide hardware limits to address space where needed.
>
>
> And if divided only to code, data and stack will it complicate things at all?


You can't really, without horrendous impact, divide stack from data on x86. Pointers from both are constantly intermixed. You could move some stack data (register save areas, return addresses, etc.) to a separate parallel stack (like IPF did, and to an extent SPARC), and that could have significant benefits (if you can't overrun an allocated item on the stack and hit a return address, you can't modify return addresses that way), but that requires substantial code overhead to implement (which isn't helped by x86 segmentation), or substantial hardware support (and the RSE on IPF had bugs for mostly the entire existence of the architecture).

As for separating code from data - the NX and W bits in the page tables do that pretty simply.