TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal >>> The report I have is: "SPIDER-a data communication experiment" >>> ... >>> I think it can be public now, but doing some checks. OK, that would be great to have online. I _think_ the hardcopy I have (somewhere! :-) is that report, but my memory should not be trusted. The people working on TCP/IP did know of the Spider work (like they knew of the Cambridge ring work), but it didn't really have any impact; it was a totally different direction than the one we were going in. >>> it turns out that the TIU driver was in Warren's repo all along: V4?! Wow. I'd have never guessed it went that far back. >>> The code calls snstat() >> The object code for snstat() is in libc.a in the dmr's V5 image. >> Reconstructed, the source code is here: >> ... >> In short, snstat() is a modified stty call Yes, I looked and found the original source, appended below. >>> Could that be the tiu sys call (#45) in the sysent.c table for V4-V6? I wonder if we'll ever be able to find a copy of the kernel code for that tiu() system call. And I wonder what it did? > [1] Oldest alarm() code I can find is in PWB1 > ... > Either alarm existed in V5 and V6 .. or is was added after V6 was > released, perhaps soon after. In the latter case the 'nfs' code that we > have must be later than 1974 Remember, that source came from the MIT system, which is a modified PWB1. So it's not surprising it's using PWB1 system calls. Noel -------- / C interface to spider status call .globl _snstat .globl cerror _snstat: mov r5,-(sp) mov sp,r5 mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 sys stty; 0f bec 1f jmp cerror 1: clr r0 mov (sp)+,r5 rts pc .data 0: .=.+6

8 years, 2 months

Early Unix Spider network / alarm()

by Paul Ruizendaal

Below what I've been able to find about alarm(): [1] Oldest alarm() code I can find is in PWB1, dated July 1977: http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/sys4.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=PWB1/sys/sys/os/clock.c Either alarm existed in V5 and V6, and was removed from distributions (which seems unlikely to me), or is was added after V6 was released, perhaps soon after. In the latter case the 'nfs' code that we have must be later than 1974 (even though the man page is dated that way). It could be from the 2nd half of 1975. [2] Interestingly, the idea to implement sleep() in terms of alarm() seems to originate in UoI network unix: http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/sys2.c -- sslep() This occurs in Oct 1977. In V7 this idea is taken to user space and sleep() is no longer a system call. [3] The UoI code has an instance of alarm() being used to break out of a potentially stalled network call, so that usage seems to have established itself early on.

8 years, 2 months

Early Unix Spider network

by Paul Ruizendaal

Progressed a little further: [1] The 'ufs' command was a variation on the 'nfs' command. The man page that Noel provided for nfs includes the paragraph: "There is a command /usr/usg/tom/ufs which transfers files to the USG Unix systems. The option letter 7 for the 11/70 or 4 for the 11/45 should be used. Otherwise 'ufs' is similar to 'nfs'." This means there must have been a Unix based File Store (server). Does anybody have a suggestion who 'tom' at USG might have been? [2] The V5 man pages in the archive have a man page for 'npr', in section VI. It says: NAME npr - print file on Spider line-printer SYNOPSIS npr file … DESCRIPTION Npr prints files on the line, printer in the Spider room, sending them over the Spider loop. If there are no arguments, the standard input is read and submitted. Thus npr may be used as a filter. FILES /dev/tiu/d2 tiu to loop It suggests that the printer was hooked up to the Spider switch and that channel 2 was hardcoded to it. [3] Upon closer inspection, the tiu.c driver is a character mode device, the use of disk buffers and a strategy() routine had me confused. It is just a reflection of the fact that it uses DMA hardware. The code for tiu.c in NSYS/V4 is rather different from the code in the SRI-NOSC tree: thinking on how to select channels seems to have changed in between these two versions. [4] Also I found the below post that mentions the snstat() call: http://minnie.tuhs.org/pipermail/tuhs/2015-December/006286.html The object code for snstat() is in libc.a in the dmr's V5 image. Reconstructed, the source code is here: http://chiselapp.com/user/pnr/repository/Spider/artifact/a93175746bd9f94f In short, snstat() is a modified stty call, an evolution in the direction of the later ioctl() system call. No progress as yet on the early history of 'alarm()'. Paul

8 years, 2 months

Early Unix Spider network

by Paul Ruizendaal

>> It is a paper copy, but I can make a scan for you. > > That makes it sounds like it might not be possible to put it online? > What's the exact title, so I can look and see if it's already online? > I'm pretty sure I've got a hardcopy of some Spider thing, but it would > probably take me a while to find it... ;-) The report I have is: "SPIDER-a data communication experiment", Tech Report 23 , Bell Lab, 1974. I did not find it online, but it may be out there somewhere. I think it can be public now, but doing some checks. > OK, the only one I have is 'nfs'. Here's the source, and man page: > > http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a > http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6 Many thanks! There is some puzzling stuff in there that I'd like to figure out, but that is easier to discuss once the report is online. Also, it turns out that the TIU driver was in Warren's repo all along: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/dmr/tdir/tiu.c http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/man/man4/tiu.4 It's fun to read that the V4 man page says "The precise nature of the UNIX interface has not been defined yet." and Noel's version says: "The precise nature of the UNIX interface is defined elsewhere." (yet the dates are the same!). Some things are surprising (to me, at least): First of all, opening a connection to the File Store is a single open on data channel 1: http://chiselapp.com/user/pnr/repository/Spider/artifact/854a591c0e7a3a54?l… I would expected the code to first have sent a connection request to the switch on control channel 1. Perhaps the File Store was an integral part of the switch/router (a Tempo minicomputer ftp://bitsavers.informatik.uni-stuttgart.de/pdf/tempoComputers/TEMPO-1_ad_Nov69.pdf) with channel 1 functionality hardwired. Next, the code has a hackish form of non-blocking I/O: http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l… I'm puzzled about the alarm() sys call. That did not exist in 1973 -- or did it only exist in Bell Labs private builds? The code calls snstat(), for instance here: http://chiselapp.com/user/pnr/repository/Spider/artifact/55ee75831bd98d6c?l… That seems to be a sys call to here: http://chiselapp.com/user/pnr/repository/Spider/artifact/2c7d65073a7cb0a5?l… Could that be the tiu sys call (#45) in the sysent.c table for V4-V6?

