Segments (was: 80286 protected mode)

George Neuner <gneuner2@comcast.net> writes:

The bad taste of segments is from exposure to Intel's half-assed
implementation which exposed the segment selector as part of the
address.
>
Segments /should/ have been implemented similar to the way paging is
done: the program using flat 32-bit addresses and the MMU (SMU?)
consulting some kind of segment "database" [using the term loosely].

What benefits do you expect from segments?  One benefit usually
mentioned is security, in particular, protection against out-of-bounds
accesses (e.g., buffer overflow exploits).

If the program uses 32-bit (or nowadays 64-bit) addresses, and the
segment number is just part of that, you don't get that protection: An
out-of-bounds access could not be distinguished from a valid access to
a different segment.  There might be some addresses that are in no
segment, and that would lead to a segment violation, but the same is
true for paging-based "security" now; the important part is that there
would be (and is) no guarantee that an out-of-bounds access is caught.

The 286 segments catch out-of-segment accesses.  The size granularity
of the 386's 32-bit segments is coarse, but at least out-of-bounds
accesses do not intrude into other segments.

On the 286 and 386 segment numbers are stored in memory just like any
other data, so an attacker may be able to change the segment number in
addition to (or instead of) the offset, and thus gain access to
sensitive data, so the security provided by 286/386 segments is
limited.  I have not looked closely into CHERI, but I dimly remember
some claims that they protect against manipulation of the extra data
(what would be the segment number in the 286) in the 128-bit address.

Intel had a chance to do it right with the 386, but instead they
doubled down and expanded the existing poor implementation to support
larger segments.

It looks to me that they took the right choices: Support 286 protected
mode, add virtual 8086 mode, support a flat memory model like
everybody else has done in modern computers (S/360, PDP-11); to
combine these requirements, they added support for segments up to 4GB
in size, so people wanting to use flat 32-bit addressing could just
use the tiny memory model (CS=DS=SS) and forget about segments.

I realize that transistor counts at the time might have made an
on-chip SMU impossible, but ISTM the SMU would have been a very small
component that (if necessary) could have been implemented on-die as a
coprocessor.

How would the addresses be divided into segment and offset in your
model?  What kind of addresses would you have used on the 286?  What
would the SMU have to do?  Would a PC have used such an SMU if it was
a separate chip?

If they had made the 286 a kind of real-mode-only 386SX-like CPU, I
think that PCs would have been designed without SMU.  And one problem
would have been that you probably would want 32 address bits to flow
from the CPU to the SMU, but the 286 and 386SX only have 24 address
pins, and additional pins are expensive.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>