[inforoots] Page vs segment (was he IBM 7090 & Yacht Handicapping)

[Mike Albaugh]

> From: Tom Van Vleck <thvv at multicians.org>
> Date: Thu, November 17, 2005 1:45 pm
> To: inforoots at computerhistory.org

> The design of the 360/67 included memory organization very
> similar to that proposed in the ten Multics hardware design
> memos.  So similar that IBM later paid MIT a big hunk of
> money to settle patent infringement claims.  One of the
> senior designers of the 645 told me that the 360/67 was
> missing a few crucial concepts from the Multics design, as
> if the IBM team had only seen nine of the ten memos; one
> important difference was that the 645 had access control
> in the segment descriptor, while the 67 had it on the
> physical page's storage key, which made memory sharing
> difficult.

 From what I remember, the storage-key was something like
the PID-part of a fully-decorated page-table entry. I can see
how this could make sharing tedious, having to change the
key every time you context-switched, but tedious is not the
same as impossible, and presumably something akin to
copy-on-write hacks could be applied -- have all pages owned
by "nobody" until someone accesses them, then "manually"
check permissions and "give" them to current process
with its permissions. On context-switch, re-chown the
pages you touched back to "nobody" . Yep, PITA, but the
segments would limit the range of possible attempts, no?

For completeness, the other way round can be equally
hazardous: The x86 until quite recently had the distinction
between "readable" and "executable" only in the segment
registers, not the page-map. But since the average
"buy-em-by-the-dozen" self-taught C++ programmer
can't really cope with segments, all segment registers,
while theoretically distinct, typically point to the same
virtual address-space, which uses the same page-table
entries. So, even though the "data" segments could be
marked "do not execute", they used the same page-table
entries as the code segments, which is really cool for
C++ hacks involving pushing code on the stack (read-write
access) and then executing it (Read-execute access). Also
cool for all that tasty stack-overflow malware . AMD fixed this,
and Intel followed suit, leaving most folks with a false sense
of security. Just because the CPU won't treat any given byte
as native code, doesn't mean it isn't a "program".  Javascript
worms, anybody? Security is hard work.

  Mike