Reply to post: Multics Hardware security

Multics resurrected: Proto-Unix now runs on Raspberry Pi or x86

Mike 16 Silver badge

Multics Hardware security

Funny you should mention Multics on Modern Hardware. When I first got the docs on the 80286, I said to myself: "looks like they want to run Multics on this beast". Rings, real segments, etc. Then I started using it and found that the segments were not quite as lovely as they were described (loading a descriptor was slow, and no caches for them). Intel could have fixed this for the 386, but it seems that the Great Unwashed _really_ wanted a memory model just like whatever Vax or SunOs machine they had in school, so they added fairly conventional page-maps as well. The death knell was probably when the folks who thought it was the bee's knees to execute code on the stack led the march to "forget segments" and map them all to one flat (page mapped) address space.

I also recall fighting with a gcc re-target over which of the configuration stuff to control things like stack layout would actually do so, or was "more like guidelines, really". Had to wonder WTF they would do with something like the IBM360 ABI that allowed "bushy stacks" (ala Burroughs) or the Power or Natsemi16032 that supported function pointers that were more than an index of octets in the one undifferentiated memory space.

In summary, Modern Hardware (for some values of "Modern") has at least vestigial support for Multics-worthy security and isolation. Modern Software developers for the most part seem more willing to eat a live toad than accept the constraints (and re-training) that might involve.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019