TUHS

tuhs@tuhs.org

2 participants
6532 discussions

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

Re: [TUHS] C declarations.

by Doug McIlroy

> Are there languages that copy arrays in function calls defaultly? > Pascal is an example. Pascal's var convention, where the distinction between value and reference is made once and for all for each argument of each function, is sound. The flexibility of PL/I, where the distinction is made at every call (parenthesize the name to pass an array by value) is finicky, though utterly general. > Where is all that [memory] going to come from if you pass a > large array on a memory-constrained system of specs common back in the > days when C was designed Amusingly, under the customary linkage method in the even earlier days when Fortran was designed, pass-by-reference entailed a big overhead that could easily dominate pass-by-value for small arrays. [In the beginning, when CPUs had only one register, subroutine preambles plugged the reference into every mention of that variable throughout the body of the subroutine. This convention persisted in Fortran, which was designed for a machine with three index registered. Since reference variables were sometimes necessary (think of swap(a,b) for example) they were made standard.] Doug

8 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: Random832 > It seems to me that this check is central to being able to (or not) > modify the in-core image of any process at all other than the one being > traced (say, by attaching to a SUID program that has already dropped > privileges, and making changes that will affect the next time it is > run). Right, good catch: if you have a program that was _both_ sticky and SUID, when the system is idle (so the text copy in the swap area won't get recycled), call up a copy under the debugger, patch it, exit (leaving the patched copy), and then re-run it without the debugger. I'd have to check the handling of patched sticky pure texts - to see if they are retained or not. {Checks code.} Well, the code to do with pure texts is _very_ different between V6 and PWB1. The exact approach above might not work in V6, because the modified (in-core) copy of pure texts are simply deleted when the last user exits them. But it might be possible for a slight variant to work; leave the copy under the debugger (which will prevent the in-core copy from being discarded), and then run it again without the debugger. That might do it. Under PWB1, I'm not sure if any variant would work (very complicated, and I'm fading). There's an extra flag bit, XWRIT, which is set when a pure text is written into; when the last user stops using the in-code pure text, the modified text is written to swap. (It lools like the in-core copy is always discarded when the last user stops using it.) But the check for sticky would probably stop a sticky pure-text being modified? But maybe the approach that seems like it would work under V6 (leave the patched, debugger copy running, and start a new instance) looks like it should work here too. So maybe the sticky thing is irrelevant? On both V6 and PWB1, it just needs a pure text which is SETUID: start under the debugger, patch, leave running, and start a _new_ copy, which will run the patched version as the SUID user. Noel

8 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole > I said -- profil - I intended to say ptrace(2) Is that the one where running an SUID program under the debugger allowed one to patch the in-core image of said program? If so, I have a story, and a puzzle, about that. A couple of us, including Jim Gettys (later of X-windows fame) were on out way out to dinner one evening (I don't recall when, alas, but I didn't meet him until '80 or so), and he mentioned this horrible Unix security bug that had just been found. All he would tell me about it (IIRC) was that it involved ptrace. So, over dinner (without the source) I figured out what it had to be: patching SUID programs. So I asked him if that was what it was, and I don't recall his exact answer, but I vaguely recall he hemmed and hawed in a way that let me know I'd worked it out. So when we got back from dinner, I looked at the source to our system to see if I was right, and.... it had already been fixed! Here's the code: if (xp->x_count!=1 || xp->x_iptr->i_mode&ISVTX) goto error; Now, we'd been running that system since '77 (when I joined CSR), without any changes to that part of the OS, so I'm pretty sure this fix pre-dates your story? So when I saw your email about this, I wondered 'did that bug get fixed at MIT when some undergrad used it to break in' (I _think_ ca. '77 is when they switched from an OS called Delphi on the -11/45 used for the undergrad CS programming course - I _think_ they switched that machine from Delphi to Unix), or did it come with PWB1? (Like I said, that system was mostly PWB1.) So I just looked in the PWB1 sources, and... there it is, the _exact_ same fix. So we must have got it from PWB1. So now the question is: did the PWB guys find and fix this, and forget to tell the research guys? Or did they tell them, and the research guys blew them off? Or what? Noel

8 years, 1 month

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

by Doug McIlroy

> We all took the code back and promised to get patches out ASAP and not tell any one about it. Fascinating. Chnages were installed frequently in the Unix lab, mostly at night without fanfare. But an actual zero-day should have been big enough news for me to have heard about. I'm pretty sure I didn't; Dennis evidently kept his counsel. Doug

8 years, 1 month

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

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" > Ordered writes go back to the original BSD fast file system, no? I seem > to recall that when we switched from our V6/V7 disks, the filesystem got > a lot more stable in crashes. I had a vague memory of reading about that, so I looked in the canonical FFS paper (McKusick et al, "A Fast File System for UNIX" [1984)]) but found no mention of it. I did find a paper about 'fsck' (McKusick, Kowalski, "Fsck: The UNIX File System Check Program") which talks (in Section 2.5. "Updates to the file system") about how "problem[s] with asynchronous inode updates can be avoided by doing all inode deallocations synchronously", but it's not clear if they're talking about something that was actually done, or just saying (hypothetically) that that's how one would fix it. Is is possible that the changes to the file system (e.g. the way free blocks were kept) made it more crash-proof? Noel

8 years, 1 month

Re: [TUHS] C declarations.

by Richard Tobin

> 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 > &. The way to read it is that you are declaring *cp1 as a char. -- 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: Warner Losh > There's a dcheck.c in the TUHS v7 sources. How's that related? That was one of the earlier tools - not sure how far back it goes, but it's in V6, but not V5. It consistency checks the directory tree. Another tool, 'icheck', consistency checks file blocks and the free list. Noel

8 years, 1 month

The evolution of Unix facilities and architecture

by Diomidis Spinellis

I've made available on GitHub a series of tables showing the evolution of Unix facilities (as documented in the man pages) over the system's lifetime [1] and two diagrams where I attempted to draw the corresponding architecture [2]. I've also documented the process in a short blog post [3]. I'd welcome any suggestions for corrections and improvements you may have, particularly for the architecture diagrams. [1] https://dspinellis.github.io/unix-history-man/ [2] https://dspinellis.github.io/unix-architecture/ [3] https://www.spinellis.gr/blog/20170510/ Cheers, Diomidis

8 years, 1 month

Re: [TUHS] Discuss of style and design of computer programs from a

by Nemo

On 6 May 2017 at 11:23, ron minnich <rminnich(a)gmail.com> wrote (in part): [...] > Lest you think things are better now, Linux uses self modifying code to > optimize certain critical operations, and at one talk I heard the speaker > say that he'd like to put more self modifying code into Linux, "because it's > fun". Oh boy. Fun, indeed! Even self-modifying chips are being touted -- Yikes! N.

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