Bakul Shah:
Unfortunately strcpy & other buffer overflow friendly
functions are still present in the C standard (I am looking at
n2434.pdf, draft of Sept 25, 2019). Is C really not fixable?
====
If you mean `can C be made proof against careless programmers,'
no. You could try but the result wouldn't be C. And Flon's
Dictum applies anyway, as always.
It's perfectly possible to program in C without overflowing
fixed buffers, just as it's perfectly possible to program in
C without dereferencing a NULL or garbage pointer. I don't
claim to be perfect, but before the rtm worm rubbed my nose
in such problems, I was often sloppy about them, and afterward
I was very much aware of them and paid attention.
That's all I ask: we need to pay attention. It's not about
tools, it's about brains and craftmanship and caring more
about quality than about feature count or shiny surfaces
or pushing the product out the door.
Which is a good bit of what was attractive about UNIX in
the first place--that both its ideas and its implementation
were straightforward and comprehensible and made with some
care. (Never mind that it wasn't perfect either.)
Too bad software in general and UNIX descendants in particular
seem to have left all that behind.
Norman Wilson
Toronto ON
PS: if you find this depressing, cheer yourself up by watching
the LCM video showing off UNICS on the PDP-7. I just did, and
it did.
I hadn't seen this yet - apologies if it's not news:
https://livingcomputers.org/Blog/Restoring-UNIX-v0-on-a-PDP-7-A-look-behind…
Quoting:
"I recently sat down with Fred Yearian, a former Boeing engineer, and
Jeff Kaylin, an engineer at Living Computers, to talk about their
restoration work on Yerian’s PDP-7 at Living Computers: Museum +
Labs."
[...]
Up until the discovery of Yearian’s machine, LCM+L’s PDP-7 was
believed to be the only operational PDP-7 left in the world. Chuckling
to himself, Yearian recalls hearing this history presented during his
first visit to LCM+L.
“I walked in the computer museum, and someone said ‘Oh, this is the
only [PDP-7] that’s still working’.
And I said, ‘Well actually, I got one in my basement!’”
[end quote]
Fun story - and worthy work. Nicely done.
--
Royce
Hi.
Doug McIlroy is probably the best person to answer this.
Looking at the V3 and V4 manuals, there is a reference to the m6 macro
processor. The man page thereof refers to
A. D. Hall, The M6 Macroprocessor, Bell Telephone Laboratories, 1969
1. Is this memo available, even in hardcopy that could be scanned?
2. What's the history of m6, was it written in assembler? C?
3. When and why was it replaced with m4 (written by DMR IIRC)?
More generally, what's the history of m6 prior to Unix?
IIRC, the macro processor in Software Tools was inspired by m4,
and in particular its immediate evaluation of its arguments during
definition.
I guess I'll also ask, how widespread was the use of macro processors
in high level languages? They were big for assembler, and PL/1 had
a macro language, but I don't know of any other contemporary languages
that had them. Were the general purpose macro processors used a lot?
E.g. with Fortran or Cobol or ...
I'm just curious. :-)
Thanks,
Arnold
I think I recall an explicit statement somewhere from an
interview with Robert that the worm was inspired partly
by Shockwave Rider.
I confess my immediate reaction to the worm was uncontrollable
laughter. I was out of town when it happened, so I first
heard it from a newspaper article (and wasn't caught up in
fighting it or I'd have laughed a lot less, of course); and
it seemed to me hilarious when I read that Robert was behind
it. He had interned with 1127 for a few summers while I was
there, so I knew him as very bright but often a bit careless
about details; that seemed an exact match for the worm.
My longer-term reaction was to completely drop my sloppy
old habit (common in those days not just in my code but in
that of many others) of ignoring possible buffer overflows.
I find it mind-boggling that people still make that mistake;
it has been literal decades since the lesson was rubbed in
our community's collective noses. I am very disappointed
that programming education seems not to care enough about
this sort of thing, even today.
Norman Wilson
Toronto ON
> That was the trouble; had he bothered to test it on a private network (as
> if a true professional would even consider carrying out such an act)[*] he
> would've noticed that his probability calculations were arse-backwards
Morris's failure to foresee the results of even slow exponential
growth is matched by the failure of the critique above to realize
that Morris wouldn't have seen the trouble in a small network test.
The worm assured that no more than one copy (and occasionally one clone)
would run on a machine at a time. This limits the number of attacks
that any one machine experiences at a time to roughly the
number of machines in the network. For a small network, this will
not be a major load.
The worm became a denial-of-service attack only because a huge
number of machines were involved.
I do not remember whether the worm left tracks to prevent its
being run more than once on a machine, though I rather think
it did. This would mean that a small network test would not
only behave innocuously; it would terminate almost instantly.
Doug
FYI.
----- Forwarded message from Linus Torvalds <torvalds(a)linux-foundation.org> -----
Date: Wed, 13 Nov 2019 12:37:50 -0800
From: Linus Torvalds <torvalds(a)linux-foundation.org>
To: Larry McVoy <lm(a)mcvoy.com>
Subject: Re: enum style?
On Wed, Nov 13, 2019 at 10:28 AM Larry McVoy <lm(a)mcvoy.com> wrote:
>
> and asked what was the point of the #defines. I couldn't answer, the only
> thing I can think of is so you can say
>
> int flags = MS_RDONLY;
>
> Which is cool, but why bother with the enum?
For the kernel we actually have this special "type-safe enum" checker
thing, which warns about assigning one enum type to another.
It's not really C, but it's close. It's the same tool we use for some
other kernel-specific type checking (user pointers vs kernel pointers
etc): 'sparse'.
http://man7.org/linux/man-pages/man1/sparse.1.html
and in particular the "-Wenum-mismatch" flag to enable that warning
when you assign an enum to another enum.
It's quite useful for verifying that you pass the right kind of enum
to functions etc - which is a really easy mistake to make in C, since
they all just devolve into 'int' when they are used.
However, we don't use it for the MS_xyz flag: those are just plain
#define's in the kernel. But maybe somebody at some point wanted to do
something similar for the ones you point at?
The only other reason I can think of is that somebody really wanted to
use an enum for namespace reasons, and then noticed that other people
had used a #define and used "#ifdef XYZ" to check whether it was
available, and then instead of changing the enums to #defines, they
just added the self-defines.
In the kernel we do that "use #define for discoberability" quite a lot
particularly with architecture-specific helper functions. So you migth
have
static inline some_arch_fn(..) ...
#define some_arch_fn some_arch_fn
in an architecture file, and then in generic code we have
#ifndef some_arch_fn
static inline some_arch_fn(.,,) /* generic implemenbtation goes here */
#endif
as a way to avoid extra configuration variables for the "do I have a
special version X?"
There's no way to ask "is the C symbol X available in this scope", so
using the pre-processor for that is as close as you can get.
Linus
----- End forwarded message -----
--
---
Larry McVoy lm at mcvoy.comhttp://www.mcvoy.com/lm
Most of this post is off topic; the conclusion is not.
On the afternoon of Martin Luther King Day, 1990, AT&T's
backbone network slowed to a crawl. The cause: a patch intended
to save time when a switch that had taken itself off line (a
rare, but routine and almost imperceptible event) rejoined the
network. The patch was flawed; a lock should have been taken
one instruction sooner.
Bell Labs had tested the daylights out of the patch by
subjecting a real switch in the lab to tortuously heavy, but
necessarily artificial loads. It may also have been tested on
a switch in the wild before the patch was deployed throughout
the network, but that would not have helped.
The trouble was that a certain sequence of events happening
within milliseconds on calls both ways between two heavily
loaded switches could evoke a ping-pong of the switches leaving
and rejoining the network.
The phenomenon was contagious because of the enhanced odds of a
third switch experiencing the bad sequence with a switch that
was repeatedly taking itself off line. The basic problem (and
a fortiori the contagion) had not been seen in the lab because
the lab had only one of the multimillion-dollar switches to
play with.
The meltdown was embarrassing, to say the least. Yet nobody
ever accused AT&T of idiocy for not first testing on a private
network this feature that was inadvertently "designed to
compromise" switches.
Doug
M6 originated as a porting tool for the Fortran source code
for Stan Brown's Altran language for algebraic computation. M6
itself was originally written in highly portable Fortran.
Arnold asked, "How widespread was the use of macro processors
in high level languages? They were big for assembler, and
PL/1 had a macro language, but I don't know of any other
contemporary languages that had them."
Understanding "contemporary" to mean pre-C, I agree. Cpp,
a particularly trivial macroprocessor, has been heavily used
ever since--even for other languages, e.g. Haskell.
The rumor that Bob Morris invented macros is off the
mark. Macros were in regular use by the time he joined Bell
Labs. He did conceive an interesting "form-letter generator",
called "form", and an accompanying editor "fed". A sort of
cross between macros and Vannevar Bush's hypothetical memex
repository, these were among the earliest Unix programs and
appeared in the manual from v1 through v6.
Off-topic warning: pre-Unix stories follow.
Contrary to an assertion on cat-v.org, I did not invent macros
either. In 1959 Doug Eastwood and I, at the suggestion of
George Mealy, created the macro facility for SAP (SHARE assmbly
program) for the IBM 704. However, the idea was in the air at
the time. In particular, we knew that GE already had macros,
though we knew no details about their syntax or semantics.
There were various attempts in the 1960s to build languages by
macro extension. The approach turned out to entail considerable
social cost: communication barriers arise when everyone
can easily create his own dialect. A case in point: I once
had a bright young mathematician summer employee who wrote
wonderfully concise code by heaping up macro definitions. The
result was inscrutable.
Macros caught on in a big way in the ESS labs at Indian Hill.
With a macro-defined switching language, code builds were
slow. One manager there boasted that his lab made more
thoroughgoing use of computers than other departments and
cited enormous consumption of machine time as evidence.
Steve Johnson recalls corrrectly that there was a set of macros
that turned the assembler into a Lisp compiler. I wrote it
and used it for a theorem-proving project spurred by Martin
Davis. (The project was blown away when Robinson published
the resolution princple.) The compiler did some cute local
optimization, taking account of facts such as Bob Morris's
astute observation that the 704 instruction TNZ (transfer on
nonzero) sets the accumulator to zero.
Doug
Dave Horsfall:
And for those who slagged me off for calling him an idiot, try this quick
quiz: on a scale from utter moron to sheer genius, what do you call
someone who deliberately releases untested software designed to compromise
machines that are not under his administrative control in order to make
some sort of a point?
=====
I'd call that careless and irresponsible. Calling it stupid or
idiotic is, well, a stupid, idiotic simplification that succeeds
in being nasty without showing any understanding of the real problem.
Carelessness and irresponsibility are characteristic of people
in their late teens and early 20s, i.e. Robert's age at the time.
Many of us are overly impressed with our own brilliance at that
age, and even when we take some care (as I think Robert did) we
don't always take enough (as he certainly didn't).
Anyone who claims not to have been at least a bit irresponsible
and careless when young is, in my opinion, not being honest. Some
of my former colleagues at Bell Labs weren't always as careful and
responsible as they should be, even to the point of causing harm
to others. But to their credit, when they screwed up that way they
owned up to having done so, tried to make amends, and tried to do
better in future, just as Robert did. It was just Robert's bad
luck that he screwed up in such a public way and did harm to so
many people.
I save my scorn for those who are long past that age and still
behave irresponsibly and harmfully, like certain high politicians
and certain high-tech executives.
Probably future discussion of this should move to COFF unless it
relates directly to the culture and doings in 1127 or other historic
UNIX places.
Norman Wilson
Toronto ON
Sent to me by someone not on this list; I have no idea whether it's been
mentioned here before.
-- Dave
---------- Forwarded message ----------
To: Dave Horsfall <dave(a)horsfall.org>
Subject: Unix Programmer's Manual, 3rd edition (1973)
Hi Dave,
Some nostalgic soul has shared a PDF on the interwebz:
> MIT CSAIL (@MIT_CSAIL) tweeted at 3:12 am on Mon, Nov 04, 2019:
> #otd in 1971 Bell Labs released the first Unix Programmers Manual.
>
> Download the free PDF here: https://t.co/BYh3dAhaJU
I wonder what became of the first and second editions?
> From: Nemo Nusquam
> One comment .. stated that (s)he worked at The Bell and they wrote it
> "unix" (lower-case) to distinguish it from MULTICS. Anyone care to
> comment on this?
All the original Multics hardcopy documentation I have (both from GE and MIT,
as well as later material from Honeywell) spells it 'Multics'. Conversely, an
original V6 UPM spells it 'UNIX'; I think it switched to 'Unix' around the
time of V7. (I don't know about _really_ early, like on the PDP-7.)
The bit about case to differentiate _might_ be right.
Noel
I may still have AOS 4.3 tape images still around somewhere. I will have
to search around and see if I still have them. Though even if I do, I'm
not sure if the license would permit me to make them available - if I
recall correctly, this wasn't an actual LPP, but there may be some IBM
license on this over and above the Berkeley license. Yes, it did come on
tape cartridges.
--Pat.
Another possible source of inspiration — including the name “worm” — were the publications by John Shoch and Jon Hupp on programs they wrote at Xerox PARC around 1979-1980 and published in 1980 and 1982:
John F. Shoch and Jon Hupp:
The “Worm" Programs — Early Experience with a Distributed Computation.
Xerox SSL-80-3 and IEN 159. May 1980, revised September 1980
http://www.postel.org/ien/pdf/ien159.pdf
John F. Shoch and Jon Hupp:
The “Worm" Programs — Early Experience with a Distributed Computation.
CACM V25 N3 (March 1982)
http://www.eecs.harvard.edu/~margo/cs261/background/shoch.pdf
> On Nov 3, 2019, Paul Winalski <paul.winalski(a)gmail.com> wrote:
>
> On 11/2/19, Warner Losh <imp(a)bsdimp.com <mailto:imp@bsdimp.com>> wrote:
>>
>> the notion of a self propagating thing
>> was quite novel (even if it had been theoretically discussed in many places
>> prior to the worm, and even though others had proven it via slower moving
>> vectors of BBS).
>
> Novel to the Internet community, perhaps, but an idea that dates back
> to the 1960s in IBM mainframe circles. Self-submitting OS/360 JCL
> jobs, which eventually caused a crash by filling the queue files with
> jobs, were well-known in the raised-floor world.
>
>> In hindsight people like to point at it and what a terrible thing it was,
>> but Robert just got there first.
>
> Again, first on the Internet. Back in 1980 I accidentally took down
> DEC's internal engineering network (about 100 nodes, mostly VAX/VMS,
> at the time) with a worm. ...
>
> Robert Morris worked as an intern one summer in DEC's compiler group.
> The Fortran project leader told Morris about my 1980 worm incident.
> So he certainly had heard of the concept before he fashioned his
> UNIX/Internet-based worm a few years later.
>
> -Paul W.
All, the second Unix artifact that I've been waiting to announce has
arrived. This time the LCM+L is announcing it. It's not the booting PDP-7.
So, cast your eyes on https://www.tuhs.org/Archive/Distributions/IBM/370/
Cheers, Warren
P.S Thanks to Stephen Jones for this as well.
Full disclosure: I served as a character witness at Robert Morris's trial.
Before the trial, the judge was quite incredulous that the prosecutor
was pursuing a felony charge and refused to let the trial go forward
without confirmation from the prosecutor's superiors in Washington.
> I'm sure that Bob was proud of his son's accomplishments -- but not
that one.
As Bob ut it, "It {being the father] is not a great career move."
Robert confessed to Bob as soon as he realized the folly of loosing
an exponential, even with a tiny growth rate per generation. I
believe that what brought computers to their knees was the
overwhelming number of attacks, not the cost of cecryption. The
worm did assure that only one copy would be allowed to proceed
at a time.
During high school, Robert worked as a summer employee for Fred
Grampp. He got high marks for finding and correcting an exploit.
> making use of known vulnerabilities
Buffer overflows were known to cause misbehavior, but few people
at the time were conscious that the misbehavior could be controlled.
I do not know whether Berkeley agonized before distributing the
"debug" feature that allowed remote super-user access via sendmail.
But they certainly messed up by not documenting it.
Doug
Hey I'm at the hackers conference (having a blast, I thought I was too
retired and burned out and I'm apparently still somewhat OK with that
crowd, much to my surprise. Super fun bunch of nerds).
Steve Bourne is here and I mentioned this list and he didn't know
about it. His interest perked up a bit when I said Doug and Rob and
Ken are here, I think his comment was something like "if Ken is there
it must be something, Ken likes to do stuff more than talk about stuff".
Probably have that not quite right but it was something like that.
I'd love to have all of the Bell Labs alumni here, hearing history from
them is awesome.
So Warren, it's your list, Steve is srb(a)acm.org, you want to do an invite?
I can do it if you prefer that but I thought I'd ask first.
Cheers,
--lm
Perhaps someone can help me locate a very humorous short
essay from Dick Haight of PWB (I believe Dick was John Mashey's
boss at the time) work in Piscataway. I had a paper copy that Dick
gave me that has long since disappeared in many office moves over
almost 50 years.
*John "Jack" Lossin Adams*
*LinkedIn CV <http://lnkd.in/_Q_w7p>* and on *Facebook
<http://facebook.com/John.Lossin.Adams>*
*If God is your Co-Pilot, you're sitting in the wrong seat!*
Veritas per Scientiam - NJIT motto
*We live at a time when emotions and feelings **count more than **truth,
and there *
*is a vast ignorance of science. - James Lovelock*
*Technology is dominated by two types of people: those who understand what *
*they **do not manage, and those who manage what they do not *
*understand. - Archibald Putt*
*We live in a society exquisitely dependent on science and technology, in
which hardly *
*anyone knows anything about science and technology. - Carl Sagan*
*Only two things are infinite, the universe and human stupidity, *
*and I'm not sure about the former. - Albert Einstein*
-------- Original Message --------
From: Stephen Jones <StephenJo(a)livingcomputers.org>
Sent: 3 November 2019 3:05:31 am AEST
Subject: Re: UNIX-7 boots on sn 129
A couple of videos of the action this week:
https://m.youtube.com/watch?v=pvaPaWyiuLA&t=18shttps://m.youtube.com/watch?v=L5MKwp2uj2k&t=119s
The JK09 turns out not to be an emulator but the newest storage device and driver for the pdp-7 and unix v0!
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
The infamous Morris Worm was released in 1988; making use of known
vulnerabilities in Sendmail/finger/RSH (and weak passwords), it took out a
metric shitload of SUN-3s and 4BSD Vaxen (the author claimed that it was
accidental, but the idiot hadn't tested it on an isolated network first). A
temporary "condom" was discovered by Rich Kulawiec with "mkdir /tmp/sh".
Another fix was to move the C compiler elsewhere.
-- Dave
ISBN 9781695978553, for anyone who wants to know that.
I see it for sale on amazon.com and amazon.ca, paperback, `Independently
published.' Does anyone know if it is likely to appear in bricks-and-mortar
bookshops any time soon?
Norman Wilson
Toronto ON
Robert Clausecker <fuz(a)fuz.su> wrote:
> > I've tried Microport SystemV /386 (SysV R3.2). It uses COFF
> Nice find! It seems to use lcall to selector 7 for system calls. A
> similar choice was made in 386BSD all the way through FreeBSD 2.2.8
> where it was replaced with int $0x80 as in Linux.
Technically speaking
lcall $0x07,$0
uses selector 0 with RPL=3 (bit0 and bit1==1) and LDT (bit2==1)
It seems it's oldest way to call kernel from userspace on x86 architecture.
AT&T's programmers used this sycall convention for SysVR3 and
SysVR4 on i386 (not sure about SysVR2 on i286).
There are very few examples with lcall-type syscall i.e.
http://www.sco.com/developers/devspecs/abi386-4.pdf
(figure 3-26)
(and leaked SysVR4 i386 sources)
William Jolitz used this convention in his amazing articles about
porting BSD4.3 to the i386 (c)1991
http://www.informatica.co.cr/unix-source-code/research/1991/0101.html
(p."System Call Inteface"). See also 386BSD 0.0:
https://github.com/386bsd/386bsd/blob/0.0/arch/i386/i386/locore.s#L361
(Did he run AT&T userspace on his kernel ???)
As you mentioned, most of early *BSD systems on i386 also used lcall.
Linus selected to use "DOS-style" call with INT 0x80.
More recent BSD on i386 also use INT.
https://john-millikin.com/unix-syscallshttp://asm.sourceforge.net/intro/hello.html
Solaris on x86 (ex. SysVR4) also uses lcall. See a
https://www.cs.dartmouth.edu/sergey/cs258/solaris-on-x86.pdf
p.4.2.3
and Solaris (later OpenSolaris and later Illumos) sourcecode.
All, I just received this from Stephen Jones at the LCM+L.
----- Forwarded message from Stephen Jones <StephenJo(a)livingcomputers.org> -----
Subject: UNIX-7 boots on sn 129
Hello Folks .. you’ll hear through official channels along with videos
and pictures (hopefully soon) that we just got PDP-7 UNICS to boot on
a real PDP-7 (sn 129) using our newly designed “JK09” disk drive.
The recent posting of source is going to be great .. we’ve been using
the simh image that has been available for a while.
BTW, compiling the B Hello World on a real 7 is much more satisfying
than it is under simh …
More to come, please watch Living Computers for updates.
(PS sorry we’re late to the BTL party).
Stephen M. Jones
----- End forwarded message -----
