31 May
2014
31 May
'14
1:15 p.m.
So it turns out the 'dcheck' distributed with V6 has two (well, three, but
the third one was only a potential problem for me) bugs it.
The first was a fence-post error on a table clearing operation; it could
cause the entry for the last inode of the disk in the constructed table of
directory entry counts to start with a non-zero count when a second disk was
scanned. However, it was only triggered in very specific circumstances:
- A larger disk was listed before a smaller one (either in the command line,
or compiled in)
- The inode on the larger disk corresponding to the last inode on the smaller
one was in use
I can understand how they never ran across this one.
The other one, however, which was an un-initalized variable, should have
bitten them anytime they had more than one disk listed! It caused the
constructed table of directory entry counts to be partially or wholly
(depending on the size of the two disks) blank in all disks after the first
one, causing numerous (bogus) error reports.
(It was also amusing to find an un-used procedure in the source; it looks
like dcheck was written starting with the code for 'icheck' - which explains
the second bug; since the logic in icheck is subtly different, that variable
_is_ set properly in icheck.)
How this bug never bit them I cannot understand - unless they saw it, and
couldn't be bothered to find and fix it!
To me, it's completely amazing to find such a serious bug in such a critical
piece of widely-distributd code! A lesson for archaeologists...
Anyway, a fixed version is here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c
if anyone cares/needs it.
Noel
31 May
31 May
1:23 p.m.
If I understand what you are saying, it only occurs when you run dcheck with mutliple
volumes at one time?
I can't say I EVER did that back in the pre-fsck days.
We did icheck and then dcheck on each disk in sequence.
I don't even think we had a shell script. It was incumbent on the operator to
check each of the system disks and any user volumes that were mounted at the time the
system crash.
Bugs are entirely not uncommon. This is why BSD and JHU and UT had their own
distributions. Having been a V6 UNIX systems programmer at a university back in the
day as we had students who found it an extracurricular activity (nobody took computing
seriously back then) to break security or just plain crash the system. Tons of worse
bugs than dcheck issues.
I actually spent some time before they elevated me to system programmer doing some
exploration in to problems (authorized by the staff).
I decided to test all the setuid programs against vulnerabilities of playing with the file
descriptors before invoking them. I found a half a dozen problems and mailed of the
details before I decided to give up and go home. The next morning our log had a message
about the first eight characters of the system accounting file being corrupted. I told
the guys recovering from that that I might know how that had happened. They said they
figured I would because it was my user name that was found overwritten on the file.
6:58 p.m.
There are bugs to be found, and it can be a fun hunt
(though not too much of a challenge). Here are some
more (security related, as thats my inclination):
http://marc.info/?l=bugtraq&m=108627540130457&w=2
http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html
http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000250.html
Tim
On Sat, May 31, 2014 at 3:15 AM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
So it turns out the 'dcheck' distributed
with V6 has two (well, three, but
the third one was only a potential problem for me) bugs it.
The first was a fence-post error on a table clearing operation; it could
cause the entry for the last inode of the disk in the constructed table of
directory entry counts to start with a non-zero count when a second disk was
scanned. However, it was only triggered in very specific circumstances:
- A larger disk was listed before a smaller one (either in the command line,
or compiled in)
- The inode on the larger disk corresponding to the last inode on the smaller
one was in use
I can understand how they never ran across this one.
The other one, however, which was an un-initalized variable, should have
bitten them anytime they had more than one disk listed! It caused the
constructed table of directory entry counts to be partially or wholly
(depending on the size of the two disks) blank in all disks after the first
one, causing numerous (bogus) error reports.
(It was also amusing to find an un-used procedure in the source; it looks
like dcheck was written starting with the code for 'icheck' - which explains
the second bug; since the logic in icheck is subtly different, that variable
_is_ set properly in icheck.)
How this bug never bit them I cannot understand - unless they saw it, and
couldn't be bothered to find and fix it!
To me, it's completely amazing to find such a serious bug in such a critical
piece of widely-distributd code! A lesson for archaeologists...
Anyway, a fixed version is here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c
if anyone cares/needs it.
Noel
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
--
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com
7:48 p.m.
btw. there is a v6 version of fsck floating around. CMU was still running v6 when Ted
did his OYOC. he later moved it to unix/TS (aka v7) which was the release mechanics out
side of BTL. I'm wonder if I can find a readable copy.
funny I remember the first time fsck saved our butts we had had power failure and
corrupted two file systems on the EE dept 11/34 I was running Icheck/dcheck and the like
trying patch the system and getting it running a gaining. this new grad student (tjk)
says he has something he wanted to try that he wrote over the summer /he had started
writing at michiga. the machine was dead Ted had it on a tape and getting it on to an
rk05 was a trick - we ended up doing it on the IUS system in CS.
once it was running we were in awe man that program migrated to all the CMU pdp11s
within hours
Clem
On May 31, 2014, at 9:15 AM, jnc(a)mercury.lcs.mit.edu
(Noel Chiappa) wrote:
So it turns out the 'dcheck' distributed with V6 has two (well, three, but
the third one was only a potential problem for me) bugs it.
The first was a fence-post error on a table clearing operation; it could
cause the entry for the last inode of the disk in the constructed table of
directory entry counts to start with a non-zero count when a second disk was
scanned. However, it was only triggered in very specific circumstances:
- A larger disk was listed before a smaller one (either in the command line,
or compiled in)
- The inode on the larger disk corresponding to the last inode on the smaller
one was in use
I can understand how they never ran across this one.
The other one, however, which was an un-initalized variable, should have
bitten them anytime they had more than one disk listed! It caused the
constructed table of directory entry counts to be partially or wholly
(depending on the size of the two disks) blank in all disks after the first
one, causing numerous (bogus) error reports.
(It was also amusing to find an un-used procedure in the source; it looks
like dcheck was written starting with the code for 'icheck' - which explains
the second bug; since the logic in icheck is subtly different, that variable
_is_ set properly in icheck.)
How this bug never bit them I cannot understand - unless they saw it, and
couldn't be bothered to find and fix it!
To me, it's completely amazing to find such a serious bug in such a critical
piece of widely-distributd code! A lesson for archaeologists...
Anyway, a fixed version is here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c
if anyone cares/needs it.
Noel
_______________________________________________
TUHS mailing list
TUHS(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3616
days inactive
3616
days old
3 comments
4 participants
participants (4)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu -
Ronald Natalie -
Tim Newsham