[COFF] [TUHS] man-page style

[bakul at bitblocks.com (Bakul Shah)]

KeyKOS had a lot in common with Multics. It had a ingle level store.
A KeyKOS system could stay on for a long time or can be restarted
from a snapshot. The kernel had no state of its own that needed
saving so snapshotting was easy. Unlike Multics' protection rings
it was a capability system so provided better security. KeyKOS
inter domain call was synchronous: the caller blocked until the
callee process was ready to accept the call. A later system EROS
was an evolution of KeyKOS and open source.

All of this would be easily possible on the Mill arch. if ever
it gets built. Mill has segments and protected function calls.

set-uid has its own issues. Plan9 doesn't have it.

On Nov 17, 2018, at 12:09 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> To explain how this was even possible, you need to know a tiny bit about
> Multics. It was a 'single level store' system; process memory and files were
> not disjoint (as in UNIX), there were only segments (most of which were
> long-lived, and survived reboots); processes had huge address spaces (up to
> 2^18 segments), and if you needed to use one, you just mapped it into your
> address space, and off you went.
> 
> So he wrote his code, and if I in my command process executed the 'TELNET'
> command, when it needed to open a TCP connection, it just mapped in his TCP
> code, and called TCP$open() (or whatever he named it). It fiddled around in
> the networking state (which was in a data segment that Dave had set up in his
> 'networking' process when it started up), and set things up. So it was kind of
> doing a subroutine call to code in another process.
> 
> The security wasn't good, because Multics didn't have set-uid (so that only
> Dave's code would have had access to that state database) - when they later
> productized the code, they used Multics rings to make it secure.
> 
> But still, that was pretty amazing. The key thing here is that nobody had to
> modify the Multics 'kernel' to support adding networking - the basic
> mechanisms (the single-level store, etc) were so powerful and general you
> could write entirely new basic things (like networking) and add them 'on the
> fly'.
> 
> 
> What Multics had was quite different from ukernels, but it amounted to the
> same thing; the system wasn't this monolithic blob, it was
> layered/modularized, and you could see (and gain access to, and in some cases
> replace - either just for yourself, or for everyone) the layers/modules.
> 
> The nice thing was that to call up some subsystem to perform some service for
> you, you didn't have to do IPC and then a process switch - it was a
> _subroutine call_, in the CPU's hardware.
> 
> I don't think anyone else ever tried to go down that path as a way to
> structure an operating system (in part because you need hardware support), and
> it's a pity. (UNIX, which would run on anything, killed just about _everything
> else_ off.)
> 
> The 386-Pentium actually had support for many segments, but I gather they are
> in the process of deleting it in the latest machines because nobody's using
> it. Which is a pity, because when done correctly (which it was - Intel hired
> Paul Karger to architect it) it's just what you need for a truly secure system
> (which Multics also had) - but that's another long message.