TUHS

tuhs@tuhs.org

2 participants
6532 discussions

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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