Slashdot Mirror
The 25-Year-Old BSD Bug
sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug.
"This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."
My ass. There are arguments for open source. The shallow bugs argument is not one of them.
Isn't the first entry usually '.'? How often would that be deleted?
...of the superiority of Microsoft.
but they had more important things to do. At least until Balmer started throwing chairs.
After all, someone closed a 25-year bug... how many hidden bugs will remain that way in os/2 warp? windows 95? other proprietary systems?
And sometimes, people who collaborate on a given open-source project are from different parts of the world and not subjected to corporate rules. So when you get creative people with different mindsets and no reason to pull back their punches when they see something wrong, you have quality.
Will we be hearing alot of "How did that get there?" as versions of BSD get patched up?
That is, wouldn't somebody in the past quarter century have exploited this bug to hide a malicious executable file or two?
Not sayin', just wonderin'...
Height: 38U, Weight: 0 Newtons, Eyes: #0000FF, OS: Gray Matter 1.0 (Alpha)
This is the power of Open Source!
With all those eyes looking at the code, stuff like this gets ID'd and fixed LICKITY SPLIT!
(runs and hides)
If you want news from today, you have to come back tomorrow.
Sometimes you need some heavier unit tests just to pick up little bugs like these. Just because everyone assumes code is correct and a few mission critical systems have been working fine on it, doesn't mean some corner case won't blow the world away tomorrow.
It is official. Netcraft now confirms: *BSD is dying Get over it and move on with your lives.....
Bug tracking software missed this because it's bug #1. lol.
The most telling thing in TFA for me was that the bug had been identified by the Samba team and a workaround implemented for Samba.
Surely both the samba communities and the *BSD communities are active enough that this could have been passed on for further investigation by the *BSD crowd? (Sure, samba probably would still need a workaround, particularly given the long uptimes and widespread deployment of *BSDs)
I know nothing of the devs at Samba and *BSD, but seems a bit strange. Perhaps they did try..
Meanwhile, congrats to Marc on fixing a bug. One of the most touted benefits of open source (whatever your license) code.
--Q
If no one has cared enough to fix it for 25 years, I'm guessing this should be rated as "inconsequential."
Must have been a really slow news day at OSNews.
Invenio via vel creo
One would think that after all these years, Windows source would have leaked, Microsoft being what they are. Everyone knows that your most secret secrets are the first things to leak... And yes, I've seen the "secret MS code" joke.
If you want news from today, you have to come back tomorrow.
GNAA Penis Rocket To The Moon Project - $5Million Received! - Our Goal: $1 Billion
Dear friends,
We're getting closer!
http://www.gnaa.us/penis-rocket-to-the-moon-project.html
If you define BSD as a collection of bugs, this story proves that BSD is dying.
--
make install -not war
After all it had survived for 25 years. Are we sure that it really is dead and did not just scurry away when the light was shined on it?
Undetectable Steganography? Yep, there's an app fo
I wonder how it still remained in MacOSX :>
Patents Drive Free Software as Hurricanes Drive Construction Industry
Can Marc look at that file dialog in GNOME? That's been around for a while as well ...
After this long would this not be considered a feature? :)
My Web Site - www.ocean-liners.com
Considering how old this bug is, and how much work-around code probably exists as a result, I wonder how many new bugs this bug fix will create.
What really intrigues me is that this had been discovered, years earlier, by the Samba folk.
Did the Samba folk not tell the BSD folk of the issue?
It is not coincidental that I happened to find this page on stumbleupon hours before it appeared on the slashdot front page. Is there such a grave deficiency of technology news that slashdot has to rely on social bookmarking sites to generate news-worthy material??
3 thoughts on this:
1. I think this bug would be classified "archeological".
2. The question now is what happens to the Samba work-around patches. Now that the bug is fixed, do the patches cause a side-effect (i.e. "a new bug")?
3. This gives rise to a new meme of nerd insults. "You call yourself a programmer? Why I've fixed bugs older than you!" Of course, only one man is entitled to use that line.
I see a lot of people making excuses for this bug not being fixed sooner. If this happened to Windows the comments would be over flowing with "MS SUCKS" and "Switch to Linux/BSD" comments. Yet, when it happens to BSD the comments are more along the line of "this is no big deal..." and "so what... it still got fixed didn't it?"
Hi Kids! Today's word is: Hypocrisy!
I don't disagree that open source is less prone to have bugs that dont get fixed for long periods of time. Nor do I disagree that open source bugs are easier to find fixes for. However... this seems to indicate that the difference between open source and closed source in this regard is not as big as open source proponents have been trying to claim. All the excuses and explanations in the world wont change that this is EXACTLY what open source proponents have been saying wouldn't happen with open source.
...because currently, no Linux bug could possibly be older than roughly 17 years. :-)
What the fuck is slashdot doing popping up "please take a survey" windows on me?
Am I the only one who thinks it's quite impressive to have 25 year old code still being used and employed on new systems?
What?
that's 23 years old.
It's called Windows.
"We live in a global world" - Harvey Pitt, former Securities and Exchange Commission Chairman
Is the MPEG Chroma bug. That was created by someone who wrote one of the original MPEG decoders that was eventually sold/distributed to most of the companies making the first DVD players (pre-1993). This one just won't go away either - initially most of the DVD manufacturers refused to acknowledge it even existed (probably because they didn't want to recall millions of DVD players with non-upgradeable firmware). I still see it every now and then on TV (indicating one of the upstream broadcasting companies is still using equipment afflicted with the bug). I notice it most often when diagonal red lines end up staircased like they're poorly interlaced (see pictures in the above link).
Steve Ballmer responded saying that not only does Windows have older and more easily accessable than BSD, but that it also holds a patent on leaving bugs unpatched for a significant amount of time.
I like the "balmer" tag...
As in "one who balms"?
Or, some Microsoft basher that can't spell?
I don't believe that many in the open source community dogmatically accept the shallow-bugs arguement as a universally applicable rule of software development. It seems to me that any reasonable person would agree that
- Not all eyeballs are equal. Theo and Linus are vastly better at code reviews than the average Slashdot reader, for example. So, there is a wide range of eyeball quality.
- Bugs have a wide distribution of subtlety. The bug in this article seems to be high on the subtlety scale.
- The 'with enough eyes all bugs are shallow' statement is universally recoginized as simplification. For example, ESR states that a better statement is:
So, yes, if you start with the sound bite version of a 'law' and apply it to a statistical anomaly, you can 'disprove' the law. We now agree that the sound bite doesn't perfectly correlate with 'real world' So, you are now forced to decide if the relationship expressed in the 'law' is uncorrelated (bug fixing uncorrelated with eyeballs) , anti-correlated (eyeballs hinder bug fixing) or correlated (eyeballs often help bug fixing). I believe that the law is still a good rule of thumb and that the correlation between 'many eyes' and 'bug get found' is strong.Think global, act loco
I know this... because Tyler knows this
No matter what legacy app you are using. If it is open source, you could fix it, if the bugfix would break it. Or you could pay someone to fix it for you.
The problem is that the stdio directory scanning routines cache multiple directory entries with a single getdirentries() system call, but then may try to 'seek' into the middle of that buffer later on.
Any filesystem based on a non-linear-file directory format, such as a B-Tree, will simply never produce consistent offsets or indices within such a buffer.
The only way to *REALLY* fix this is to add a cookie field to the filesystem-independant dirent structure (and if your BSD isn't using a filesystem-independant dirent structure, it needs to be first fixed to do that). lseek()ing to a directory cookie works just fine, and always will (or at least will far more robustly then trying to scan a re-cached buffer from getdirentries()).
When DragonFly went to a filesystem-independant dirent structure I very stupidly only added ~40 reserved bits to the dirent structure, instead of the 64 we need to properly implement per-entry directory cookies. I'm still pissed at myself for that gaff.
In anycase, a per-entry directory cookie effectively solves the problem. The only other way to get such cookies, if it can't be embedded in the dirent structure, is to create a new system call similar to getdirentries() but which also populates an array of directory cookies. FreeBSD and DragonFly have kernel implementations of readdir which supply per-entry directory cookies so it is really just a matter of creating the new system call and then making libc use it.
-Matt
"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."
Lurch's Corollary: Even after a hundred detailed bug reports have been posted on the official forums, Blizzard still won't fix it.
If you're going to work in Open Source projects related to Operating Systems, stay away. The dreaded "trade secrets" accusation could ruin your whole career.
BSD and the *nixes were designed to be simple, effective, modular operating systems. As long as you have the drivers and know how, you can easily port them over and install them on a variety of hardware. Then, thanks to their modular nature, you can then plug in all the extra bells and whistles you need for your particular system and go to town.
That is why they are still around and still popular. They are K.I.S.S., work as they are supposed to, and the modular code that is plugged into them can just be sloughed away when it becomes out dated, and newer, better code plugged in to modernize the OS as you go.
That's also why Windows has had so many problems over the years. Windows was designed to be everything you need in a single package. That means everything is all tied up together. So, unlike BSD and the *nixes, when part of the OS becomes out dated, MS can't just unplug the old stuff and plug in new stuff. It's all interlinked from the ground up. That means a large portion of development time getting is spent fixing bugs caused by new additions, which then cause even more problems down the line when you go to update again. It also makes it bloated as legacy code ends up stuck in the mix because without it the patched together additions wouldn't function right.
And, unfortunately for MS, their market dominance is based on the windows "feel" being familiar and backwards compatibility. If they could, I'm sure they'd re-write windows from the ground up, but now they are in a catch 22 where doing so might significantly kill their market share.
I'm guessing Bill and company sometimes look back and kick themselves for not having the guts to go for broke and re-do the OS from the ground up for Windows XP. Because, back then MS was still king, Apple was at its low point with a very small and stagnant market share, and the *nixes were still primarily a hard core enthusiast hobby. Today, if MS were to completely change Windows, they'd probably lose a significant amount of market share to a variety of alternatives.
You are who you are, let no one tell you different. But, never close your mind to a new point of view.
This is not the first time the OpenBSD time does an excellent job at finding obscure bugs that were lying around for one or two decades in every BSD derivative. Congratulations !
{{.sig}}
Bugs Slowly Decomposing
that's longer than microsoft!
I am astounded that some people are claiming that this shows OSS does not work, BSD sucks, etc.
Operating Systems are extremely complex and created by man. It is therefore impossible for any of them to be absolutely perfect.
For a bug to be hidden for 25 years (the bug itself and not the symptom), it would have to be obscure and occur only in fringe cases. Well, this bug was obscure and only occurs in fringe cases!
If this were happening in closed source software, the bug would be near the bottom of priorities, since it only occurs under rare conditions. Nobody will bother going to the trouble of analyzing the binary, so to be fixed it would need to be taken seriously by the company behind to closed code.
In this OSS case, it only had to be taken seriously by one talented person.
BSDi and Apple didn't find it. Some person who was empowered with the code being open found it and fixed it. In fact, this fix to Apple's OSX, comes courtesy of the O in OSS.
Proof that OSS works, from one of the oldest OSS bases around. You would expect a bug to be pretty obscure in such old OSS code and that is exactly what this bug is. Is it any wonder that the BSD's are so incredibly stable?
Any chance this bug might be in AIX, HPUX, or Solaris? Just curious. Or did they fix it and not give it back!