Far and near pointers on the 80286 and later
|
Prev: The 6809 and 680xx instruction sets
Next: DANGER DANGER THIRD DAY CPU FAN FAILURE DANGER DANGER
From: jmfbahciv on 30 Mar 2010 08:44 George Neuner wrote: > On Sun, 28 Mar 2010 08:16:02 -0500, jmfbahciv <jmfbahciv(a)aol> wrote: > >> George Neuner wrote: >> >>> Leaving aside why anyone would _want_ to bring back Multics ... >> To study how to make an OS secure from the beginning project plan >> to the last edit for shipping? > > Ok, but there are other secure systems to study such as Amoeba and > EROS. They are more modern than Multics, and in particular, were > designed to be distributed. > > I don't mind anyone studying Multic - there is plenty to learn from it > (including what not to do) ... but I would be against trying to revive > it as a working operating system. > There is nothing, I repeat NOTHING, more instructive than working on a functional system. It's a computer biz law that, what you expect to happen, will not happen; the corollary is that the opposite of what you expect to happen will happen. Only those who have done OS development for many releases will understand this one. ARe you really sure that MULTICs doesn't have old tricks which have to be relearned and reimplemented again? I'm not. I'm sure of the opposite. /BAH
From: Anne & Lynn Wheeler on 30 Mar 2010 10:13 George Neuner <gneuner2(a)comcast.net> writes: > Ok, but there are other secure systems to study such as Amoeba and > EROS. They are more modern than Multics, and in particular, were > designed to be distributed. > > I don't mind anyone studying Multic - there is plenty to learn from it > (including what not to do) ... but I would be against trying to revive > it as a working operating system. as an aside ... some of the ctss people went to 5th flr, 545 tech sq to do multics and others went to the science center on the 4th flr and did (virtual machine) cp40 (on special modified 360/40 with virtual memory hardware) which morphed into cp67 (when standard virtual memory 360/67 became available) and then morphed into vm370. http://www.garlic.com/~lynn/subtopic.html#545tech Old reference to Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#44 Thirty Years Later: Lessons from the Multics Security Evaluation http://www.garlic.com/~lynn/2002l.html#45 Thirty Years Later: Lessons from the Multics Security Evaluation multics page http://www.multicians.org/multics.html old post in multics news group (AFDS was Multics installation) http://www.garlic.com/~lynn/2001m.html#12 Multics Nostalgia with respect to cp67 ... there seemed to have been a lot of these guys .... but I didn't become aware of them until much later: http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml I did assurance panel discussion at 2001 IDF in tcpa track ... http://web.archive.org/web/20011109072807/http://www.intel94.com/idf/spr2001/sessiondescription.asp?id=stp+s13 with their technical director http://web.archive.org/web/20011106111653/www.intel94.com/idf/spr2001/speakerdescriptions.asp?id=bsnow Coyotos is successor to EROS ... EROS was based on tymshare's (370) gnosis capability operating system ... which was spun off as keykos when m/d bought tymshare (I was brought in to do gnosis audit/review as part of the spin-off). http://en.wikipedia.org/wiki/Coyotos There were also some number of "object" operating system efforts .... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink technology went to Taligent ... and (possibly) some of SPRING/DOE shows up in java (and java virtual machine) Recent reference about being asked about coming in to head up commercialization of SPRING/DOE for shipping as product http://www.garlic.com/~lynn/2010f.html#47 Nonlinear systems and nonlocal supercomputing misc. past posts mentioning gnosis, keykos, eros, coyotos http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs) http://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious http://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc. http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s? http://www.garlic.com/~lynn/2001n.html#10 TSS/360 http://www.garlic.com/~lynn/2002f.html#59 Blade architectures http://www.garlic.com/~lynn/2002g.html#0 Blade architectures http://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer) http://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv? http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it? http://www.garlic.com/~lynn/2002j.html#75 30th b'day http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation http://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks http://www.garlic.com/~lynn/2003i.html#15 two pi, four phase, 370 clone http://www.garlic.com/~lynn/2003j.html#20 A Dark Day http://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage http://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts http://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts http://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts http://www.garlic.com/~lynn/2003m.html#24 Intel iAPX 432 http://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing? http://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security http://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security http://www.garlic.com/~lynn/2004m.html#29 Shipwrecks http://www.garlic.com/~lynn/2004m.html#49 EAL5 http://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue http://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"? http://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005b.html#7 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005b.html#12 [Lit.] Buffer overruns http://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general http://www.garlic.com/~lynn/2005d.html#43 Secure design http://www.garlic.com/~lynn/2005d.html#50 Secure design http://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new? http://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities http://www.garlic.com/~lynn/2005s.html#12 Flat Query http://www.garlic.com/~lynn/2006k.html#37 PDP-1 http://www.garlic.com/~lynn/2006m.html#34 PDP-1 http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS? http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006w.html#42 vmshare http://www.garlic.com/~lynn/2006y.html#11 Multiple mappings http://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style" http://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work http://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript http://www.garlic.com/~lynn/2008b.html#24 folklore indeed http://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child? http://www.garlic.com/~lynn/2008e.html#12 Kernels http://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff http://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos" http://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels (Re: Kernels http://www.garlic.com/~lynn/2008s.html#3 New machine code http://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs http://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers http://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure -- 42yrs virtualization experience (since Jan68), online at home since Mar1970
From: nmm1 on 30 Mar 2010 10:19 In article <hosqpu41t4u(a)news7.newsguy.com>, jmfbahciv <jmfbahciv(a)aol> wrote: >> >There is nothing, I repeat NOTHING, more instructive than working >on a functional system. It's a computer biz law that, what you >expect to happen, will not happen; the corollary is that the >opposite of what you expect to happen will happen. Only >those who have done OS development for many releases will >understand this one. Not at all. I have never done that, but I have done such things as implement fully-functional language run-time systems (including exception handling, non-trivial I/O and associated recovery). I am VERY familiar with that principle, and it holds true even after 40+ years experience .... >ARe you really sure that MULTICs doesn't have old tricks >which have to be relearned and reimplemented again? I'm >not. I'm sure of the opposite. I don't object to people reinventing the wheel, but I do wish they would get the number of sides right! That is especially true as people attempt to use Unix derivatives (including Microsoft ones, of course) for servers. Mainframes had lots of defects, but avoided many of the current ones. Regards, Nick Maclaren.
From: George Neuner on 30 Mar 2010 14:19 On Tue, 30 Mar 2010 10:13:07 -0400, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > >George Neuner <gneuner2(a)comcast.net> writes: >> Ok, but there are other secure systems to study such as Amoeba and >> EROS. They are more modern than Multics, and in particular, were >> designed to be distributed. >> >> I don't mind anyone studying Multic - there is plenty to learn from it >> (including what not to do) ... but I would be against trying to revive >> it as a working operating system. > >as an aside ... some of the ctss people went to 5th flr, 545 tech sq to >do multics and others went to the science center on the 4th flr and did >(virtual machine) cp40 (on special modified 360/40 with virtual memory >hardware) which morphed into cp67 (when standard virtual memory 360/67 >became available) and then morphed into vm370. >http://www.garlic.com/~lynn/subtopic.html#545tech Yup. Multics did a lot of things first and got quite a bit of it right. Internally, at least, Multics was quite nice. However, the security API was not fun to work with and the user experience could be unpleasant at times. I personally did not use Multics extensively, but I know people who did and many of them disliked it - as I did. Of course, I also disliked using VMS ... so I'm probably going to be cast out 8) I quite enjoyed programming VAXen, but I was much happier using Unix than VMS. >Coyotos is successor to EROS ... EROS was based on tymshare's (370) >gnosis capability operating system ... which was spun off as keykos when >m/d bought tymshare (I was brought in to do gnosis audit/review as part >of the spin-off). >http://en.wikipedia.org/wiki/Coyotos Coyotos seems still to be a research project. CapROS, though is a commercial spin off of EROS. http://www.capros.org/ >There were also some number of "object" operating system efforts >... like Apple's Pink and Sun's SPRING/DOE ... some of Apple's Pink >technology went to Taligent ... and (possibly) some of SPRING/DOE shows >up in java (and java virtual machine) Pink wasn't designed with security in mind (Apple was still thinking single user) and it never really materialized anyway. Taligent's OS was more focused on being reliable than being secure. EROS (and follow-ons) and Amoeba were designed from the ground up as capability based secure operating systems. George
From: Anne & Lynn Wheeler on 30 Mar 2010 14:28
George Neuner <gneuner2(a)comcast.net> writes: > Pink wasn't designed with security in mind (Apple was still thinking > single user) and it never really materialized anyway. Taligent's OS > was more focused on being reliable than being secure. re: http://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later I did a one week JAD with taligent (there were dozen or so top taligent people in the session and their JAD person) going over what would be required for business critical (both reliable and secure). the net was approx. 30% hit to the taligent base ... two new frameworks plus hits to the existing frameworks. However, I believe the taligent security guru was on business trip that week ... visiting some gov. agency on the east coast. misc. past posts referencing the taligent JAD: http://www.garlic.com/~lynn/2000e.html#46 Where are they now : Taligent and Pink http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow http://www.garlic.com/~lynn/2004p.html#64 Systems software versus applications software definitions http://www.garlic.com/~lynn/2005i.html#42 Development as Configuration http://www.garlic.com/~lynn/2007m.html#36 Future of System/360 architecture? http://www.garlic.com/~lynn/2008b.html#22 folklore indeed http://www.garlic.com/~lynn/2009m.html#26 comp.arch has made itself a sitting duck for spam -- 42yrs virtualization experience (since Jan68), online at home since Mar1970 |