8 years, 2 months

can't protect files from deletion v5,v6, or v7

by Mark Longridge

Ok, I just did an experiment with the rm command and the results surprised me. On Unix v5 logged in as root I created a small test file then did chmod 444 on it. Unfortunately it appears that mere users can still rm the file and also directories are not safe from the rmdir command (even directories set to mode 444). This seems to be the case for v6 and v7 as well. To be fair rm will prompt the user with: test1: 0100444 mode but the user only has to type y and hit enter and the file is toast. Is there no way to completely protect files from being deleted? Mark

8 years, 2 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal >>> the 1974 report on Spider >> Is that online? If not, any chances you can make it so? > It is a paper copy, but I can make a scan for you. That makes it sounds like it might not be possible to put it online? What's the exact title, so I can look and see if it's already online? I'm pretty sure I've got a hardcopy of some Spider thing, but it would probably take me a while to find it... ;-) > I think that in the lifespan of Spider (1972-1978) there were 3 main > network programs (basing myself on McIlroy's Unix Reader): > - 'nfs' an FTP-like program ... > - 'ufs' not sure what it was, but I think a telnet-like facility > - 'npr' a network printing program OK, the only one I have is 'nfs'. Here's the source, and man page: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/nfs.a http://ana-3.lcs.mit.edu/~jnc/tech/unix/man6/nfs.6 Noel

8 years, 2 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by Paul Ruizendaal

> >> I'm looking into the history of Spider and early Datakit. Sandy Fraser >> was kind enough to send me the 1974 report on Spider > > Is that online? If not, any chances you can make it so? It is a paper copy, but I can make a scan for you. > which contains the drivers tiu.c, mpx.c - I'm not sure what other files there > are part of it? I think tiu.c might be all. The TIU ("terminal access unit") was the network card, so to speak (actually some 5 boards in a rack) and did a lot of the heavy lifting. From the tiu.c file I understand that a DR11-B parallel I/O card was used on the PDP side to connect to the TIU, and that access was structured as a block device driver. > I'm not at all clear how this stuff got there - someone at Bell must have just > dumped the contents of the 'dmr' directory, and sent it all off? Looks like it. > The PWB1-based MIT systems also have a lot of the Spider software (although it > was never used). It's a slightly different version than the one above: 'diff' > shows that 'tiu.c' is almost identical, but mpx.c has more significant > differences. > > It also contains man pages, and sources for some (?) user programs; I have the > source and manpage for 'nfs'. What other names should I be looking for? (The > man page for 'nfs' doesn't list any other commands.) I'll put them up > momentarily. I think that in the lifespan of Spider (1972-1978) there were 3 main network programs (basing myself on McIlroy's Unix Reader): - 'nfs' an FTP-like program to copy files to/from a central File Store. I'm not sure whether the File Store was a Unix machine or something else. - 'ufs' not sure what it was, but I think a telnet-like facility - 'npr' a network printing program A little surprising, but no reference to a Spider mail program in that document. > In the meantime, I'll append the 'tiu' man page. Thanks! It is from October 1973, which sounds right for Spider. I guess this code is the first networking on Unix, predating the UoI work by about 18 months.

8 years, 2 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > I'm looking into the history of Spider and early Datakit. Sandy Fraser > was kind enough to send me the 1974 report on Spider Is that online? If not, any chances you can make it so? > Does anybody know of surviving v5/v6/v7 code for Spider networking (e.g. > the 'tiu' device driver, the 'nfs' file transfer package, etc.)? You're in luck. To start with, check out: http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/dmr/oldstuff which contains the drivers tiu.c, mpx.c - I'm not sure what other files there are part of it? I'm not at all clear how this stuff got there - someone at Bell must have just dumped the contents of the 'dmr' directory, and sent it all off? The PWB1-based MIT systems also have a lot of the Spider software (although it was never used). It's a slightly different version than the one above: 'diff' shows that 'tiu.c' is almost identical, but mpx.c has more significant differences. It also contains man pages, and sources for some (?) user programs; I have the source and manpage for 'nfs'. What other names should I be looking for? (The man page for 'nfs' doesn't list any other commands.) I'll put them up momentarily. In the meantime, I'll append the 'tiu' man page. There isn't one for mpx, alas. Noel -------- .th TIU IV 10/28/73 .sh NAME tiu \*- Spider interface .sh DESCRIPTION Spider is a fast digital switching network. .it Tiu is a directory which contains files each referring to a Spider control or data channel. The file /dev/tiu/d\fIn\fR refers to data channel \fIn;\fR likewise /dev/tiu/c\fIn\fR refers to control channel \fIn\fR. .s3 The precise nature of the UNIX interface is specified elsewhere. .sh FILES /dev/tiu/d?, /dev/tiu/c? .sh BUGS

8 years, 3 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by Paul Ruizendaal

>> There are two other routes to TCP/IP on a PDP11 without split I/D: >> ... >> DCEC's adaptation of the Wingfield TCP/IP library, designed to work >> with V6. It is mostly a user space daemon, but requires some kernel >> enhancements. > > I wonder what the performance would be like, since the TCP is in a user > process (a different one from the application), i.e. there's a process switch > every time the application goes to send or receive data. This wouldn't have > been such an issue when the code was written, since ARPANet-type networks > were not very fast, but with a better network, it would have been limiting. IEN98 (http://www.rfc-editor.org/rfc/ien/ien98.txt, page 2) has the answer: about 10kb/s. The DCEC version used shared memory instead of rand ports and was claimed to be a bit more performant, but I have no number. I'd be surprised if it was twice as fast, so perhaps 15kb/s. Paul

8 years, 3 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > So some other mechanism (also discussed here) needed to be created to > avoid blocking in the application. > ... > Rand, UNET & Chaos had something else that gave the save async function, > who's name I've forgotten at the moment I don't think the RAND code had the non-blocking stuff; AFAICR, all it had was named pipes (effectively). Jack Haverty at BBN defined and implemented two new calls (IIRC, 'capac()' and 'await()') to do non-blocking I/O. The documentation for that is in the 'BBN' branch at TUHS: http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/await http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc/ipc/ipc My memory might be incorrect, but I don't think it was asynchronous (i.e. a process issued a read() or write(), and that returned right away, before the I/O was actually done, and the system notified the process later when the I/O actually completed). I actually did implement asyn I/O for an early LAN device driver - and just to make it fun, the device was a DMA device, and we didn't want the overhead of a copy, so the DMA was direct to buffers in the process - i.e. 'raw' I/O. So that required some major system tweaks, to keep the process from being swapped out - or moved around - while the I/O was pending. > I believe Noel posted the code for same in the last year from one of the > MIT kernels I found it on the dump of an MIT machine, but it was never run on any machine at MIT - we just had the source in case we had any use fot it. Noel

8 years, 3 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by jnc＠mercury.lcs.mit.edu

> From: Paul Ruizendaal > There are two other routes to TCP/IP on a PDP11 without split I/D: > ... > DCEC's adaptation of the Wingfield TCP/IP library, designed to work > with V6. It is mostly a user space daemon, but requires some kernel > enhancements. I wonder what the performance would be like, since the TCP is in a user process (a different one from the application), i.e. there's a process switch every time the application goes to send or receive data. This wouldn't have been such an issue when the code was written, since ARPANet-type networks were not very fast, but with a better network, it would have been limiting. > From: Steve Simon > do you have pointers to any documentation on the rand/MIT network API? There was no 'MIT' network API. He was talking about the CHAOSNet API. The TCP/IP done in the CSR group at MIT used a totally different API. The various Unix systems at MIT were pretty well out of touch with each other, and did not exchange code. The only exceptions were the DSSR (later RTS) and CSR groups in Tech Sq, who used pretty much the same system. Noel

8 years, 3 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by Paul Ruizendaal

I had somehow convinced myself that Ultrix-11 needed split I/D, but indeed it does not: # file unix unix: (0450) pure overlay executable not stripped # size unix 14784+(8192,8000,8064,8000,8064,8128,8000,7808,7936,7936,7680,7360,1344)+3524+13500 = 31808b = 076100b (111296 total text) With only 16KB of permanent kernel there will be a lot of overlay switching. I'm not entirely sure why bss could not be 1KB smaller, enabling 8KB more of permanent kernel. The loss of performance from 2 disk buffers less really outweighed less overlay switching? If I understand correctly, the network code continuously switches around segment 5 to access the right mbuf. According to the notes in the TUHS archive (http://www.tuhs.org/Archive/Distributions/DEC/Ultrix-11/Fred-Ultrix3/setup-…) running Ultrix-11 with networking on a 11/40 class machine is borderline workable: "I have personally tested it on a 23+, 53 and 83. I know it runs fine on the 73. The smaller machines (34, 40 etc) should work akin to the 23, meaning using overlays and be very tight on RAM for the drivers. TCP/IP is a biiiiig load for those systems!" There are two other routes to TCP/IP on a PDP11 without split I/D: - 3COM's TCP/IP package (initially an overlay over V7, soon after also over 2BSD); I believe the source to this is lost. - DCEC's adaptation of the Wingfield TCP/IP library, designed to work with V6. It is mostly a user space daemon, but requires some kernel enhancements. The Wingfield code is in the TUHS archive, but that version has a modified V6 kernel that also supports NCP networking and requires split I/D. If used with a minimally enhanced V6 kernel, it would easily fit in 64KB, without overlays. Note that these last two options have very different API's and would not be so easy to work with. Paul

8 years, 3 months

Fwd: Re: Unix with TCP/IP for small PDP-11s

by William Pechter

-----Original Message----- From: pechter(a)gmail.com To: arnold(a)skeeve.com Sent: Sat, 20 May 2017 16:41 Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s Missed the reply all on the phone. Phil Karn had KA9Q in the 80s... It is mentioned on Wikipedia... Don't know much more. PPP might be better than slip. Bill -----Original Message----- From: arnold(a)skeeve.com To: pechter(a)gmail.com Sent: Sat, 20 May 2017 16:12 Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s Yes! Do you want to follow up to the list please? Thanks, Arnold William Pechter <pechter(a)gmail.com> wrote: > KA9Q sound right? > > -----Original Message----- > From: arnold(a)skeeve.com > To: imp(a)bsdimp.com, bqt(a)update.uu.se > Cc: tuhs(a)minnie.tuhs.org > Sent: Sat, 20 May 2017 15:06 > Subject: Re: [TUHS] Unix with TCP/IP for small PDP-11s > > Warner Losh <imp(a)bsdimp.com> wrote: > > > I read the sources to see the TCP/IP support was there (that's the bit > > about adding Berkeley Sockets). I see nowhere that it's excluded for the > > non I/D machines, but haven't tried it first hand. I got interested not > > because of the PDP-11, but because I have an old Rainbow that recently > > started running Venix (v7-based version) and was trolling around for some > > way to do TCP/IP to it (though w/o readily available ethernet cards, I'm > > not sure it is a viable project). > > Boy is the memory going. What was the TCP/IP implementation people > ran on DOS to do connections over serial lines? Could that be found > and revived for such a system? > > Thanks, > > Arnold

8 years, 3 months

Re: [TUHS] 11/60 (was: Unix with TCP/IP for small PDP-11s)

by Johnny Billquist

On 2017-05-21 23:27, Clem Cole <clemc(a)ccc.com> wrote: > Actually, the 11/60's main claim to fame was it supposed to be a > 'commercial' PDP-11 and was built for the small business market. The WCS > was a side effect. As you mentioned in another mail, it's main claim to fame was probably the short time it actually existed in the market. DEC seriously did some things wrong on it, such as only 18-bit address, and no split I/D space, at a time when pretty much any other PDP-11 was going there. But it was also one of a couple of -11 models where you had the ability to write your own microcode. But I've never heard of anyone who had the WCS option. (But at one point, I was playing with four 11/60 machines in a computer club.) I don't remember if it was you or someone else who said that there were several microcode bugs in the 11/60. It ran the DEC OSes, but there were some issues with Unix. I seem to also remember seeing some special code in the RSX kernel for some 11/60 oddity, but I would have to search through the code to remember exactly what that was about. > It was to built to run RSTS and RSX and had a commercial instruction set > exten *etc.*. Somebody had written a 'dentist office' package for it and a > 'car dealership package' IIRC. And was physically packaged a tad > differently than the other 11's as it was trying to be marketing to places > that might want to show it off instead of hiding it in a computer room. Uh? I have not seen any plans ever mentioning CIS for the 11/60, but I guess it's possible it was considered at some point. But I can assure you no CIS ever existed for the 11/60. The only machines that ever had the CIS option was the 11/44 and 11/23,11/24. But I have no idea how many machines ever actually had the option installed. One nice detail of the 11/60 is that it had the FPP build in. But there was also an optional hardware FPP accelerator available. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 3 months

Unix with TCP/IP for small PDP-11s

by jnc＠mercury.lcs.mit.edu

I'm trying to find out if there is any existing Unix for the PDP-11 which supports TCP/IP on /40-/34-23 class machines (i.e. non-I+D machines)? Does 2.9 BSD with TCP/IP (assuming such a thing exists) fit on those machines? (I know 2.9 does run on them, but I don't know about the TCP/IP part.) The reason I ask is that MIT did a TCP/IP for V6 which would run on them (only incoming packet de-mux is in the kernel - the TCP is in with the application, in the user process), which has recently been recovered from a backup tape. I'm trying to figure out if there is any use for it, as it would take some work to make it usable (I'd have to write device drivers for available Ethernet cards, and adapt an ARP implementation for it). Noel

