Windows Vista x64 To Require Signed Drivers

Anonymous Coward writes "With little fanfare, Microsoft just announced that the x64 version of Windows Vista will require all kernel-mode code to be digitally signed. This is very different than the current WHQL program, where the user ultimately decides how they want to handle unsigned drivers. Vista driver developers must obtain a Publisher Identity Certificate (PIC) from Microsoft. Microsoft says they won't charge for it, but they require that you have a Class 3 Commercial Software Publisher Certificate from Verisign. This costs $500 [EUR 412] per year, and as the name implies, is only available to commercial entities."

Comments

All this will do...

[ajiva]

All this is going to do is prevent software that emulate hardware (Daemon Tools for example) from working properly under Vista. As I recall these types of software pretend to be hardware using unsigned drivers, so this won't work unless they get the drivers signed somehow. Looks like a way to enforce DRM to me.

Re:All this will do...

[Randolpho]

Actually, nearly all hardware emulation drivers, along with most general purpose device drivers, can still be unsigned.

I suggest folks RTFA. Hell, just read the tagline for /. article. It says "kernel mode", folks, not "user mode". You need a digital signature to write kernel-mode drivers (and, BTW, to stream protected content), but user-mode unlicensed drivers are fair game.

Frankly, IMO, most drivers *should* be user-mode -- if you're writing your driver in kernel mode, you should re-think your design. Yeah, there's always the necessary exception, but if it's that important, go get a digital signature.

Re:All this will do...

[mrchaotica]

No, it'll screw over all OSS drivers in general, because if you modify it, it won't work anymore. It defeats the entire point of having the source code in the first place!

First they lock out open source drivers

[etymxris]

Next, applications? I'm not sure how they'll deal with developer machines, but then again, that problem should apply for drivers too. It's not really a slippery slope. They've been doing it on the xbox for years, after all. It's not so much the money as the control they have to vet everything that can run on their system.

It's all about the DRM.

[TripMaster Monkey]

The summary is a bit brief (as well as being plagarized verbatim from OSNews.com, but a brief perusal of the cited Microsoft article is rather illuminating:

• Drivers must be signed for devices that stream protected content. This includes audio drivers that use Protected User Mode Audio (PUMA) and Protected Audio Path (PAP), and video device drivers that handle protected video path-output protection management (PVP-OPM) commands.
  
• Unsigned kernel-mode software will not load and will not run on x64-based systems.
  
• Note: Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.

(Boldface mine.)

It would seem that Microsoft cares more about the profits of the record companies than it does about the ability of its users to be able to use its software. Just one more reason to switch to Linux.

Re:It's all about the DRM.

[mrchaotica]

Can I use the Windows API and play a CD's audio tracks from a home brew .Net app?

The Windows API will have very little to do with it. Basically, it'll depend on what you want to do.

For example, just sending the audio to the "Trusted" (i.e. restricted) output devices will work, but "faking" the hardware so as to capture the digital stream to use for Fair Use won't (this is exactly why they're requiring all drivers to be cryptographically signed).

And there won't be a damn thing you can do about it!

If the application level is unaffected by this, then its not that bad.

I'm sure it wasn't that bad when the NAZIs started forcing the Jews to wear stars, either.

But if they are enforcing restrictions to the application layer, this could really stiffle non-professional windows development.

Does the phrase "digital serf" mean anything to you? 'Cause that's what Microsoft, the RIAA, and the MPAA want to turn us all into. It won't just stifle non-professional Windows development, it'll stifle culture and creativity in general by setting up tolls every time anyone wants to communicate an idea. It will be like Bellsouth's "two-tiered internet [sic]" but infinitely worse.

Re:It's all about the DRM.

[RingDev]

Wow, I'd rate you +1 insightful just for cramming all that FUD into one post. Well done!

-Rick

Re:It's all about the DRM.

[Rhys]

And there won't be a damn thing you can do about it until someone finds the first security exploit in the OS!

So we should have to wait all of what, negative five minutes?

