From touch at ISI.EDU Sun Jul 22 10:40:26 2001 From: touch at ISI.EDU (Joe Touch) Date: Sun, 22 Jul 2001 10:40:26 -0700 Subject: [ih] testing.... Message-ID: <3B5B100A.24F2BF9D@isi.edu> This is a test. Joe From rms46 at vlsm.org Mon Jul 23 21:30:13 2001 From: rms46 at vlsm.org (Rahmat M. Samik-Ibrahim) Date: Tue, 24 Jul 2001 11:30:13 +0700 Subject: [ih] Usenet History Message-ID: <3B5CF9D5.8396DBDD@vlsm.org> FYI, there is a Usenet.History archive at http://communication.ucsd.edu/bjones/Usenet.Hist/Nethist/ regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Nimbus 2000: Now on SALE at our platform 9 3/4 outlet -- From braden at ISI.EDU Tue Jul 24 20:13:47 2001 From: braden at ISI.EDU (Bob Braden) Date: Tue, 24 Jul 2001 20:13:47 -0700 (PDT) Subject: [ih] Question on UCSB OLS Message-ID: <200107250313.f6P3Dla19535@boreas.isi.edu> Hi, If you don't grok the title of this message, never mind. This is in hopes that there is someone on this list with at least a minimal memory of the UCSB OLS ("Culler Fried" system). My question is this. I am proofing an early RFC about the OLS. It includes the symbolism "(+)", as in the key push sequence "USER LI (+)". In another place, it shows "USER LI DISPLAY <+>", where <+> is actually shown as a plus inside a circle. Are these alternative representations for the same button, or is "circle +" different from "(+)"? I could dig into other early OLS documentation and figure this out, but it would be nice if someone knew off the bat. Thanks, Bob Braden From dragon at cs.utexas.edu Fri Jul 27 08:18:40 2001 From: dragon at cs.utexas.edu (Chris Edmondson-Yurkanan) Date: Fri, 27 Jul 2001 10:18:40 -0500 Subject: [ih] conf on history of ... networks Message-ID: <200107271518.KAA23358@neverland.cs.utexas.edu> I'll bet that none of us expected the 4th email to this mailing list to be about another conference!!! I don't know anything more about this particular conference, besides that they are encouraging meetings and discussions between historians and the scientists/engineers. (Braden/Partridge/Chapin/myself and others have casually discussed over the last year putting on our own workshop version but have not acted on it. So, here's the conference announcement that I just received. Chris Edmondson-Yurkanan # #International Conference on the History of Computing and Networks # #Grenoble, FRANCE 2002 # #Call for Papers # # #ACONIT (Association for a Conservatory of Information Technology), #AHTTI (Association of History of Telecommunications and Information #Technology) and CHARME (Committee for the History of ARMEments), in #collaboration with IMAG (Institute of Applied Mathematics in #Grenoble), are organising an international conference on the History #of Computing and Networks for autumn 2002. # #This conference provides an opportunity for meetings and discussions #between historians who are studying, and the scientists and engineers #who participated in the development of computing and networks. The #following subject themes are given as examples of what might be #discussed: # #Preservation and Exhibition of Computing and Telecommunication #heritage # #Developments of the concepts of teaching and researching in #computing. # #The role of the military in the development of computing # #Automation and robotics # #Computing in medicine # #The impact of computer networks on software systems # #The evolution of standards # #The convergence of computing and telecommunications # # #This conference is the latest the series of Computer History #Conferences held in France in 1988 in Grenoble, 1990 in Paris, 1993 in #Sophia-Antipolis, 1995 in Rennes and 1998 in Toulouse. An exhibition #tracing the history of computing and networks will complement the #conference. # #Papers should present information of historical interest and proposals #of up to two pages will be accepted until 15 January 2002. Proposals #can be emailed in electronic form in either ASCII text or RTF format #to colloque2002 at aconit.org , or mailed in paper form to : # #ACONIT /Colloque 2002 #10 bis rue Ampere #BP 267 #38016 Grenoble Cedex #France # #Submissions will be examined by the program committee. # #Requests for support of the conference are being made from public and #private organisations and companies and from the European Union. # #Full details can be found on the conference web site at #http://www.aconit.org/colloque2002 # -- Chris Edmondson-Yurkanan I'm going to have a "YEAR of the dragon"+1 Computer Sciences, TAY2.124(C0500) My email addresses are: chris at cs.utexas.edu The University of Texas at Austin or dragon at cs.utexas.edu Austin, TX 78712-1188 URL: www.cs.utexas.edu/users/dragon/ +1 512 471 9546 fax: (471 8885) Office: TAY 4.136 (pls fedex to TAY 2.124) From braden at ISI.EDU Fri Jul 27 12:08:46 2001 From: braden at ISI.EDU (Bob Braden) Date: Fri, 27 Jul 2001 19:08:46 GMT Subject: [ih] Re: IPv4 vs MAC Message-ID: <200107271908.TAA28853@gra.isi.edu> ----- Begin Included Message ----- >From owner-ietf-outbound at ietf.org Fri Jul 27 11:35:04 2001 Date: Fri, 27 Jul 2001 11:29:04 -0700 From: Steve Feldman To: Robert Elz Cc: ietf at ietf.org Subject: Re: IPv4 vs MAC Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Loop: ietf at ietf.org On Fri, Jul 27, 2001 at 03:40:53PM +0700, Robert Elz wrote: > Does no-one else still recall the world before ARP, where MAC addresses > (ie: the old 16 bit things that 3Mbit ethernet used) were embedded in the > bottom 16 bits of your class B address (no-one had anything smaller than > that of course...) Oh my, I remember writing drivers for those beasts back in my UC Berkeley days. (We had a class A!) And wondering how to deal with those new-fangled 48 bit MAC adddresses in 10 Megabit Ethernet. I think I started off just taking the low 16 bits, which worked fine when there were only 100 or so Ethernet interfaces in existence. (The first ARP RFC didn't come out until after I graduated.) As I recall, Xerox's XNS protocol used the entire MAC address as the protocol address, which made translation easy but routing difficult. I feel old... Steve ----- End Included Message ----- From frana003 at tc.umn.edu Fri Jul 27 13:55:21 2001 From: frana003 at tc.umn.edu (Philip Frana) Date: Fri, 27 Jul 2001 15:55:21 -0500 Subject: [ih] CFP: Iterations: An Interdisciplinary Journal of Software History Message-ID: <3.0.5.32.20010727155521.0081fdc0@frana003.email.umn.edu> Call for Papers: ITERATIONS Iterations: An Interdisciplinary Journal of Software History, a new peer-reviewed electronic journal published by the Charles Babbage Institute, is now seeking article submissions. Iterations provides an outlet for scholarly articles on software history, a forum for first hand accounts of significant events and developments in software, reviews, and feedback from readers and authors. Analyses of software history that draw upon perspectives and methodologies from other disciplines are encouraged. Articles should be a minimum of 5,000 words. Inquiries and submissions should be sent electronically (MS Word attachment preferred) to cbi at tc.umn.edu Please consult www.cbi.umn.edu/iterations/faq for frequently asked questions about Iterations. Inquiries can also be made by contacting: Dr. Jeffrey R. Yost, Editor, or Dr. Philip L. Frana, Associate Editor and Reviews Editor at (612) 624-5050, sending email to cbi at tc.umn.edu or sending mail to: Iterations Charles Babbage Institute 211 Andersen Library University of Minnesota 222 21st Avenue South Minneapolis, MN 55455 Philip L. Frana, Ph.D. NSF Software History Project Manager Charles Babbage Institute Center for the History of Information Processing 211 Elmer L. Andersen Library 222 21st Avenue South University of Minnesota Minneapolis, MN 55455 ph. 612-624-5050 fax 612-625-8054 www.cbi.umn.edu frana003 at tc.umn.edu From rogers at ISI.EDU Sun Jul 29 16:39:08 2001 From: rogers at ISI.EDU (Craig Milo Rogers) Date: Sun, 29 Jul 2001 16:39:08 -0700 Subject: [ih] Re: IPv4 vs MAC In-Reply-To: Your message of "Fri, 27 Jul 2001 19:08:46 GMT." <200107271908.TAA28853@gra.isi.edu> Message-ID: <25099.996449948@ISI.EDU> >On Fri, Jul 27, 2001 at 03:40:53PM +0700, Robert Elz wrote: >> Does no-one else still recall the world before ARP, where MAC addresses >> (ie: the old 16 bit things that 3Mbit ethernet used) were embedded in the >> bottom 16 bits of your class B address (no-one had anything smaller than >> that of course...) The 3-Mbit Xerox PARC Ethernet packet format has 8-bit wide address fields, not 16-bit wide ones. At ISI, I connected our first 3-Mbit Ethernet to the ARPAnet via PDP-11 running the EPOS operating system. Our Ethernet addresses were mapped into IP network 10. Due to a pecularity of network 10 addressing (due, in turn, to a convention of the expanded IMP addressing scheme, if I recall correctly), our 3-Mbit Ethernet addresses actually mapped into the third octet of the IP Net 10 address, rather than the 4th octet. However, this mapping was transparent to other Net 10 hosts, so the ISI gateway didn't have to participate in IP-level routing protocols (which considerably simplified its construction and maintenance). We installed a second ARPAnet-to-Ethernet gateway at DARPA. The primary purpose of the gateways was to provide Internet access to the Xerox "Penguin" laser printer that had replaced the XGP (Xerox Graphic Printer) printer at each site. The printers used a Xerox Alto as a front-end to the actual print engine, which was a highly modified Xerox copier. Our gateways performed an application-level transformation between the Internet TFTP protocol and the Xerox EFTP protocol; the two protocols were very similar, and the transformation was nearly stateless. Dave Mill's "fuzzball" system provided similar Internet-to-3Mbit-Ethernet gateway services, as well as a variety of other utility services, and ran on less expensive PDP-11 configurations than EPOS. For a while, there were quite a few of them installed around the Internet. Craig Milo Rogers From rms46 at vlsm.org Mon Jul 30 19:15:54 2001 From: rms46 at vlsm.org (Rahmat M. Samik-Ibrahim) Date: Tue, 31 Jul 2001 09:15:54 +0700 Subject: [ih] OOT: What is a stack? Message-ID: <3B6614DA.E29DF675@vlsm.org> Hello: I have no idea where to follow up this issue; hopefully this list is the best fit. James P. Salsman wrote on the IETF list: > Speaking of prevention measures, is there anything in > i386 architecture which can prevetn execution of code > on the stack, or is that exclusive to SPARCitecture? I am not familiar with SPARC, cmiiw, it uses 32 multipurpose registers with a sliding window. Therefore, what is exactly "prevent execution of code on the stack" ? Speaking of stack history, how many processors that actually call one of its register as a "stack pointer"? Intel 8XXX, Zilog, what else? How about PDP-11, does R5 count as a stack pointer? How about HP-1000, where a return address was stored in the front of a subroutine (Jump save address)? regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Hi! How are you? I send you this in order to have advice From bovik at best.com Mon Jul 30 19:44:30 2001 From: bovik at best.com (James P. Salsman) Date: Mon, 30 Jul 2001 19:44:30 -0700 (PDT) Subject: [ih] Re: OOT: What is a stack? In-Reply-To: <3B6614DA.E29DF675@vlsm.org> Message-ID: <200107310244.TAA18030@shell9.ba.best.com> Rahmat, Thank you for your questions about stacks. Since the virtual memory management unit defines which segments are and are not executable, I think it is best to think of the stack as the memory which has been allocated to the MMU's "stack segment" instead of in terms of particular registers. It turns out that the i386 MMU does have provisions for nonexecutable segments, and such safeguards for the stack are implemented in certain patches to Linux. However, those patches break certain features of the GDB debugger, so they are not popular. Also, it is rumored that certain unix signaling packages push legitimate code on to the stack, but they are sloppy, because there is a miniscule efficiency advantage to doing so, and the pitfalls are very bad. (Every fixed-length buffer becomes a potential security exploit.) Maybe someone at Microsoft can tell us what happens to Windows when the stack segment is marked non-executable. Does anything break? At least the CodeRed worm would break, along with similar stack exploits. Cheers, James > Date: Tue, 31 Jul 2001 09:15:54 +0700 > From: "Rahmat M. Samik-Ibrahim" > To: MILIS Internet History > CC: "James P. Salsman" > Subject: OOT: What is a stack? > > Hello: > > I have no idea where to follow up this issue; hopefully this > list is the best fit. > > James P. Salsman wrote on the IETF list: > > > Speaking of prevention measures, is there anything in > > i386 architecture which can prevetn execution of code > > on the stack, or is that exclusive to SPARCitecture? > > I am not familiar with SPARC, cmiiw, it uses 32 multipurpose > registers with a sliding window. Therefore, what is exactly > "prevent execution of code on the stack" ? > > Speaking of stack history, how many processors that actually > call one of its register as a "stack pointer"? Intel 8XXX, > Zilog, what else? > > How about PDP-11, does R5 count as a stack pointer? > How about HP-1000, where a return address was stored > in the front of a subroutine (Jump save address)? > > regards, > > -- > Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org > - Hi! How are you? I send you this in order to have advice From touch at ISI.EDU Mon Jul 30 20:56:16 2001 From: touch at ISI.EDU (Joe Touch) Date: Mon, 30 Jul 2001 20:56:16 -0700 Subject: [ih] OOT: What is a stack? References: <3B6614DA.E29DF675@vlsm.org> Message-ID: <3B662C60.D2682693@isi.edu> "Rahmat M. Samik-Ibrahim" wrote: > > Hello: > > I have no idea where to follow up this issue; hopefully this > list is the best fit. Actually, not so much. The purpose of this list is to discuss issues of Internet history. These are decidedly not Internet issues. Please take the discussion to another list... Joe > > James P. Salsman wrote on the IETF list: > > > Speaking of prevention measures, is there anything in > > i386 architecture which can prevetn execution of code > > on the stack, or is that exclusive to SPARCitecture? > > I am not familiar with SPARC, cmiiw, it uses 32 multipurpose > registers with a sliding window. Therefore, what is exactly > "prevent execution of code on the stack" ? > > Speaking of stack history, how many processors that actually > call one of its register as a "stack pointer"? Intel 8XXX, > Zilog, what else? > > How about PDP-11, does R5 count as a stack pointer? > How about HP-1000, where a return address was stored > in the front of a subroutine (Jump save address)? > > regards, > > -- > Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org > - Hi! How are you? I send you this in order to have advice From dpreed at reed.com Tue Jul 31 11:57:44 2001 From: dpreed at reed.com (David P. Reed) Date: Tue, 31 Jul 2001 14:57:44 -0400 Subject: [ih] Re: OOT: What is a stack? In-Reply-To: <200107310244.TAA18030@shell9.ba.best.com> References: <3B6614DA.E29DF675@vlsm.org> Message-ID: <5.1.0.14.2.20010731145304.043f98a0@mail.reed.com> Small issue: Return addresses of calling routines are on the stack, and they don't require execute access to exploit. Thus, every fixed length buffer is indeed a potential exploit, whether or not you give "execute" permission to the stack. I sense a wish to "blame Microsoft" or "blame Intel" on this one. Blame the designers of "C" string handling routines, instead - or is Bell Labs Murray Hill exempt from criticism these days? Who wrote the first set of str* libraries in C, and forgot to require bounding of the target string, anyway? At 07:44 PM 7/30/01 -0700, James P. Salsman wrote: >Rahmat, > >Thank you for your questions about stacks. > >Since the virtual memory management unit defines which segments are and >are not executable, I think it is best to think of the stack as the >memory which has been allocated to the MMU's "stack segment" instead of >in terms of particular registers. > >It turns out that the i386 MMU does have provisions for nonexecutable >segments, and such safeguards for the stack are implemented in certain >patches to Linux. However, those patches break certain features of >the GDB debugger, so they are not popular. Also, it is rumored that >certain unix signaling packages push legitimate code on to the stack, >but they are sloppy, because there is a miniscule efficiency advantage >to doing so, and the pitfalls are very bad. (Every fixed-length buffer >becomes a potential security exploit.) > >Maybe someone at Microsoft can tell us what happens to Windows when >the stack segment is marked non-executable. Does anything break? At >least the CodeRed worm would break, along with similar stack exploits. > >Cheers, >James > > > Date: Tue, 31 Jul 2001 09:15:54 +0700 > > From: "Rahmat M. Samik-Ibrahim" > > To: MILIS Internet History > > CC: "James P. Salsman" > > Subject: OOT: What is a stack? > > > > Hello: > > > > I have no idea where to follow up this issue; hopefully this > > list is the best fit. > > > > James P. Salsman wrote on the IETF list: > > > > > Speaking of prevention measures, is there anything in > > > i386 architecture which can prevetn execution of code > > > on the stack, or is that exclusive to SPARCitecture? > > > > I am not familiar with SPARC, cmiiw, it uses 32 multipurpose > > registers with a sliding window. Therefore, what is exactly > > "prevent execution of code on the stack" ? > > > > Speaking of stack history, how many processors that actually > > call one of its register as a "stack pointer"? Intel 8XXX, > > Zilog, what else? > > > > How about PDP-11, does R5 count as a stack pointer? > > How about HP-1000, where a return address was stored > > in the front of a subroutine (Jump save address)? > > > > regards, > > > > -- > > Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org > > - Hi! How are you? I send you this in order to have advice From bovik at best.com Tue Jul 31 13:06:15 2001 From: bovik at best.com (James P. Salsman) Date: Tue, 31 Jul 2001 13:06:15 -0700 (PDT) Subject: [ih] Re: OOT: What is a stack? In-Reply-To: <5.1.0.14.2.20010731145304.043f98a0@mail.reed.com> Message-ID: <200107312006.NAA07313@shell9.ba.best.com> > Date: Tue, 31 Jul 2001 14:57:44 -0400 > From: "David P. Reed" > > Small issue: Return addresses of calling routines are on the stack, and > they don't require execute access to exploit. Thus, every fixed length > buffer is indeed a potential exploit, whether or not you give "execute" > permission to the stack. > > I sense a wish to "blame Microsoft" or "blame Intel" on this one. Blame > the designers of "C" string handling routines, instead On the contrary, branching to an arbitrary address is very rarely even a significant capability in comparison to an executable exploit. It might work in conjunction with a seperate exploit, but not by its self. Is there any question that the decsions of operating systems architects, as to whether they allow code execution from the stack, are having a significant impact on the history of the internet? There ought to be a Plumbing and Building Code for Internet-connected hosts. If your hardware forces you to have an executable stack, then you need better hardware. Cheers, James From rms46 at vlsm.org Tue Jul 31 16:46:58 2001 From: rms46 at vlsm.org (Rahmat M. Samik-Ibrahim) Date: Wed, 01 Aug 2001 06:46:58 +0700 Subject: [ih] The List: for historians or for history actors? References: <3B6614DA.E29DF675@vlsm.org> <3B662C60.D2682693@isi.edu> Message-ID: <3B674372.19B1D19A@vlsm.org> Joe Touch wrote: > The purpose of this list is to discuss issues of Internet > history. These are decidedly not Internet issues. Please > take the discussion to another list... Oh, I see. May I know who should participate: the historians or the history actors? Is there any intention to writing down the discussion result? In what format? .DOC (historians main tool) ? .nroff (history actors main tool)? regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org - Hi! How are you? I send you this in order to have advice