From dave at horsfall.org Fri Nov 2 05:55:21 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Nov 2018 06:55:21 +1100 (EST) Subject: [COFF] Happy birthday, Morris Worm! Message-ID: The infamous Morris Worm was released in 1988; making use of known vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was accidental, but the idiot hadn't tested it on an isolated network first). A temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh". Another fix was to move the C compiler elsewhere. -- Dave From cym224 at gmail.com Fri Nov 2 09:49:17 2018 From: cym224 at gmail.com (Nemo Nusquam) Date: Thu, 1 Nov 2018 19:49:17 -0400 Subject: [COFF] Happy birthday, Morris Worm! In-Reply-To: References: Message-ID: <224e4e62-9e2b-0d99-9937-603f505856e6@gmail.com> On 11/01/18 15:55, Dave Horsfall wrote: > The infamous Morris Worm was released in 1988; making use of known > vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out > a metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it > was accidental, but the idiot hadn't tested it on an isolated network > first). Must have certainly embarrased his father. N. > A temporary "condom" was discovered by Rich Kulawiec with "mkdir > /tmp/sh". > > Another fix was to move the C compiler elsewhere. > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From dave at horsfall.org Fri Nov 2 11:02:26 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 2 Nov 2018 12:02:26 +1100 (EST) Subject: [COFF] Happy birthday, Morris Worm! In-Reply-To: <224e4e62-9e2b-0d99-9937-603f505856e6@gmail.com> References: <224e4e62-9e2b-0d99-9937-603f505856e6@gmail.com> Message-ID: On Thu, 1 Nov 2018, Nemo Nusquam wrote: > Must have certainly embarrased his father. It certainly did :-) I understand he received a stern "talk"... -- Dave From cym224 at gmail.com Tue Nov 6 23:53:16 2018 From: cym224 at gmail.com (Nemo) Date: Tue, 6 Nov 2018 08:53:16 -0500 Subject: [COFF] BWK's latest tome Message-ID: PUP sent out an announcement of BWK's latest tome (https://press.princeton.edu/titles/14171.html). I am bemused that his accolades do not mention UNIX (and yes, target audience and all that). N. From dave at horsfall.org Sat Nov 10 10:18:49 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 10 Nov 2018 11:18:49 +1100 (EST) Subject: [COFF] In memoriam: Gene Amdahl Message-ID: We lost computer architect Gene Amdahl on this day in 2015; responsible for "Amdahl's Law" (referring to parallel computing), he had a hand in the IBM-704, the System/360, and founded Amdahl Corporation (a clone of the 360/370 series). -- Dave From dave at horsfall.org Sun Nov 11 06:05:40 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sun, 11 Nov 2018 07:05:40 +1100 (EST) Subject: [COFF] Happy Birthday, Donald Michie and Robert Fano! Message-ID: Donald Michie, a computer scientist, was born in 1923; he was famous for his work in AI, and also worked at Bletchley Park on the "Tunny" cipher. And Robert Fano, Computer scientist and Professor of Electrical Engineering at MIT, was born on this day in 1917. He worked with Claude Shannon on Information Theory, was involved in the development of time-sharing computers, and was Founding Director of Project Mac, which became MIT's AI Lab. -- Dave From dave at horsfall.org Tue Nov 13 05:45:58 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 13 Nov 2018 06:45:58 +1100 (EST) Subject: [COFF] Happy birthday, Per Brinch Hansen! Message-ID: Computer scientist Per Brinch Hansen was born on this day in 1938; he was known for his work on "monitors" (now known as operating systems), concurrent programming, parallel processing, etc. -- Dave From dave at horsfall.org Fri Nov 16 08:33:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Fri, 16 Nov 2018 09:33:34 +1100 (EST) Subject: [COFF] In Memoriam: Jay W. Forrester, happy birthday Gene Amdahl, and LSD Message-ID: Weird day... Computer architect Gene Amdahl was born in on this day in 1922; he had a hand in the IBM 704 and the System/360, founded Amdahl Corporation (maker of /360 clones), and devised Amdahl's Law in relation to parallel processing. But we lost Jay W. Forrester in 2016; another computer pioneer, he invented core memory (remember that, with its destructive read cycle?). Oh, and LSD was first synthesised in 1938 by Dr. Hofmann of Sandoz Labs, Switzerland; it had nothing to do with Berkeley and BSD, man... -- Dave From gtaylor at tnetconsulting.net Sat Nov 17 06:46:22 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Fri, 16 Nov 2018 13:46:22 -0700 Subject: [COFF] [TUHS] man-page style In-Reply-To: <20181116192941.DFB6218C073@mercury.lcs.mit.edu> References: <20181116192941.DFB6218C073@mercury.lcs.mit.edu> Message-ID: <590e188f-092b-afd6-ff0a-4b6db8dc0f8d@spamtrap.tnetconsulting.net> On 11/16/2018 12:29 PM, Noel Chiappa wrote: > _That_ is what made me such a huge fan of Unix, even though as an > operating system person, I was, and remain, a big fan of Multics (maybe > the only person in the world who really likes both :-), which I still > think was a better long-term path for OSes (long discussion of why elided > to keep this short). Can I ask for the longer discussion? It sounds like an enlightening sidebar that would be good to have over a cup of COFFee. Maybe the barista on the COFF mailing list will brew you a cup to discuss this there. ~wink~wink~nudge~nudge~ -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3982 bytes Desc: S/MIME Cryptographic Signature URL: From dave at horsfall.org Sat Nov 17 07:44:51 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Nov 2018 08:44:51 +1100 (EST) Subject: [COFF] Happy birthday, computer mouse! Message-ID: On this day in 1970 computer pioneer Douglas Engelbart was awarded the patent for the computer mouse. It was a fugly thing: just a squarish box with two wheels underneath it mounted at right-angles and a button. Ergonomic it wasn't... -- Dave From dave at horsfall.org Sat Nov 17 07:49:23 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Nov 2018 08:49:23 +1100 (EST) Subject: [COFF] VMS epoch Message-ID: For some reason, I have in my calendar for today: VMS Epoch http://h41379.www4.hpe.com/wizard/wiz_2315.html Epoch of the Smithsonian Astrophysical Observatory, and is Julian Day 2400000 (to allow date to fit into a 36-bit word on the IBM 704). When I visited that page, NoScript went bersek... -- Dave From cym224 at gmail.com Sat Nov 17 08:05:22 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 16 Nov 2018 17:05:22 -0500 Subject: [COFF] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: On 16/11/2018, Dave Horsfall wrote: > On this day in 1970 computer pioneer Douglas Engelbart was awarded the > patent for the computer mouse. Not really meaning to argue but http://www.dougengelbart.org/content/view/90/48/ claims: "Doug Engelbart's patent on the computer mouse, titled X-Y position indicator for a display system (3,541,541), filed June 21, 1967 and granted January 17, 1970 [...]". Link to the USPTO: http://pdfpiw.uspto.gov/.piw?PageNum=0&docid=03541541 > It was a fugly thing: just a squarish box with two wheels underneath it mounted > at right-angles and a button. Ergonomic it wasn't... Allegedly hand-carved but who carved it? N. > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From dave at horsfall.org Sat Nov 17 08:22:33 2018 From: dave at horsfall.org (Dave Horsfall) Date: Sat, 17 Nov 2018 09:22:33 +1100 (EST) Subject: [COFF] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: On Fri, 16 Nov 2018, Nemo wrote: >> On this day in 1970 computer pioneer Douglas Engelbart was awarded the >> patent for the computer mouse. > > Not really meaning to argue but Don't worry; I love receiving corrections. > http://www.dougengelbart.org/content/view/90/48/ claims: "Doug > Engelbart's patent on the computer mouse, titled X-Y position indicator > for a display system (3,541,541), filed June 21, 1967 and granted > January 17, 1970 [...]". Link to the USPTO: > http://pdfpiw.uspto.gov/.piw?PageNum=0&docid=03541541 Hmmm... Right date, but wrong month; thanks. Not sure how that happened, but now corrected. -- Dave From cym224 at gmail.com Sat Nov 17 11:45:07 2018 From: cym224 at gmail.com (Nemo) Date: Fri, 16 Nov 2018 20:45:07 -0500 Subject: [COFF] Happy birthday, computer mouse! In-Reply-To: References: Message-ID: Oh, dear. On 16/11/2018, Dave Horsfall wrote: > On Fri, 16 Nov 2018, Nemo wrote: > >>> On this day in 1970 computer pioneer Douglas Engelbart was awarded the >>> patent for the computer mouse. >> >> Not really meaning to argue but > > Don't worry; I love receiving corrections. > >> http://www.dougengelbart.org/content/view/90/48/ claims: "Doug >> Engelbart's patent on the computer mouse, titled X-Y position indicator >> for a display system (3,541,541), filed June 21, 1967 and granted >> January 17, 1970 [...]". Link to the USPTO: >> http://pdfpiw.uspto.gov/.piw?PageNum=0&docid=03541541 > > Hmmm... Right date, but wrong month; thanks. Not sure how that happened, > but now corrected. Apologies, Dave, my implicit joke fell flat. Their website is wrong; you are correct (as seen on the tombstone of the actual patent). N. > > -- Dave > _______________________________________________ > COFF mailing list > COFF at minnie.tuhs.org > https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff From jnc at mercury.lcs.mit.edu Sun Nov 18 06:09:08 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Sat, 17 Nov 2018 15:09:08 -0500 (EST) Subject: [COFF] [TUHS] man-page style Message-ID: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> > From: Grant Taylor >> as an operating system person, I was, and remain, a big fan of Multics >> ... which I still think was a better long-term path for OSes (long >> discussion of why elided to keep this short). > Can I ask for the longer discussion? Sure. (Note that I'm not on COFF, so if anyone replies, please make sure I'm CC'd directly.) Basically, it boils down to 'monolithic OS's are bad' - for all the reasons laid out in the usual ukernel places (I first saw them in the BSTJ MERT paper, IIRC). {What follows is not the crispest way to explain it; sorry. I didn't feel like deleting it all and re-writing to get straight to the point, which is 'Multics had many of the advantages of a ukernel - and a long time before the ukernel idea arrived - but without the IPC overhead, which seems to be the biggest argument against ukernels'.} Now, early UNIX may have done pretty well in a _tiny_ amount of memory (I think our -11/40 V6 had about 64KB of main memory _total_, or some such ridiculous number), and to do that, maybe you have to go monolithic, but monolithic is pretty Procrustean. This was brought home to me in doing early TCP/IP work on PDP-11 Unix. The system was just not well suited to networking work - if what you wanted to do didn't fit into the UNIX model, you were screwed. Some people (e.g. BBN) did TCP as a process (after adding IPC; no IPC in UNIX, back then), but then you're talking a couple of process switches to do anything. I looked at how Dave Clark was doing it on Multics, and I was green with envy. He added, debugged and improved his code _on the running main campus system_, sharing the machine with dozens of real users! Try doing that on UNIX (although nowadays it's getting there, with loadable kernel stuff - but this was in the 70's)! 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. Noel From gtaylor at tnetconsulting.net Sun Nov 18 15:33:04 2018 From: gtaylor at tnetconsulting.net (Grant Taylor) Date: Sat, 17 Nov 2018 22:33:04 -0700 Subject: [COFF] [TUHS] man-page style In-Reply-To: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> References: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> Message-ID: On 11/17/2018 01:09 PM, Noel Chiappa wrote: > Sure. (Note that I'm not on COFF, so if anyone replies, please make sure > I'm CC'd directly.) Thank you for the reply Noel. I found this to be an interesting read. I occasionally bump into some Multicians and am always pleasantly surprised at how different their world is. > 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. If you're ever feeling bored and would like to share that story. ():-) Thank you again for typing the message and sending it to a mailing list that you're not subscribed to. If we're ever in a pub together, I owe you a round. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4008 bytes Desc: S/MIME Cryptographic Signature URL: From bakul at bitblocks.com Sun Nov 18 16:28:00 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Sat, 17 Nov 2018 22:28:00 -0800 Subject: [COFF] [TUHS] man-page style In-Reply-To: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> References: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> Message-ID: 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 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. From tytso at mit.edu Mon Nov 19 07:24:02 2018 From: tytso at mit.edu (Theodore Y. Ts'o) Date: Sun, 18 Nov 2018 16:24:02 -0500 Subject: [COFF] [TUHS] man-page style In-Reply-To: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> References: <20181117200908.2FAF918C073@mercury.lcs.mit.edu> Message-ID: <20181118212402.GD32299@thunk.org> On Sat, Nov 17, 2018 at 03:09:08PM -0500, Noel Chiappa wrote: > > I looked at how Dave Clark was doing it on Multics, and I was green with envy. > He added, debugged and improved his code _on the running main campus system_, > sharing the machine with dozens of real users! Try doing that on UNIX > (although nowadays it's getting there, with loadable kernel stuff - but this > was in the 70's)! One of the things that made Multics amazing is that you could replace a shared library while other processes was using it --- and without anything crashing. To achieve this, there is a tag field which identifies the object type and its length. So if a library defines an expanded version of the data structure, the new fields are tacked onto the end of the data structure and the length field is bumped. Older callers of the library might pass in a version of the data structure with the original length field; hence, fields can't be accessed unless without first checking the structure tag. I stole this idea and used in Kerberos v5 and Linux's userspace ext2/3/4 utilities, where we use a error table code --- another Multics concept --- as the structure tag. So in the error_table file, we might have: ec EXT2_ET_MAGIC_BADBLOCKS_ITERATE, "Wrong magic number for badblocks_iterate structure" And that in each function that uses that structure, there'd be something like this: EXT2_CHECK_MAGIC(iter, EXT2_ET_MAGIC_BADBLOCKS_ITERATE); Where EXT2_CHECK_MAGIC is defined as: #define EXT2_CHECK_MAGIC(struct, code) \ if ((struct)->magic != (code)) return (code) (All MIT KerberosV5 and libext2fs structures have a 32-bit unsigned magic field as the first 4 bytes of the structure.) This technique is also useful so when I needed to add support for 64-bit block numbers, I could use the structure magic numbers to disambiguate which version of the object we were using. Hence unlike some shared libraries where the magic number has been incremented to indicate an ABI break every few months, e2fsprogs has not had an ABI break in over ten years. This also made it a bit easier to find use-after-free bugs in an era before valgrid/purify, by the simple expedient of zeroing the magic field when deallocating an object. > 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. So that's a bit misleading. Setuid isn't really a good analogue for protection rings. The proper analogue for user mode versus kernel mode in the Unix world. (Where user mode is roughly speaking, Multics ring 4, and Kernel mode is Multics ring 0 --- the Honeywell hardware had support for 8 rings, but processes running below ring 4 have so little access that using them isn't terribly practical for general purpose programs. Processes ringing at rings 5 and higher wouldn't have access to most of what we in the Unix world would call "the standard POSIX system calls".) Code running in one ring can transition to higher rings via "gates", which would be the Unix equivalent of a system call. Hence, a Multics program running at Ring 4 could create its own gates that would provide an extremeted limited set of system services to programs running at Ring 5. Those programs wouldn't have access to the normal system calls, but only via the specified functions in the Ring 4 gates. This is sort of like Capsicum, but it's more powerful --- and it was designed decades before FreeBSD's Capsicum. > 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. Well, when you call a system call, you don't do a process switch either. So when Ring 4 code calls a ring 0 service, you chan think of it as a system call. It might not have been any slower than a normal function call, but remember, this is a CISC system. So another way of saying things is that normal function calls weren't any faster than a privilege transition via a system call! > 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. One unfortunate thing about the 386 VM is that a segment plus offset gets translated to a 32-bit global virtual address, which is then translated to a physical address via a single page table. With Multics, each segment had its own page table which translated the segment+offset to a physical address. With only 32-bits of virtual address space on the 386, it's not at all clear aggressive use of segments ala Multics would have worked terribly well, due to the internal fragmentation of that 32-bit address space. So I've talked to some Multicians at MIT who might quibble with the claim that 386's deisgn was "done correctly". In any case, since no one really used segments on 32-bit x86, segment support ended up getting mostly dropped in 64-bit mode. (The FS and GS segments still kinda work, mostly to keep Windows happy. The CS, DS, ES, and SS segments are basically no-ops in the 64-bit x86 world.) Which is too bad. I suspect that with a 64-bit address space, designing an OS with a Multics-style segmentation architecture might have been possible. (But see Rob Pike's "Systems Software Research is Irrelevant" rant for the argument that even if was *possible* it was very unlikely to have happened, so for AMD and Intel to have neutered segmentation in the x86-64 architecture might have been a well justified decision.) Cheers, - Ted From bakul at bitblocks.com Tue Nov 20 05:48:46 2018 From: bakul at bitblocks.com (Bakul Shah) Date: Mon, 19 Nov 2018 11:48:46 -0800 Subject: [COFF] [TUHS] man-page style In-Reply-To: Your message of "Mon, 19 Nov 2018 12:53:31 -0500." <20181119175331.A0A9A18C076@mercury.lcs.mit.edu> References: <20181119175331.A0A9A18C076@mercury.lcs.mit.edu> Message-ID: <20181119194853.657EE156E40C@mail.bitblocks.com> On Mon, 19 Nov 2018 12:53:31 -0500 jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote: > > > All of this would be easily possible on the Mill arch. if ever it gets > > built. Mill has segments and protected function calls. > > What I found about that mostly talked about the belt stuff. Do you happen to > have a pointer to the segment/call stuff? This is a good talk re IPC and protection: https://www.youtube.com/watch?v=XJasE5aOHSw In the desciption below the video there is a list of times where various topics are covered so you can jump to what you want. Slides here: https://millcomputing.com/docs/inter-process-communication/ Ivan's talk on Security should also be of help: https://www.youtube.com/watch?v=5osiYZV8n3U https://millcomputing.com/docs/security/ The key implication is a thread can make a "portal" call, where the same thread is now in a different protection domain. No need for rendezvous & a couple of extra context switches to a different thread, or trampoline through a higher privilege kernel. This callee function can only access what is visible from its own protection domain. It can operate on caller's memory data ony if the caller provides one time access to it. > > set-uid has its own issues. Plan9 doesn't have it. > > Ah, what were the issues (if you happen to know)? The issue is setuid(uid,gid) process has *full* access* available to uid,gid. If uid==0, now the process has superuser access. Why should an install program have access to /etc/passwd or have raw disk access or be able to root around in kernel memory? Typically you only want to provide very limited access. From jnc at mercury.lcs.mit.edu Tue Nov 20 03:53:31 2018 From: jnc at mercury.lcs.mit.edu (Noel Chiappa) Date: Mon, 19 Nov 2018 12:53:31 -0500 (EST) Subject: [COFF] [TUHS] man-page style Message-ID: <20181119175331.A0A9A18C076@mercury.lcs.mit.edu> > From: Grant Taylor > Thank you for the reply Sure; I love to yap about stuff like this. > I occasionally bump into some Multicians and am always pleasantly > surprised at how different their world is. Yes, it's very unlike most of what's been done since. Some of it (e.g. a strictly ordered set of rings for protection) was wrong, but there's a lot of good stuff there yet to be mined. >> Which is a pity, because when done correctly (which it was - Intel >> hired Paul Karger to architect it) Ooops, it was Roger Schell, I get them mixed up all the time. His oral history, here: https://conservancy.umn.edu/handle/11299/133439 is a Must Read. >> it's just what you > need for a truly secure system (which Multics also >> had) - but that's another long message. > If you're ever feeling bored and would like to share that story. OK, soon. > From: Bakul Shah > All of this would be easily possible on the Mill arch. if ever it gets > built. Mill has segments and protected function calls. What I found about that mostly talked about the belt stuff. Do you happen to have a pointer to the segment/call stuff? > set-uid has its own issues. Plan9 doesn't have it. Ah, what were the issues (if you happen to know)? Noel From dave at horsfall.org Wed Nov 21 06:17:34 2018 From: dave at horsfall.org (Dave Horsfall) Date: Wed, 21 Nov 2018 07:17:34 +1100 (EST) Subject: [COFF] First permanent ARPAnet link Message-ID: (I decided it was more suitable for COFF instead of TUHS (but sadly the membership does not overlap much.) https://en.wikipedia.org/wiki/Leonard_Kleinrock#ARPANET ``The first permanent ARPANET link was established on November 21, 1969, between the IMP at UCLA and the IMP at the Stanford Research Institute.'' And thus from little acorns... -- Dave From dave at horsfall.org Mon Nov 26 08:08:47 2018 From: dave at horsfall.org (Dave Horsfall) Date: Mon, 26 Nov 2018 09:08:47 +1100 (EST) Subject: [COFF] EDSAC replica switched on Message-ID: A replica of EDSAC, the Electronic Delay Storage Automatic Calculator, was switched on at Bletchley Park on this day in 2014; EDSAC was the first practical general purpose stored program electronic computer (and how's that for hair-splitting?). -- Dave From dave at horsfall.org Tue Nov 27 07:01:03 2018 From: dave at horsfall.org (Dave Horsfall) Date: Tue, 27 Nov 2018 08:01:03 +1100 (EST) Subject: [COFF] In memoriam: Ada Lovelace Message-ID: Augusta Ada King-Noel, Countess of Lovelace, was lost to us in 1852 from uterine cancer. Regarded as the first computer programmer and a mathematical prodigy (when such things were unseemly for a mere woman), she was the daughter of Lord Byron, and a friend of Charles Babbage. -- Dave From dave at horsfall.org Thu Nov 29 17:46:45 2018 From: dave at horsfall.org (Dave Horsfall) Date: Thu, 29 Nov 2018 18:46:45 +1100 (EST) Subject: [COFF] In memoriam: Maurice Wilkes Message-ID: Almost forgot... We lost Sir Maurice Wilkes FRS FREng on this day in 2010; he was known for his work on EDSAC, microprogramming, etc. -- Dave