8 years, 3 months

Re: [TUHS] Unix with TCP/IP for small PDP-11s

by Johnny Billquist

On 2017-05-20 04:00, Warner Losh <imp(a)bsdimp.com> wrote: > https://ia601901.us.archive.org/10/items/bitsavers_decpdp11ulLTRIX112.0SPDS… > > Looks like it requires MMU, but not split I/D space as it lists the > following as compatible: M11, 11/23+, 11/24, 11/34, 11/40 and 11/60. It > does require 256kb of memory. See table 2, page 6 for details. Uh...? Where do you see that there is any TCP/IP support in Ultrix-11? If any was done by someone else, there is no saying that it would be usable on a machine without split I/D. To be honest, I've never seen any mention of TCP/IP on any machine without split I/D space. I guess it could be done, but it would be a rather big headache... Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

8 years, 3 months

Re: [TUHS] The evolution of Unix facilities and architecture

by David

At Celerity we were porting Unix to a new NCR chipset for our washing machine sized Workstation. We had a VAX 750 as the development box and we cross compiled to the NCR box. We contracted out the 750 maintenance to a 3rd party and had no problems for a couple of years. Then one day I came in to work to find the VAX happy consuming power and doing nothing. Unix wasn’t running and nothing I could do would bring it back. After about 2 hours I got my boss and we contacted the maintenance company. They guy they sent did much what I’d done and then went around the back. He pushed on the backplane of the machine and Lo, it started working. He then removed the pressure and it failed quite immediately. Turns out the backplane had a broken trace in it. We had done no board swaps in many months and the room had had no A/C faults of any kind. The company got a new backplane and had it installed in 2 days. Being 3rd party we couldn’t get it replaced any quicker. After that it worked like a champ. Celerity eventually became part of Sun as Sun Supercomputer. David

