Contributed by mk/reverse on from the non-disclosure dept.
Yes | 14.2% (116 votes) | ||
No | 62.5% (511 votes) | ||
Insecure display drivers? Ha! | 23.3% (191 votes) | ||
Total votes: 818
(Comments are closed)
OpenBSD Journal
Contributed by mk/reverse on from the non-disclosure dept.
Yes | 14.2% (116 votes) | ||
No | 62.5% (511 votes) | ||
Insecure display drivers? Ha! | 23.3% (191 votes) | ||
Total votes: 818
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Anonymous Coward (203.122.230.31) on
Comments
By Marcos Carvalho Latas (81.193.132.12) on
You can certainly find equivalent hardware with free drivers (buy only what's free).
Remember the Pentium bug and Thomas Nicely?
That should have warned you.
Comments
By Sean Brown (204.209.209.129) on
Comments
By Anonymous Coward (204.214.120.254) on
by your logic, it should also be in their best interest to release drivers at all. it doesn't work this way.
By Anonymous Coward (151.188.16.16) on
In 1998, a German hacker (in the traditional, not CNN, sense) asked Microsoft in a public forum if there were any backdoors in the newly-released Windows 98. Of course, Microsoft said NO, NO, A THOUSAND TIMES, NO! This hacker, who had reverse-engineered one of the OS binaries, went public with his discovery of...you guessed it, a backdoor. That same week, MS released a "security fix" for a "newly-discovered vulnerability."
Check Point got caught with a backdoor in their FireWall-1 software. One of the guys (former lawyer turned sysadmin) that I worked with at a previous job did some research and called Check Point about what he found. According to Check Point, it was "developer debugging code" which should not have remained in the final product. This "developer debugging code" ended up being a back door...in firewall software! It is also public knowledge that, right about that time, FireWall-1 got pulled off the US Approved Products list for a while. Way too suspicious for me.
Then, there's the Windows 2000 "NSAKEY" business with which Microsoft got caught. Since I don't have access to their source code, I don't, nor will likely ever, know if it was innocent. However, given the Windows 98 and X-Box "let's automatically erase your disk if you put Linux on it" incidents, I wouldn't put it past them. Windows 2000 and XP "phone home" too many times anyway for my taste, and that new "Product Activation" scares me.
Let us also not forget the "RealDownload" incident. This was when someone did a packet sniff on his own box and found out that, contrary to Real's assurances of privacy, RealDownload was secretly sending all sorts of information about his online activities to their servers. This included activity that had nothing to do with Real's servers.
And since you mention Intel, don't forget that they're the ones who came out with that Processor Serial Number business. They *say* that you can turn it off, but the fact that they put it there in the first place is automatically pause for concern in my book.
Still believe companies think it's in their best interests not to spy on us when they think they can get away with it? Examples like the above force me to respectfully, but wholeheartedly, disagree.
Comments
By Sean Brown (204.209.209.129) on
B) A backdoor in OpenBSD after installing one binary driver would be far more trivial to discover. It wasn't there before, now it is therefore it would have to be the driver since you would know what the rest of the system should be doing. You do keep an eye on that right?
That is more what I meant by it would be in their best intrests. Backdoors occur unfortunatly, but they happen when it is difficult to tell if it is doing something it shouldn't. When you have one closed driver or software package on an otherwise well audited and open system, exactly how hard will it be to hide something.
I still think that binary drivers would be a nice option.
Comments
By Anonymous Coward (68.148.237.181) on
Why would binary be more trivial to audit than C source? Why waste the time on binary?
Since others addressed security already, I want to address the freedom aspects - only because nobody else has.
When I buy a piece of hardware, it's mine to do as I wish, not as the vendor's wishes. You'd like the vendor to dictate your freedom - but I don't, like many others here. "Trusted Computing" and DRM, such as product activation per limited use or per install, is slowly becoming the norm; and they don't belong in OpenBSD or any BSD infrastructure.
Thus, here are 2 examples for the need of Free drivers and documented hardware:
"Turning non-Pro Radeon 9500s into Radeon 9700s through hacked drivers"
http://www.neoseeker.com/news/story/2247/
"ATI All-in-Wonder cards and "Macrovision""
http://www.biline.ca/ati_macrovision.htm
Comments
By Sean Brown (68.147.204.149) on
As far as auditing a binary driver goes, I am not saying that it would be easier, I believe it would be much harder. Determining if a driver is doing something it should not however, would not require a full auditing on OpenBSD. The system already is, therefor by default if the system is doing something it should not, the driver is at fault. Assuming that it is the only binary driver on the system, with more then one, you would just have to spend a little more time tracking it down.
Comments
By Anonymous Coward (68.148.237.181) on
If you're willing to drop an OS to make use of your hardware, it's pointless to "ask" for a binary-only option in OpenBSD.
As per driver auditing, I was saying OpenBSD coders shouldn't waste their time auditing closed drivers, and I don't think any of them do. Regardless of the difficulty auditing binary drivers, it's easiest to just drop it - "out of sight, out of mind" as the saying goes.
Comments
By Sean Brown (68.147.204.149) on
However, auditing binary drivers should not be expected of the developers, its not their stuff to maintain. I was saying that the person running the machine would be the one who would have to keep an eye on it since hopefully they would know what their machine should be doing. I think that word would travel quite fast if a driver tried to do something it shouldn't.
By djm@ (203.217.30.86) on
By Matt Van Mater (65.205.28.104) on
I wonder if there might be a sort of compromise where various binary drivers could be listed under a new section in the ports collection with a "Permit_Package_cdrom=no" type of style that does not include it in any future release or house the binary drivers on any ftp mirrors. That way OpenBSD doesn't stray from it's goals of providing non free/open software but the OpenBSD users now have a well-structured way of getting the software they need/want on their own. An added bonus is that it wouldn't be too terribly hard to implement since we can utilize the ports collection's ability to fetch certain software on demand.
I think this is similar to the problems OBSD had with DJB and his non-free licensing where Theo refused to include a port that referrs to software that doesn't allow for third party distribution. If that is the case, then this idea might be dead in the water...
Comments
By Anonymous Coward (129.177.234.103) on
Which political goals exactly?
Comments
By Matt (65.205.28.104) on
Comments
By Anonymous Coward (82.182.103.172) on
Comments
By Anonymous Coward (204.214.120.254) on
i'm not a big fan of fast food or corporate america .. so i'm a big opponent of mcdonalds. should i still eat there every day?
Comments
By Anonymous Coward (213.145.178.123) on
Why?
Comments
By Anonymous Coward (204.214.120.254) on
By Anonymous Coward (69.182.25.166) on
Why?"
Because it employs hundreds of millions of people, has created such evil things as UNIX and the C programming language, and donates billions of dollars to charity every year. Corporate America is a force of pure evil in the world.
Comments
By Anonymous Coward (204.214.120.254) on
By SH (82.182.103.172) on
As an exanple, I just bought a used Intel Server Adapter (10/100MBit) and thought to put it to good use. As it happens, it is a Intel Intelligent Server Adapter that has no open source driver. In addition, the card is EOL by Intel, so even Windows users will have problems. So I've got a card that by all rights should be usable, but now can only function has an ugly paper weight. I'm sure other readers has similar stories to tell.
The OpenBSD's uncompromising stance regarding binary drivers (along with it's corresponding activism) is ladauble. If only the other *BSD and and Linux adopted a similar attitude.
By Eric Radman (205.238.235.23) theman@eradman.com on http://eradman.com
Anybody who's used binary drivers on Linux for some time knows that binary (i.e. proprietary) drivers have a bug-to-feature ratio that server little more than to give us a taste of hell before it's time.
I've used NVIDIA and Cisco software my laptop for two years under Linux 2.4 and 2.6 and I can tell you that it's a pure masochistic exerise. Even the best binary-only modules like VMWare are fragile because the maintainers of individual distributions can't streamline them for their particular set of libraries, configuration, etc.; what you end up with is a lot of hacks that work...sometimes.
The position that the OpenBSD community has historically held over proprietary software is very sensible.
Comments
By Anonymous Coward (192.197.144.229) on
Most other binary drivers suck, because the vendor doesn't care.
By Anonymous Coward (69.182.25.166) on
By tedu (67.127.59.81) on
Comments
By SH (82.182.103.172) on
By Anthony (68.145.111.152) on
Binary blobs for firmware are one thing. Devices already have firmware (or ROMs) that you can't access, so that's not really any different.
But drivers? No. Can't depend on the vendors to fix security problems anything, can't depend on the vendors to fix bugs, can't depend on the vendors to update for a new version, can't depend on the vendors to port it to any other architechtures, etc.
Now... if there were a platform-independant bytecode blob that implemented some standard interface in such a way that it could be used in any OS on any architechture, then we'd be talking. I don't know if that's even possible (Amiga can do it with 68k binary drivers, but that doesn't mean anything about BSD), but if it were I could live with it. Can't speak for Theo on that, but I could live with it.
Thoughts?
Comments
By Anonymous Coward (80.138.155.143) on
By Ian McWilliam (220.240.54.229) on
By Dennis (217.208.157.3) on
By Brad (81.173.18.2) on
Comments
By Anonymous Coward (168.209.98.66) on
By Anonymous Coward (62.227.105.76) on
If a company wants their hardware to be supported, they have to open their specs. Without specs the hardware ist not open, no "open" drivers can be written.
It's quite bizzare that the vendors don't like to use the free marketing potential and labour, that someone actually does work for them for free.
(Yeah yeah, competitors advantage. Damn, they would have to set themself apart by making better hardware...)
I think the project should not part from the "best as possible"-stance.
Binary drivers are bad. You never know whats in it. It's not reviewed code, so not trusted. I like my OpenBSD box stable.
To include binary drivers and not presure the vendors into opening the specs, that allow someone to use the hardware they bought in a realy free sense, would be a setback.
including binary drivers == no/much less incentive for the vendor to start cooperating anymore
By Boris (218.102.177.93) on
It is only recently that hardware allows to have large chunks of embeded code, because of bit-memory chips falled, while size dramatically increased.
In other words, it is only very recently hardware manufacturers
can make software. firmware drivers, bios with tcp/ip stacks, and what not unholy perversions. They're just trying to take over control of software world. the machines are trying to control the matrix.
Those not following the law of supply and demand just fail.
There are no demand for closed firmware. they can keep their crappy microcode undebugged, full of backdoors and what not, to themselves.
By djm@ (203.217.30.86) on
By joes (80.222.205.242) on
By Anonymous Coward (67.64.89.177) on