| Date: | August 16, 2005 / year-entry #227 |
| Tags: | history;when-people-ask-for-security-holes-as-features |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20050816-08/?p=34563 |
| Comments: | 79 |
| Summary: | Probably the single greatest source of bluescreen crashes in Windows XP is buggy device drivers. Since drivers run in kernel mode, there is no higher authority checking what they're doing. If some user-mode code runs amok and corrupts memory, it's just corrupting its own memory. The process eventually crashes, but the system stays up. On the... |
Probably the single greatest source of bluescreen crashes in Windows XP is buggy device drivers. Since drivers run in kernel mode, there is no higher authority checking what they're doing. If some user-mode code runs amok and corrupts memory, it's just corrupting its own memory. The process eventually crashes, but the system stays up. On the other hand, if a driver runs amok and corrupts memory, it's corrupting your system and eventually your machine dies. In acknowledgement of the importance of having high-quality drivers, Windows XP warns you when an uncertified driver is being installed. Which leads to today's topic, a question from a device driver author.
The whole purpose of that dialog is to prevent the situation you desire from happening! [typo fixed 5pm] If you don't want the warning dialog, submit your driver for certification. (For testing purposes, you can sign your drivers with the test root certificate and install the test root certificate before running your setup program. Of course, installing the test root certificate also causes the desktop to read "For test purposes only" as a reminder that your machine is now allowing test-signed drivers to be installed.) Driver writers, of course, find the certification process cumbersome and will do whatever they can to avoid it. Because, of course, if you submit your driver for certification, it might fail! This has led to varying degrees of shenanigans to trick the WHQL team into certifying a driver different from the one you intend to use. My favorite stunt was related to my by a colleague who was installing a video card driver whose setup program displayed a dialog that read, roughly, "After clicking OK, do not touch your keyboard or mouse while we prepare your system." After you click OK, the setup program proceeds to move the mouse programmatically all over the screen, opening the Display control panel, clicking on the Advanced button, clicking through various other configuration dialogs, a flurry of activity for what seems like a half a minute. When faced with a setup program that does this, your natural reaction is to scream, "Aaaiiiiigh!" |
Comments (79)
Comments are closed. |
Woah, I’ve just lost all my hope for the human kind
my thoughts were always that windows should run unsigned drivers in user mode …. like in NT 3.51
Actually, if you define your own device class you will NOT get prompted by the unsigned driver install dialog.
Also, one of the problems of WHQL in my experience is that although you provide an INF file that may list 10 different devices, WHQL will still sign it even if you’ve only provided them with only one of those listed devices.
Even worse, my new Dell laptop came with an usigned bluetooth driver whose setup automatically clicks on the Continue button of the dialogs while installing the driver.
BTW, the WHQL website is awfully hard to navigate, so I can see why small hardware manufacturers are put off.
I have seen these shenanigans as well about a year ago, with the driver for a USB memory key. It would install and auto-push the button on that warning dialog. XP SP2 added a new check for kernel memory pool corruption and guess what? This driver would blue-screen every time the memory key was plugged in.
To me, this kind of software fits into the "grayware" area along with spyware and adware. Attempts to circumvent a user notification like this are malicious, and the result is an unstable system.
Were you hidding under the table at the meeting I was at just the other day?
I work on a wifi product that sometimes is bundled with wifi cards. When packaged like that our installer also installs the wifi card dirver.
Guess what. The suits are all upset about the "unsigned driver" warning, and they are sure that a programmer more clever than me could make them go away.
Of course actually getting the drivers certified is too expensive.
Excuse me while I get back to work on my TPS report.
Were you hidding under the table at the meeting I was at just the other day?
I work on a wifi product that sometimes is bundled with wifi cards. When packaged like that our installer also installs the wifi card dirver.
Guess what. The suits are all upset about the "unsigned driver" warning, and they are sure that a programmer more clever than me could make them go away.
Of course actually getting the drivers certified is too expensive.
Excuse me while I get back to work on my TPS report.
You talk about WHQL like it’s fair and impartial.
Unfortunately, I remember the crap they pulled with 3dfx. Like, for instance, making them write a 2D driver for NT for the Voodoo 1 to WHQL it. A driver they never had any intention of releasing. Or the fact that they were demanding Glide source code (and the ability to do what they want with it) to allow them to distribute an OpenGL ICD, and were holding back WHQL certification to boot. Glide, you may remember, was a direct competitor to D3D back then, and also Microsoft were in undisclosed cahoots with nVidia at the time. I’m not saying this is what killed Glide or 3dfx or anything, I’m just saying it was underhanded.
And some readers may wonder why WHQL is so important? It’s not only because of this box, it’s because OEMs get money back on Windows if they ship with WHQL only hardware. So basically, hardware manufacturers are forced to make concessions on occasion to have nothing to do with the quality of their drivers. Otherwise they’ll never be in a Dell machine.
That’s not to say that WHQL doesn’t have its value, as noted above. But sometimes there’s a nefarious side to it as well that has nothing to do with security or bluescreens.
Bugs me when large vendors like IBM and SAN cards don’t get their drivers verified.
Jack,
Neither side of this game is impartial. Just as you claim WHQL isn’t playing fair, I can tell you that sometimes (mostly) the OEM (and other hardware makers) are out to cut corners and make money.
I still remember one of Linksys’s Wireless B PCMCIA cards. I went to install the driver, the instructions actually said something to the tune of "Ignore this warning box, it doesn’t mean anything important. Continue clicking OK on every screen until the driver finishes installing." Hell I could have put a box in that said "Click here to format your hard drive" and I’m sure some end users would have clicked OK. Cisco is a huge company, surely the WHQL payment isn’t much to them.
WHQL is there because it assures drivers are stable. Why? Because when the BSOD comes most end users don’t say "Oh my unsigned driver has corrupted memory in Kernal mode." They say "Stupid Windows, always crashing, Macs never crash." WHQL helps make windows look good, because that’s all alot of end users see the computer as, "Windows."
Heh, I’ve spent a lot of time attempting to explain why we couldn’t "brand" the dialogs that pop up in the browser before the user installs a signed control…
WHQL helps make windows look good, because that’s all alot of end users see the computer as, "Windows."
———
Well, if that’s the case, then it sounds like Microsoft is the true beneficiary of WHQL. So why should the hardware vendors have to foot the expensive bill?
Problem with WHQL from my perspective is that it imposes requirements that aren’t related to system reliability. Sometimes these are impossible to meet, depending on the hardware.
Judging by the number of comments here, I’d say WHQL is more a thorn in the side of developers than it probably needs to be.
What really bugs me is when you get a blue screen and all crash analysis says is that it was "caused by a device driver". Since there are 30 or 40 on the machine that makes it really hard to work out who to blame. I would instantly replace their hardware.
I would have assumed that memory allocations, PCI reservations, DMAs etc would be at least tagged with the driver class (eg video driver resources would be different than USB serial port drivers).
The reason it only says, "caused by a device driver" is because all device drivers run in the same memory space, so my video card driver could be dancing all over your ethernet driver memory.
Making WHQL certification free would certainly encourage a lot more vendors to certify their drivers, but it would also causes a lot of vendors to just sumbit crap to the WHQL without testing it themselves first.
WHQLs job is to stop support calls, to stop MS getting the blame for BSOD events. And they are mostly good at it. The fact that most stuff just plugs and plays is down to them…try getting the miscellaneous bits of a laptop to work on linux to see what their absence brings.
But systems still BSOD, and we, the end users, get to stare at the screen. And that happens even if the stuff gets certified, because there are so many system combinations out there, so many OS patches, so many machine states -and only one pointer error in a driver toasts your box. Furthermore, driver vendors get no respect. Nobody reviews a graphics card saying "its a junk card but the driver folk have made it almost workable". No bad drivers get blame, good drivers get silence. Whereas a bit of instability in an app is par for the course, what with crash-recovery built into things like Word.
What WHQL could be done is making more of the posted crash failure statistics public. Why cant we see which display driver causes the most failures? Or which bluetooth dongles are the flakiest? Or whose DVD-RW software should we avoid? MS fault reporting must know these facts…
My guess is that if you have the capital to get your hardware manufactured and your device drivers working at all, the monetary cost of WHQL will not be the deterrent to getting your drivers certified. Making your hardware available to vendors like Dell would surely make up for that.
What will be a deterrent is the kind of story Jack Matthews told. Demanding unrestricted license to the source code? Refusing to grant certification to a company because they make software that competes with Micorosft? Those are real deterrents. Sure, some of them just want to cut corners and release unstable garbage, but many of them are probably scared off by the prospect of submitting their code to a hostile and aggressive company who just might see them as a threat. Better to just tell the users to ignore the warning in the instruction manual.
(tsrbike: the fact that some hardware manufacturers are cheapskates who want to get away with releasing crap has no bearing on how Microsoft treats the good ones.)
I do agree that people who make setup programs that programmatically move the mouse in an attempt to bypass the confirmation dialog should be hit on the head a few times…fortunately those seem to be relatively rare.
And oh yeah: for full disclosure’s sake, I should note that I personally have no idea if Jack’s story is true. I just have no reason to disbelieve it, and Microsoft has demonstrated time and again its willingness to behave that way.
So much going on…..Had a week and a half of vacation which was nice. It was nice to get back to see…
How about if I get to certify my own drivers… then if a user accepts my signing certificate as trustworthy, they can install any of my drivers without further prompts.
A barrier to entry is a barrier to entry. The signing requirement and the requirement that potential clients of error reporting obtain a cert from VeriSigh cost third party companies money and thereby cause them to stay out of markets they could have entered, and consequently LOWER the quality of components available to users by decreasing competition.
Microsoft would best level the playing field by displaying the signature box of a signed driver. Thus the user would be required to view a dialog box for ANY driver. Further, Microsoft should allow orgs that are peers of WHQL certify drivers and allow drivers to obtain certs from any such org or set of such orgs as they choose. Over time users would know which orgs were on the ball and which had agendas.
I remember the matrox millenium driver (I think) installation under Win95 clicking all the display properties buttons to install the driver, but at the time I was under the impression this was because updating the video driver was pretty complicated for normal people, having to go to the display properties, last tab, Have Driver, etc..
At a company I used to work for they had found away around that dialog box. They would silently launch the System Properties / Driver Signing Options dialog, send windows messages to select "Ignore" and then click ok, effectively turning off the dialog box (BTW, the code to re-enable the setting was commented out, so the installer made your machine less secure forever — great stuff coming from a security company).
When it came time for me to release my device driver they insisted that I use this "Top Secret" functionality to get rid of the unsigned driver dialog box. I flatly refused. It took a lot of fighting, but I pretty much said "I will not do it, ever."
Yes, I realize that resources (memory, dma, irq etc) are shared amongst all device drivers. However it should be possible to do a better job of pointing fingers. For non-memory related issues, you can track which driver reserved the resource. For memory related stuff, you can tag allocations with who made them.
In many cases just narrowing to the class of device would be more than enough for me.
I like the spirit of WHQL, the main thing I don’t like about it pertains to the barrier it causes. If I am a small startup, the cost in terms of time and resources to WHQL my driver could be a barrier to me putting out my product.
Additionally, if you do have a new device class or something very different from what WHQL is expecting, there is an additional level of pain that you have to go through.
In other words, I feel that in certain cases, WHQL is a barrier to innovation.
Not to mention the whole idea of MSFT playing big brother regardless of the benefit is also an issue. If it is really necessary, then an independent 3rd party should WHQL certify where Microsoft would have to undergo the exact same requirements and not be able to make exceptions for their own code.
I’m guessing that "your" was meant to be "you":
The whole purpose of that dialog is to prevent the situation your desire from happening!
Otherwise, interesting article. Thanks for taking the time out to write up stuff every weekday.
How much does the WHQL thing cost?
sorry Raymond but this qualifies as your lamest argument ever. Considering the usual high quality I say this one is in a category of itself.
Disclaimer: I am a user, never worked in a hardware vendor nor in software/driver related company.
Your argument can be summed thus: "In order to make sure your computer is more stable Microsoft is making the hardware more expensive." All this certification cost is passed back to the consumer of the hardware.
WHQL is a monopoly and the worst of it. Arrogant, anti-competitive, expensive, buearacratic.
Remember AT&T and proprietary phones?
"In order to make sure your computer is more stable Microsoft is making the hardware more expensive."
When a hardware vendor makes a crappy driver and foists it off on users, they are just shifting costs from themselves to their users. Instead of selling the product for $40, they sell it for $30 and let the user spin the Wheel of Misfortune. Maybe their users will be lucky and only have an occasional crash. Or maybe the users will lose thousands of dollars worth of valuable data. Thank goodness breaking the little seal on the driver CD absolves the vendor of any responsibilty for that.
But tekumse, certification isn’t required. Anyone can install drivers that aren’t certified. And anyone can write drivers that aren’t certified. The point is that they’re going to get a warning letting them know that anything can happen.
Yep, anything can still happen, even with signed drivers. It’s impossible to fully test any significant piece of software, including drivers.
(The complexity of the DDK interfaces doesn’t help with that either, but that’s a separate issue.)
WHQL signing is at best a statement saying "Microsoft’s testing team couldn’t get this to fail". Which is, fundamentally, not worth a whole lot.
Does Windows let users install certs from other driver certification organisations? It seems to me that I should be given the option to trust Joe Random Driver Certification Company if I want to. More likely, though, is that a system vendor will do its own testing on hardware for systems it ships and would thus be able to sign the drivers for the devices in the system themselves and install their certificates on systems that they sell.
I think it’s Microsoft being the centralized authority that makes most people balk at this certification business. For many people there are other orgnisations that they would trust just as much or moreso than Microsoft to certify drivers, and buying a system from a company implies trust in them I think. (after all, there’s nothing to stop them doing the driver installation before you get the system, so you’d never see the signing dialog unless you did a reinstall.)
Chris suggested that a price reduction to $1000 would make the WHQL program more popular. In fact, it costs only $250:
http://www.microsoft.com/whdc/whql/policies/testing.mspx
Which suggests that price isn’t the reason for unsigned drivers.
Ben: The problem with that is that a dodgy hardware vendor could just create an installer that installs their own certificate, then installs the now trusted signed driver, completely negating the signing process.
Installers that bypass these kind of checks by sending Windows messages really need to be stopped though. There should be some way of preventing automation of system dialogs like this. I appreciate that’s not easy though.
Take this situation:
Video driver has a random pointer and writes to memory owned by someone else.
Audio driver has a perfectly valid pointer that just got badly corrupted. It writes to that and BSODs. The error message says ‘Audio driver was running and it just crashed.’
Clearly this is not the fault of the audio driver but they’ll be getting the support calls. Or, more likely, several different drivers will be blamed on different systems and at different times.
Reporting information that is likely to be inaccurate is a bad idea.
I thought you were only required to submit source code if you wanted your driver to be shipped "in the box" with Windows. If you just want to have people install it off a CD with some hardware or download it then you only need to submit the binary for testing.
Looking at Vista it seems the final version will refuse to install ANY drivers that are not signed. The beta only lets things through because there are not enough signed drivers around for all the available hardware. Perhaps that is only for Graphics drivers.
Also doesn’t Vista have a seperate secure desktop that is used for the InfoCard properties? By making the driver secutiry dialogs use that environment you would prevent any manipulation via window messages.
Many of these bypassing tricks could be avoided by having the driver install confirm messages appear in a separate window station, similar to the trick used with screen savers and the Ctrl+Alt+Del dialog to stop running applications from messing with them. It would mean that the user would be unable to interact with the desktop while the dialog is displayed, but I think that’s a small price to pay, especially since driver installation is something that one (hopefully) does pretty infrequently.
The whole driver install process doesn’t need to be done like this, but the message whining about a driver not being signed certainly does, as would a theoretical dialog for installing new driver certificates, which should be full of lots of big red warnings telling users that it’s probably a bad idea.
I remember reading, though, that it’s not uncommon for driver installers to simply shove the relevant entries into the registry directly without going through the driver install APIs. There’s little that can be done about this except to place access controls on the relevant parts of the registry which the real driver installer can bypass. Perhaps recent versions of Windows do this already; I’ve not really ever checked. :)
It’s a shame that drivers are now often provided in installer packages. I much preferred it when drivers were installed through the Add Hardware interface based on a completely declarative install script, thus restricting what could happen at driver install.
I’ve thought for a while now, in fact, that all software installation under Windows should be based on declarative scripts (describing what needs to be done) run through a standardized installer rather than through executables. It would then allow the standardized installer to impose rules on software installation rather than simply having conventions, and force prompts where the installer wants to do something a little iffy such as writing to the Windows directory. Of course, it’s too late for all that now, and there’s not really any way to stop vendors shipping installer applications anyway since the system can’t distinguish between a setup program and an actual application.
Declarative deployment is the best way to deploy things. .MSI tried to do this but added a "custom" feature that got hacked into by every installer tool vendor, so the declarative stuff got completely ignored.
i actually work on distributed system deployment by day, and it is things that dont clean up that cause the most trouble. Drivers may cause bluescreens, but it is normally apps that get your system into such a complete mess that "rebuild time" is your only option. This is why vmware/vpc and xen are so cool. you can clone system images, install something for single use and then delete the disk image after use. nice. its a wonderful future, and it also blows away so much app activation protection that stuff is doomed too. why worry about WGA when entire vm images can be shared?
<i>I remember reading, though, that it’s not uncommon for driver installers to simply shove the relevant entries into the registry directly without going through the driver install APIs. There’s little that can be done about this except to place access controls on the relevant parts of the registry which the real driver installer can bypass. Perhaps recent versions of Windows do this already; I’ve not really ever checked. :) </i>
I believe you’re correct Ben, I have worked for a company that produced a driver that did exactly that. Digital signatures were the last thing on their mind because WHQL submission would have introduced an external dependency into the almighty schedule.
Right up to and including Windows Server 2003, the registry entries required you refer to were accessible only by administrative users, but not solely through the driver installation APIs . We never had the problem of a warning dialog being shown during installation.
So the majority of vendors hate enough WHQL program to create all kinds of crazy hacks and I’m sure some of those using it are not trilled about it and the problem is with them??? Now that’s arrogance.
What happened to Raymond who thought that if something doesn’t work the way most people expect it then it is broken?
I *love* Steve’s idea. Seeing crash statistics would help me make a more informed choice. There are pitfalls that would need to be worked out (e.g. a particular device might show a lot of crashes simply because it’s very popular and therefore in a lot of systems) but there is certainly some potential there.
So how do you explain when WHQL drivers hang, lock up and generally destroy my machine? Yes, nVidia, ATI, Microsoft, and many other companies are to blame. WHQL is just Microsoft’s way of steering the market in its own whims. Guess what for Vista? You won’t be allowed to install non-WHQL drivers. You’ll be required to go through WGA just to install drivers. Your hardware will be buried under layers of DRM which decides how you get to use the hardware you paid for. You don’t own your PC, Microsoft does.
Raymond,
Interesting post. However, I think we need to be fair here and say part of the problem is the fact WHQL doesn’t HAVE a certification program for all driver types out there. I have a few kernelmode drivers that I wrote, some requiring consent dialogs (NDIS and TDI style network filters) and one that does not (an IFS filter). When I approached Microsoft for certification and went through the process, it was found that WHQL doesn’t currently have a category and cannot therefore issue a set of tests against the drivers. We can’t even go through the process of being tested, never mind getting the driver signed or get the WHQL badge.
If Microsoft wants to sign only drivers that have passed testing in the WHQL lab, I am for it. But they need to have the resources and the test plans to avail itself so developers that leverage the DDK can go end to end with the process. Currently, thats not possible… making it a suspect process for many driver developers out there. I run all our code through the IOStress and the HCT test kits (with and without Driver Verifier on), as well as use tools like prefast and static driver verifier as part of our build process. However, we can’t leverage the rest of WQHL’s offering because it doesn’t yet exist. And when Vista is released, it will start getting harder to handle this with customers. We take pride in our development and testing process… yet show up as unprofessional as we have unsigned drivers. Yet there is nothing we can do about it.
Give us an alternative to comply with the driver signing. I don’t mind going through the process… but you leave people to dumb hacks to make the installation process easy and professional to customers when you don’t give an option.
Chris comments: >> How much does WHQL cost? As someone pointed out, if WHQL was free, hardware vendors would submit crappy code and let WHQL QA it. <<
Microsoft does not perform the actual testing of the driver. The hardware vendor obtains the test suite (a free download, I believe), and runs the test on their own – fixing problems identified by the test suite.
Once the driver passes test suite, a log that is encrypted by the test suite is sent to WHQL – that is what is used by MS to verify the driver has passed the tests.
So the costs bourne by the hardware vendor are $250 per submission and the cost of the Verisign certificate. I’m sure that for most vendors the main concern is actually performing the work and the schedule impact (note that any updates to the driver need to go throught the same process if they are going to be signed).
I wish I had a good way to describe the immense difficulty of coding quality device drivers that are, fast, useful, stable, interop-friendly, and cheap. (After all, the companies want to make money as well.)
It’s just not as easy as anyone ever imagines. People have wonderful ideas as to how to fix things, but actually implementing them would be painful, if not impossible. I know that Raymond’s regular audience tends to be a more Win32 oriented community than a driver writing one, so I’ll say this:
Go out, get the DDK, and start writing drivers. See how demanding it is, and how difficult quality is to control. In user mode, a bug is a crash. You stop, debug it, change things up, and keep going. Even THIS process, in kernel mode, can be painful.
If writing Win32 code in C is running with scissors, writing a kernel mode device driver in C is riding around in a concert on a chipper/shredder. You’re probably going to get hurt, and some people are gonna die.
Before you go and quote "but other platforms!" at me, remember that Windows has a far wider range of drivers written for it than any other platform, a good number of which are perfectly stable. This is the ENTIRE point of the WHQL program, to get those marginal drivers to a minimum level of quality. NOT to ensure they are perfect.
I was getting blue screens from a buggy MICROSOFT driver (for a netgear cardbus adapter). Installing the *unsigned* vendor provided driver made it work correctly.
How much does WHQL cost? As someone pointed out, if WHQL was free, hardware vendors would submit crappy code and let WHQL QA it. Bad drivers make Microsoft look bad, so Microsoft should make WHQL very easy, but still provide a minor inconvenience *to PHBs*! Most programmers want to write good code. I bet most hardware vendors avoid WHQL because of cost-averse PHBs. If Microsoft charged (say) just $1000, then PHBs would reluctantly give in but insist that programmers write good code to avoid unnecessary resubmission to WHQL.
Carlos,
I hope you’re wrong about not being able to insall unsigned drivers in Vista. Sounds like a really consumer-unfriendly approach. I definitely don’t want to be in a world where only drivers Microsoft approves can be installed.
"I was getting blue screens from a buggy MICROSOFT driver (for a netgear cardbus adapter). Installing the *unsigned* vendor provided driver made it work correctly. "
About two years ago, for some of their wireless junk, Netgear put out incompatible versions of the hardware that had the SAME Plug and Play ID. So, if you let Windows auto-detect the hardware and install the driver based on the PnP ID it would sometimes install the wrong driver. One of the cardinal rules of PnP is NEVER give the same ID to two different pieces of hardware.
Haven’t you noticed this is exactly the way the world (or Microsoft’s world) is going? It won’t be too much longer before ALL software has to be approved by Microsoft before it can be installed…
many years have passed since introduction of bluetooth, and yet WHQL bluetooth certification does allow ONLY a limited number of profiles.
if you, as a manufacturer, try to provide all the bluetooth profiles (specific examples: bluetooth audio gateway, bluetooth network card (not dialup adapter)), you do not receive WHQL! which means that *ALL* the bluetooth device drivers used in *ALL* major laptops (ibm/lenovo,dell,etc) are unsigned!!!!! (and consequently are using various schemes to bypass the warning dialog message).
as another user said here, WHQL has become yet another monopolistic arrogant, anti-competitive, buearacratic tool. it has become useless for users. fortunately it is quite easy to circumvent.
I don’t think all the comments about WHQL being arrogant, monopolistic, etc, are fair. They exist to try being a measure of stability and repeatability, to all the random drivers out there. On the other hand, they’re out of date; before the internet, when drivers were only released once on in long increments, it would make sense, but now updates are released weekly or monthly in many cases, to correct minor bugs and occasionally add features, requiring a costly resubmission for each. And of course new product categories that aren’t really new anymore really do need to be dealt with.
Maybe if once a driver passed, updates that passed the suite could be signed for free.
On the other hand, I wish some companies would keep their printer drivers stable, since terminal services requires exactly the same driver on each end. (Or at least a print processor that can decode its print driver’s stream, which Brother changes every update.)
I doubt vista will ship requiring driver verification, the companies will revolt.
I cannot comment on whether WHQL is a monopolistic practice, on whether WHQL testing is really thorough…
What I can say is: back when I used Win 95 OSR 2 I used to face various BSoDs that were apparently rooted in drivers and VxDs. I now run Win XP SP2, and the only time I saw a blue screen was when I removed my wallpaper [really lame joke, I know :)]
One thing I ensured while setting up my current box was to use only signed drivers. Maybe that helped, maybe its just XP SP2 that’s more stable… but what matters is that I’m happy.
The current WHQL may not be the ideal process, but I see good (IMHO) ideas being put out. Hope someone on the WHQL team is going through this blog.
I am really beginning to wish that Windows would really lock down what installation apps (and apps in general) can do to a system.
I really wish that I simply didn’t have the rights to write to certain directories or read/write certain registry keys. Because when management comes and asks me if I can do something, I have to answer that technically I can. Even though I feel that the behaviour in question is dodgey as all hell.
[1] Crap hardware, bcos it’s cheaper to buy parts.
[2] Crap code, bcos good coders ask for too much money.
[1] + [2] ==> BSOD
News at 11!!!
Signed drivers I can see the point of.
However some MS security features are a pain in the ass for seemingly little benefit.
For example I do some development in C# for an application at my workplace. In the past executables from VB and C++ are run from a network share. Now the CLR fails to run CLR exes because the assembly needs to be specially signed or full access allowed to local intranet zone.
So now I would have to visit every PC and change the .net Configuration.
"Reporting information that is likely to be inaccurate is a bad idea."
Try telling that to whoever wrote the Add/Remove Programs app… :)
I’m just a dumb end-user so I’ll list my concerns:
* It seems that circumventing the safety mechanisms is too easy, security related dialogs should be made so that only already installer drivers (mouse) can access them.
* Automation of things should not be possible through hacky approaches.
* Maybe it will be in future processors possible to have each driver in their own space or such that it is easier to know what driver causes crash.
* Having a similar, perfected installer for all applications and drivers would be good. Companies can then do minor customizations to this by specifying audio,text,video or 3D graphics to be displayed during the install. Current installer companies can go to * since most of the install programs are mediocre and over-size and slow etc at best.
* Windows should have a mechanism to split files somehow – I imagine having single downloadable installer image. When executed the image (suppose it is 3 GB in size, a huge game), provided that it is run on the destination drive of the install, could just split itself to the files inside of it without any copying processes involved. So download a huge file to C: then run it and it will split into many files which are then moved to appropriate places. 1 second install! Patent pending soon!
To anyone above who wrote "I have all WHQL drivers installed and my machine still is buggy!"
Please read exactly what Raymond has said.
Then, re-read it. Go ahead and give it a third time.
He said that systems can be unstable and BSOD because hardware manufacturers are using two code paths: one for the WHQL tests that work perfectly and get approved, then use triggers and flag th have it run a completely different path on the end user’s machines from the same binary that the WHQL tested.
And before you start MS bashing, think to yourself… and be honest… ever had a kernel panic because of a dodgy driver in Linux?
The uncertified driver warning is just an annoyance. Only an out-of-touch geek would think that it is a security feature.
Here is what normal people see. Hell, it’s what I see, since I don’t spend 10 minutes contemplating every damn dialog you throw at me:
Blah blah blah blah
Technobabble technobabble blah blah
Blah blah blah blah
Blah blah blah blah
Blah blah blah blah
[Some button] [Some other button]
If I pause and concentrate, I can probably figure out the implications one way or the other.
There is no way my Dad can figure it out. He just wants his device to work, and so he will press the default button. If that doesn’t work, he will run the installer again and press the other button. What the hell did you think a normal, non-geek person would do?
Well, Nate, if Microsoft changed the dialog to say:
Warning! Your hardware manufacturer hasn’t bothered to test this driver!
Do you feel lucky?
Yes No
Quite a few people would be annoyed. So they have to change the dialog.
All I know is that, should Longhorn, I mean Vista refuse unsigned drivers outright, I won’t be buying it. Windows isn’t the only game in town.
Oh, this is just awesome. Microsoft requires a certification program for drivers and it’s called "monopolistic, anti-competitive and arrogant." When Sun, IBM or some OSS foundation does the exact same thing, it’s called "open, trust, competitive, standardization and quality." MS-bashers, get a clue, please.
Well, after reading most of the comments on this topic I figured I would voice up my opinion having to constantly deal with this issue. First, a little background. I work for a company that manufacutres automotive diagnostic equipment.
Our tool plugs in (via USB) to a Windows PC and interfaces with the car. The USB chip in our device is a standard, off-the-shelf component with a driver that has passed WHQL. We don’t even have the source code for this driver. Now, the certified driver we’ve seen cause BSOD’s and hung IRP’s. But only in very odd situations, so I can understand WHQL missing it.
However, for our product we take this driver, modifiy the VID & PID in the INI file and then that dialog box comes up. Now, our customers are auto mechanics who get very, very scared by that dialog box. We’ve lost a few customers who returned the thing and couldn’t even install the driver.
Despite us manufacturing our own hardware we are just not able to pay for WHQL certification every time our vendor (FTDI) comes out with a new driver. I understand why the warning is there and would prefer that it be kept. But I wish that WHQL costs could be reduced.
-Mark
zzz:
<<<
* Windows should have a mechanism to split files somehow – I imagine having single downloadable installer image. When executed the image (suppose it is 3 GB in size, a huge game), provided that it is run on the destination drive of the install, could just split itself to the files inside of it without any copying processes involved. So download a huge file to C: then run it and it will split into many files which are then moved to appropriate places. 1 second install! Patent pending soon!
>>>
This is exactly how installers have worked for many years, to a greater or lesser extent. I’m not sure what’s new here. The reason installations are slow even though all they are is splitting a zip (if that), it because disk reading and writing speed is a huge bottleneck.
Your other statement pretty much describes MSI and recent versions of InstallShield.
solution: revisit the NT microkernel design. Move device drivers from kernel mode to user mode. Crappy device drivers crash themselves, not the entire OS. I’ve read that Longhorn/Vista is introducing support for user-mode device drivers.
Scenario 1
"How should we deal with bad device drivers?"
"I know! Let’s put up a dialog forcing the user to acknowledge that the device driver might be bad. Then it will be *their* fault if it fails!"
—-
Scenario 2
"How should we deal with bad device drivers?"
"I know! Let’s warn the user. Then, when they see the warning they can either drive back to the store to return the product, or call the manufacturer and ask them for a certified driver. Since most computer stores and all manufacturers are responsive to customer needs, they will *certainly* either refund their money and suggest a certified replacement, or quickly re-write their driver and certify it. And since all users are rational, they would never install the un-certified driver."
"And these steps won’t be inconvenient at all compared to clicking the ‘Continue’ button!"
I’m an MS-basher (well, I am in this thread, but not always), and I think that if having certified drivers is so all-fired important, then Windows should refuse to install them. Correspondingly, make the certification process free or low-cost.
Another alternative would be to refuse to install non-certified drivers for devices that Windows already supports. Then, discourage IHVs from writing drivers and focus on increasing Windows’ built-in support for devices. The world doesn’t need another mouse driver, another printer port monitor, or for gobsake, an OEM driver for a USB memory stick!
Another alternative would be for Microsoft to build the PCs, using only hardware they approved of. Don’t support anything else. Or require PC makers to certify their designs, using only approved devices. *
Anything is better than dumping the problem on the user’s lap.
* This isn’t as far fetched as it seems. Microsoft is doing it already with the X-Box and, to a lesser degreee, with HPCs and HTPCs. Apple has done it forever.
You can’t just run arbitrary drivers in user mode because some need direct hardware access. Anything that can access hardware can crash your machine, so it almost doesn’t matter if its memory is protected because the whole rest of the machine is open for abuse. Why pay the massive price of separate address spaces (mapping, copying, TLB flushes, cache misses) if it isn’t even going to solve your problem?
On the other hand, many drivers don’t need to access hardware, and they may be able to run from user mode (see user mode WDF). There’s no reason my USB CF reader’s driver should be able to bring down my machine, but there is definitely a perf hit for making all those user<->kernel transitions.
Based on the fact the posts calling WHQL a monopolistic manifestation of Big Brother and a seemingly equal number suggesting that it be more draconian, I would suggest that MS is doing a good job.
Yes, user-space device drivers. Perhaps that should be "re-introduce" user-space drivers :-) I believe NT3.51 worked that way. NT4 went back to ring0 drivers because it made it a lousy games platform.
It’s true – a driver can crash your PC by doing bad stuff to DMA, PCI bus control, USB controller etc. But I bet most BSODs come from good old-fashioned memory treading (re-use freed block, buffer overflow. stack corruption), so user-space running would catch, what, 70% of buggy driver failures?
You could also perhaps reduce the severity of the warning for user-space drivers, so that the user would be less frightened, and the 1-man shops (who probably do USB stuff mostly anyway) can sell product without involving Microsoft.
It was only GDI and the Window Manager that were in usermode before NT4. The drivers that talk to the actual hardware have always been kernel mode.
http://www.microsoft.com/technet/archive/ntwrkstn/evaluate/featfunc/kernelwp.mspx
Many of the things people are asking for are available/coming in "Longhorn".
A new device driver installation architecture, unified user mode and kernel mode device driver model, and WHQL certification for non-standard device classes. There’s also a future goal of kernel mode driver isolation (not sure how far along this work is — probably beyond "Longhorn") so that even faults in kernel mode drivers are recoverable.
Device Installation Rules for Windows Longhorn
http://www.microsoft.com/whdc/driver/install/InstallRules.mspx
Windows Driver Foundation
http://www.microsoft.com/whdc/driver/wdf/default.mspx
Windows Vista Driver Development
http://www.microsoft.com/whdc/driver/wdk/default.mspx
Windows Vista Logo Program
http://www.microsoft.com/whdc/winlogo/LH_logo.mspx
The Driver Quality Signature Program (for devices that don’t fit established MS Logo programs)
http://www.microsoft.com/whdc/winlogo/drvsign/dqs.mspx
Of course people aren’t actually asking for a security hole… the security hole already exists and Raymond more or less admits that.
As to the "drivers crash.. bad" part of this argument, Microsoft isn’t doing half of what they ought to do from an engineering point of view if that was the focus. WHQL provides a barrier to entry targetted at Microsoft’s worst fears ($250 doesn’t keep out IBM but it does keep out Joe Blow), another excuse to drive developers through the "just buy one more certificate" milking process, and as an added bonus a way to get first look at new things coming down the pipeline (remember Microsoft is also a hardware company – they’re asking people to send potentially valuable information to their direct competitor – uh, right)
If Microsoft wanted to improve reliability and device driver quality, and if they wanted the user to help drive this improvement to the right people, then they would…
* Let the vendor install a cert chain (buy IBM, get an IBM cert, all IBM drivers are authorised, let IBM take the heat when it breaks).
* Give away the middle layer. Windows device drivers do too much work, adding complexity where the system is at its most vulnerable. Microsoft has a software RAID solution that’s useable. But that solution isn’t included in every Windows (for market segmentation reasons, ie marketing overides engineering) so a zillion users have "upgraded" with a 3rd party driver. There are dozens of other examples where Microsoft has or could quickly develop 90% of the code in 3rd party drivers and could provide a service layer to those drivers eliminating the bulk of their code. Less code => Less bugs.
* Push drivers into userspace. There is no reason why a bug in the driver for my fancy USB mouse should kill Windows. If developers are finding it easier to make that fancy driver run with excess privileges, work with them to reverse the trend. If they’re doing it out of habit, find ways to break the habit. Most machines ought to have less than half a dozen hardware-specific (and thus provided by 3rd parties) kernel drivers but on Windows it’s commonly many times more.
# Disk controller
# Sound
# Graphics
# Network
# Video in (e.g. webcam, DVB)
Gee, there do seem to be a LOT more 3rd party files than can be explained by that loaded into the NT kernel. WHQL isn’t fixing that, with or without an "Install anyway" dialog. If Raymond wants to address driver quality and improve Windows security in the bargain, here’s a suggested title
"Why you shouldn’t write a (kernel) driver"
On the issue of having Vista not allow the installation of drivers that have not been accepted by MS (assuming this is the case), I personally feel that this is too much power. It allows one company to render the products of other companies literally useless. These companies are sometimes competing with MS, or its partners. Bad scenario.
That said, I think there is another large reason for the new (supposed) policy that has been overlooked in this discussion: DRM and the like. Without this move, it is much harder to protect content. The problem is that this, like most attempts to restrict what it is possible for a consumer to do with his own machine, adds no immediate benefit to the consumer, often serving only to annoy or inconvenience him/her. (The ‘big picture’ benefits are another discussion.)
A few comments here, the first of which is tangential to the topic.
1. It’s not only driver installers that automatically click buttons and hide their shenanigans from victims. A CD/DVD writing program, which used to be my favourite in this genre, did the same thing. During installation it invoked Windows Media Player in a hidden window and issued invisible instructions to Windows Media Player to persuade it to change the DVD region code in the drive’s firmware. This is the thing that can only be changed 4 times and then the drive automatically disables it from being changed again. We need logo certification for apps too, and have certification denied to apps that screw their customers.
2. As mentioned before but it bears repeating, I was also tricked by a "security" app that played the same kind of game to install an unsigned driver without the user’s knowledge. Maybe I know which company "Joe" used to work for. One version of their unsigned driver caused a few blue screens. Naturally I blamed Microsoft because I didn’t even know that driver was there. After being gently reminded of how to check for what drivers are installed, I found it.
3. Also mentioned before but bears repeating. Despite the blue screens mentioned in item 2 above, I’ve still had about 50 times as many blue screens caused by signed drivers than caused by unsigned drivers. And I’ve still had more blue screens caused by drivers that Microsoft designated themselves as the provider and publisher and self-signer, than drivers received from other vendors.
So, I have no opinion one way or the other about signed or unsigned drivers, but the trickery and secrecy played by some vendors is pretty offensive. The user needs to be informed when drivers are being installed, signed or not.
Somebody mentioned the joy of loading Linux on a laptop (especially an older, slightly dodgy laptop). I have lots of different operating systems around my house, and I assure you that Linux, which lets everybody and his idiot brother write drivers, is a pretty hit and miss affair for laptop support. Windows XP runs quite well even on some pretty obscure hardware.
The one operating system that has been completely without flaw or trouble is OpenBSD. And what does this operating system have in common with Windows? Driver authoring is very tightly controlled by a central group of developers. They are in fact an wholly undemocratic lot and make the WHQL process look pretty benign. Source must be provided or it won’t even be considered, and programming problems will get you the boot, even if they aren’t tripped over during runtime.
So keep in mind, if you don’t like Windows, there are alternatives. Even alternatives that might cause the drivers you write for your software to be of much higher quality. But if you like that option to keep your code proprietary, a little bit of driver signing is a pretty small price to pay.
This&nbsp;is the best story I’ve ever heard about somebody trying to get around the unsigned driver dialog…
PingBack from http://proxy.11a.nu/2005/09/14/device-driver-signing-bypasses/
PingBack from http://www.angelsonlinehome.com/?p=79
PingBack from http://www.angelsonlinehome.com/wp/?p=60