8 years, 3 months

Old Unix vulnerabilities

by Dave Horsfall

OK, I'll kick it off. A beauty in V6 (and possibly V7) was discovered by the kiddies in Elec Eng; by sending a signal with an appropriately-crafted negative value (as determined from inspecting <user.h>) you could overwrite u.u_uid with zero... Needless to say I scrambled to fix that one on my 11/40 network! -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

8 years, 3 months

Re: [TUHS] The evolution of Unix facilities and architecture

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall > Err, isn't that the sticky bit, not the setuid bit? Oh, right you are. I just looked in the code for ptrace(), and assumed that was it. The fix is _actually_ in sys1$exec() (in V6) and sys1$getxfile() (in PWB1 and the MIT system: /* * set SUID/SGID protections, if no tracing */ if ((u.u_procp->p_flag&STRC)==0) { if(ip->i_mode&ISUID) if(u.u_uid != 0) { u.u_uid = ip->i_uid; u.u_procp->p_uid = ip->i_uid; } The thing is, this code is identical in V6, PWB1, and MIT system!? So now I'm wondering - was this really the bug? Or was there some bug in ptrace I don't see, which was the actual bug that's being discussed here. Because is sure looks like this would prevent the exploitation that I described (start an SUID program under the debugger, then patch the code). Or perhaps somehow this fix was broken by some other feature,, and that introduced the exploit? Noel