Seriously. This just copy protection at the OS level. People break game copy protection all the time. People will find a security hole in Vista and use it to do the exact same thing (where's the statement that tests the signed condition... yes some nops there would do nicely) and it'll be wide open again. In the worst case there is always the ability of something like a mod chip to alter signals on the fly. I'd have faith if the hardware gurus can do it to a Xbox they can do it to a PC.

It is as bad as MMO makers claiming they're going to detect and ban bots. If my bot is a linux router with a usb hookup and a "keyboard" program running to feed "user interaction" to the game-running windows machine, they can't detect it. To them nothing is out of the ordinary. Sure, you have to decode the packet stream but that isn't /that/ hard. The information MMOs send isn't that different from what MUDs send, and people have been scripting those for years. The best the MMO maker can do is use hieuristics to watch for "bot-like" behavior but even that is questionable at best. (I'm sure I look like a bot by about 2 am if I'm up playing that late)

From the nail-in-the-coffin department...

[pdbogen]

All I can say is what's probably come to everyone else's mind: the banging sound of hammer against coffin.
This will certainly quiet complaints about Windows' crashing (since many crashes are related to poorly written drivers, WHQL or not), but how did whomever thought this would be a good idea completely forget about the serious compatbility issues that this will raise?

Ooh lovely

[JediTrainer]

While I applaud the idea of signed drivers and the like, this looks like a very clever way to shut out OSS developers. Heck - some of the smaller commercial outfits might even balk at having to spend that kind of money on the certificate.

What pains me is knowing full well that this really won't necessarily increase the quality of the drivers, though. So they're signed. So what? All this might do is delay upgrades, if anything.

You will be able to disable verification

[aapold]

Its in the white paper attatched. Is it perfect? no... but it won't absolutely prevent you from doing stuff. Here's the relevent text:


How to Disable Signature Enforcement during Development
During the early stages of development, developers can disable enforcement in Windows so that driver signing is not necessary. The following options are available for developers to disable digital signature enforcement temporarily so that Windows will load an unsigned driver.
Attaching a kernel debugger. Attaching an active kernel debugger to the target computer disables the enforcement module in Windows Vista and allows the driver to load.
Using the F8 option. An F8 boot option introduced with Windows Vista--"Disable Driver Signature Enforcement"--is available to disable the kernel-signing enforcement only for the current boot session. This setting does not persist across boot sessions.
Setting the boot configuration. A boot configuration setting is available for prerelease builds that allows the suppression of the enforcement module in Windows to be persisted across boot sessions. Windows Vista includes a command-line tool, BCDedit, which can be used to set this option. To use BCDedit, the user must have Elevated User or Administrator privileges on the system. The most straightforward approach is to create a desktop shortcut to cmd.exe, and then right-click -> Run Elevated. The following shows an example of running BDCedit at the command prompt:

// Disable enforcement - no signing checks
Bcdedit.exe -set nointegritychecks ON

// Enable enforcement - signing checks apply
Bcdedit.exe -set nointegritychecks OFF


// Disabling integrity check on an alternate OS
// specified by a GUID for the system ID
Bcdedit.exe -set {4518fd64-05f1-11da-b13e-00306e386aee} nointegritychecks ON

I'm not sure it'll even do that.

[cduffy]

Some software of that variety takes the approach of acting as an iSCSI device. So long as the OS has native iSCSI support, the application need not install its driver.

I'm considerably more worried about the impact on projects like OpenVPN.

STUPID

[Chanc_Gorkon]

Does Microsoft even know the amount of drivers that ARE NOT signed?? This is stupid and it won't prevent anything. Is Microsoft going to look over thousands of drivers just to make sure they don't cause anything bad so they can put thier little WHQL seal and sign the blasted thing? What's to prevent someone from creating a hack that gets around this? Nothing. Why even try to do something like this? At least give users the option to screw up the system.

What about switching the root cert?

[Halo-]

Okay, so MS requires all kernel drivers to be signed. That's ugly, but anything has that is signed has to be verified to the meaningful. The certificate used to verify the signatures is still stored in software at this time, right?

So, what's to stop me from replacing the certificate which comes with Windows with my own, and then just resigning all the drivers?

(Okay, the DMCA for one... grrr....)

I don't think this if going to make Windows unhackable until hardware support for the certs is added. (which is pretty close, I think...)

Re:why are they calling it x64?

[frankie]

Why is this so difficult for so many people to figure out? Microsoft doesn't want to play favorites in the x86 war. They don't want to say either "x86-64" or "EMT64" and offend the other chipmaker, so they just call it generic "x64". It's obvious.

Re:Not true...

[99BottlesOfBeerInMyF]

if you actually read the MSDN page on this subject you will find that non administrators will be prevented from installing unsigned drivers.

This is not true. From the article, "Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems." On 32 bit systems, only admins can load unsigned drivers. on 64-bit, no one can.

a shot in the foot

[rocketman768]

This is the beginning of microsoft's death. Anyone who's read "In the beginning was the command line" by Neal Stephenson should recognize these early signs. It's the same reason apple never got really big: they used proprietary hardware and therefore limited the amount of users that could use their OS. Therefore, prices stayed relatively high, and most users chose the more flexible PC platform. Microsoft is requiring their users to use (sort of) proprietary software and drivers. This will of course result in the fact that other (more flexible) OS's will become more popular. I'm just now getting to see the usefulness in Linux. I've used it off and on for the past 6 years, but now it's getting to the point where my machine is in Linux mode for a week at a time before I need to do some Maple or Matlab stuff. All I can say is that I will most definitely have a dual-boot system from now on, and that the more restrictive MS gets, the more I will stay in Linux to rip MY OWN FRIGGIN CD's and whatever else they consider potentially unlawful at MS. It's a self-stabilizing situation within the market, so don't worry too much about it. It's the beginning of a new era where Windows will not have the majority of the market.

You CANNOT do this in the production version

[kawika]

Read on, it says that the BCDEDIT option will be removed before final Vista code ships, perhaps as early as Vista RC1.

Re:Not true...

[99BottlesOfBeerInMyF]

User-mode drivers (which most drivers *should* be) are still fair game. It's only kernel-mode that's at issue, and they're only really necessary for stringent timing requirements and legacy hardware.

Except for drivers for "CD-ROM, disk drivers, ATA/ATAPI controllers, mouse and other pointing devices, SCSI and RAID controllers, and system devices." as the article says. I'd say that is a good portion of the drivers, wouldn't you?

You're neglecting one important fact...

[jd]

Since only commercial vendors can be licensed, any garage developer (Messers Hewlett and Packard, for example) can build their own hardware but NOT be licensed to produce a driver for it. Only a pre-existing commercial vendor can do that, and most won't unless you pay them.

This not only means that you can't have third-party drivers, it ALSO means you can't have 1st party drivers from start-ups. It effectively prohibits anyone new from entering the hardware arena.

But there's more! Although Microsoft's license is "free", they aren't necessarily going to give a license to everyone. Thus, they can effectively ban technology they don't like. Blu-Ray vs. HD-DVD is going to be the shortest battle on record, if all it will take is for Microsoft to prohibit rival systems running on "their" desktops.

There is a way round the problem, but it puts you at risk from the DMCA as (by definition) it is circumventing security technology. By having a hypervisor-like OS running at the lowest level, and then having Vista run on top of that, you can make any piece of physical hardware look like any other piece of hardware that you like. Nothing Vista can do about it, as it can't see the hardware directly, all it can see is the results of pushing data of one type in one direction, then pulling data of another type in the opposite direction.

Re:64bit ?

[burndive]

Backwards compatability.

All drivers for 64-bit XP need to be rebuilt, since the 32-bit versions used with XP won't work in a 64-bit operating system. There are currently no 64-bit XP drivers to be backward-compatible with, so MS is setting the bar where it wants for all new drivers. They can't do the same with 32-bit because they have to be compatible with the unsigned 32-bit drivers already on the market for XP.

64-bit is the future of desktop computing, and MS doesn't want have to support unsigned drivers in future versions of Windows.

Re:To be honest...

[mrchaotica]

something that someone else produced and can damn well provide to you under whatever restrictions they please because *they created it, and you didn't*

No, THIS it what's "divorced from reality!"

Nowhere in US copyright law does it say anything remotely like this -- no matter how much the publishers wish it did. The real reality is that ideas are not property, except in the sense that they belong to the culture as a whole. The foundation of copyright law is based on a social contract designed to promote the general welfare (i.e. Common Good), not to give creators and/or publishers any kind of entitlement! That's why copyright expires, if you couldn't figure it out before. Copyright is actually a lease -- artists lease a monopoly from the government for a period of time (originally 14 years), and make payment in the form of the creative work itself.

if a content owner tells you that you can only watch it while standing naked in your living room bouncing on one foot with half your nutsack shaved, thats their business.

That's completely and utterly false -- the courts have struck down many less insane restrictions (by the way, did you ever hear of Betamax?).

Here's the bottom line: There's no such thing as a "content owner," what you call "media" is actually our culture (which everyone has a right to experience), and the social contract whereby we (as citizens) allow artists to enjoy monopoly status is revokable by the people, if the artists fail to hold up their end of the bargain. Although many don't agree with me yet, I believe this has already happened.

Re:Generic wrapper driver.

[Philip K Dickhead]

Drivers aren't the biggest security issue - as incompleted TCP handshakes were not.

This is for Disney's "security" - not ours. Like the "USA Patriot" act: the target of the restriction is the average person, not the "evildoer".