8 years, 3 months

Re: [TUHS] The evolution of Unix facilities and architecture

by jnc＠mercury.lcs.mit.edu

> From: "Steve Johnson" > a DEC repairperson showed up to do "preventive maintenance" and managed > to clobber the nascent file system. > Turns out DEC didn't have any permanent file systems on machines that > small... A related story (possibly a different version of this one) which I read (can't remember where, now) was that he trashed the contents of the RS04 fixed-head hard disk, because on DEC OS's, those were only used for swapping. Noel

8 years, 3 months

Re: [TUHS] C declarations.

by Steve Johnson

Some interesting comments: "You all are missing the point as to what the cost of passing arrays by value or what other languages do" I don't think so. To me the issues is that the model of what it means to compute has changed since the punch-card days. When you submitted a card deck in the early days, you had to include both the function definition and the data--the function was compiled, the data was read, and, for the most part there were no significant side effects (just a printout, and maybe some stuff on mag tape). This was a model that had served mathematics well for centuries, and it was very easy to understand. Functional programming people still like it a lot... However, with the introduction of permanent file systems, a new paradigm came into being. Now, interactions with the computer looked more like database transactions: Load your program, change a few lines, put it back, and then call 'make'. Trying to describe this with a purely functional model leads to absurdities like: file_system = edit( file_system, file_selector, editing_commands ); In fact, the editing commands can change files, create new ones, and even delete files. There is no reasonable way to handle any realistic file systems with this model (let alone the Internet!) In C's early days, we were just getting into the new world. Call by value for arrays would have been expensive or impossible on the machine with just a few kilobytes of memory for program + data. So we didn't do it. Structures were initially handled like arrays, but the compiler chose to make a local copy when passed a structure pointer. This copy was, at one time, in static memory, which caused some problems. Later, it went on the stack. It wasn't much used... This changed when the Blit terminal project was in place. It was just too attractive on a 68000 to write struct pt = { int x; int y } /* when int was 16-bits */ and I made PCC pass small structures like this in registers, like other arguments. I seem to remember a dramatic speedup (2X or so) from doing this... "(did) Dennis / Brian/ Ken regret this design choice? Not that I recall. Of course, we all had bugs in this area. But I think the lack of subscript range checking was a more serious problem than using pointers in the first place. And, indeed, for a few of the pioneers, BCPL had done exactly the same thing. Steve

8 years, 3 months

C declarations.

by Ron Natalie

Bjarne agrees with you. He put the * (and the &) with the type name to emphasize it is part of the type. This works fine as long as you only use one declaration per statement. The problem with that is that * doesn't really bind to the type name. It binds to the variable. char* cp1, cp2; // cp1 is pointer to char, cp2 is just a char. I always found it confusing that the * is used to indicate an pointer here, where as when you want to change an lvalue to a pointer, you use &. But if we're going to gripe about the evolution of C. My biggest gripe is when they fixed structs to be real types, they didn't also do so for arrays. Arrays and their degeneration to poitners is one of the biggest annoyances in C. > Am I the only one here who thinks that e.g. a char pointer should be > "char* cp1, cp2" instead of "char *cp1, *cp2"? I.e. the fundamental type is "char*", not "char", and to this day I still write:

8 years, 3 months

Re: [TUHS] C declarations.

by Richard Tobin

> Fortran, for the record, passes nearly everything by reference Sort of. The Fortran 77 standard imposes restrictions that appear to be intended to allow the implementation to pass by value-and-result (i.e. values are copied in, and copied back at return). In particular it disallows aliasing that would allow you to distinguish between the two methods: If a subprogram reference causes a dummy argument in the referenced subprogram to become associated with another dummy argument in the referenced subprogram, neither dummy argument may become defined during execution of that subprogram. http://www.fortran.com/F77_std/rjcnf-15.html#sh-15.9.3.6 -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

8 years, 3 months

Re: [TUHS] The evolution of Unix facilities and architecture

by jnc＠mercury.lcs.mit.edu

> From: Random832 > Ah. There's the other piece. You start the SUID program under the > debugger, and ... it simply starts it non-suid. *However*, in the > presence of shared text ... you can make changes to the text image > ... which will be reused the *next* time it is started *without* the > debugger. So I actually tried to do this (on a V6 system running on an emulator), after whipping up a tiny test program (which prints "1", and the real and current UIDs): the plan was to patch it to print a different number. However, after a variety of stubbed toes and hiccups (gory details below, if anyone cares), including a semi-interesting issue with the debugger and pure texts), I'm punting: when trying to set a breakpoint in a pure text, I get the error message "Can't set breakpoint", which sort of correlates with the comment in the V6 sig$ptrace(): "write user I (for now, always an error)". So it's not at all clear that the technique we thought would work would, in fact, work - unless people weren't using a stock V6 system, but rather one that had been tweaked to e.g. allow use of debuggers on pure-text programs (including split I+D). It's interesting to speculate on what the 'right' fix would be, if somehow the techique above did work. The 'simple' fix, on systems with a PWB1-line XWRIT flag, would be to ignore SETUID bits when doing an exec() of a pure text that had been modified. But probably 'the' right fix would be to give someone debugging a pure-text program their own private copy of the text. (This would also prevent people who try to run the program from hitting breakpoints while it's being debugged. :-) But anyway, it's clear that back when, when I thought I'd found the bug, I clearly hadn't - which is why when I looked into the source, it looked like it had been 'already' been fixed. (And why Jim G hemmed and hawed...) But I'm kind of curious about that mod in PWB1 that writes a modified pure text back to the swap area when the last process using it exits. What was the thinking behind that? What's the value to allowing someone to patch the in-core pure text, and then save those patches? And there's also the 'other people who try and run a program beind debugged are going to hit breakpoints' issue, if you do allow writing into pure texts... Noel -------- For the gory details: to start with, attempting to run a pure-text program (whether SUID or not) under the debugger produced a "Can't execute {program-name} Process terminated." error message. 'cdb' is printing this error message just after the call to exec() (if that fails, and returns). I modified it to print the error number when that happens, and it's ETXTBSY. I had a quick look at the V6 source, to see if I could see what the problem is, and it seems to be be (in sys1$exec()): if(u.u_arg[1]!=0 && (ip->i_flag&ITEXT)==0 && ip->i_count!=1) { u.u_error = ETXTBSY; goto bad; } What that code does is a little obscure; I'm not sure I understand it. The first term checks to see if the size of the text segment is non-zero (which it is not, in both 0407 and 0410 files). The second is, I think, looking to see if the inode is marked as being in use for a pure text (which it isn't, until later in exec()). The third checks to make sure nobody else is using the file. So I guess this prevents exec() of a file which is already open, and not for a pure text. (Why this is the Right Thing is not instantly clear to me...) Anyway, the reason this fails under 'cdb' is that the debugger already has it open (to be able to read the code). So I munged the debugger to close it before doing the exec(), and then the error went away. Then I ran into a long series of issues, the details of which are not at all interesting, connected with the fact that the version of 'cdb' I was using (one I got off a Tim Shoppa modified V6 disk) doesn't correspond to either of the sources I have for 'cdb'. When I switched to the latest source (so I could fix the issue above), it had some bug where it wouldn't work unless there was a 'core' file. But eventually I kludged it enough to get the 'can't set breakpoints' message, at which point I threw in the towel.

8 years, 3 months

Re: [TUHS] The evolution of Unix facilities and architecture

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > it was was originally written for the for the 6th edition FS (which I > hope I have still have the sources in my files) ... > I believe Noel recovered a copy in his files recently. Well, I have _something_. It's called 'fcheck', not 'fsck', but it looks like what we're talking about - maybe it was originally named, or renamed, to be in the same series as {d,i,n}check? But it does have the upper-case error messages... :-) Anyway, here it is: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/fcheck.8 Interestingly, the man page for it makes reference to a 'check' command, which I didn't recall at all; here it is: http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/check.c http://ana-3.lcs.mit.edu/~jnc/tech/unix/man8/check.8 for those who are interested. > Noel has pointed out that MIT had it in the late 1970s also, probably > brought back from BTL by one of their summer students. I think most of the Unix stuff we got from Bell (e.g. the OS, which is clearly PWB1, not V6) came from someone who was in a Scout unit there in high school, of all bizarre connections! ISTR this came the same way, but maybe I'm wrong. It definitely arrived later than the OS - we'd be using icheck/dcheck for quite a while before it arrived - so maybe it was another channel? The only thing that for sure (that I recall) that didn't come this way was Emacs. Since the author had been a grad student in our group at MIT, I think you all can guess how we got that! Noel

8 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS