Here we go again...

...with the whole anti-competitive behavior thing.

Apparently, Microsoft is testing a technology in x86-64 versions of Windows (XP64, Windows Server 200something SPsomethingelse) called 'kernel patch protection'. What this does, by itself, is probably a good idea--it prevents certain types of system call hooking and modifications to the system's critical tables (for those sufficiently geeky as me to know what these low-level x86 tables are, they're the IDT, GDT, SDT, and the other dispatch tables) to prevent certain types of rootkits from properly functioning. If a driver or something tries to hook an entry in the Interrupt Descriptor Table or System Call Dispatch Table, the Windows Kernel will, in its infinite wisdom of how to gracefully handle errors, immediately BSOD with a bug-check-exception On AMD64 platforms (only--you Intel boys don't qualify for this feature just yet, but that day is probably coming Real Soon Now) the kernel patch protection also prevents the kernel from switching stacks to one not allocated by the kernel.

This is all well and good by itself, but there are a few problems with it:
1) Third-party anti-virus and firewall software vendors, as well as MANY device drivers, **NEED** to be able to hook system calls and interrupts.
2) There's no stable and safe way around this 'protective' measure, which will prevent a LOT of third-party security software from working unless they start using even more dangerous methods of hooking into the Windows kernel.

Humorously, Microsoft's official answer to those who complain about the fact that their drivers and security software suddenly stopped working is this:

Modify your application or driver to use only Microsoft-documented interfaces. If the functionality you want to enable is not supported with Microsoft-documented interfaces, then you cannot safely enable that functionality. There is no mechanism to selectively disable patch protection or "special-case" a given application to work around patch protection. If an application or driver patches the kernel, it generates a bug check and shuts down the system. Note that patch protection in the operating system might be extended in future releases or service packs, so using any undocumented mechanisms in your application or driver (even if they seem to work on released versions of Windows that support patch protection) might result in further incompatibilities in the future.

Click to expand...

...which would be fine, except most Windows software is closed-source. Which would be fine, except there's not a good, safe, and dependable other way to get security software running with the priveleges it needs to do its job other than installing it as a kernel patch.

I'm not saying shame on you Microsoft because I'm a linux user. In this case, I'm saying SHAME ON YOU MICROSOFT for making it harder for third parties to (once again!) have products integrate with your OS. Companies dependent on, say, Proventia, or Symantec AV, or Symantec firewalls, may well be SOL when this technology is rolled into Vista (as it is being promised at the moment). And what of device drivers that may have a very legitimate need to hook system calls?

Honestly, guys. Cut us all a break already. There is no 'kernel integrity' as it stands now, as you haven't let anybody but Microsoft people review the code for problems. This measure, while it could be good for your own security software divisions, is only going to make it harder for legitimate people to get their work done and keep Windows--which is quite a leaky ship--more secure. There is an urgent need at the moment for third-party security software running at the kernel level and until the functionality of the official Microsoft-provided tools is guaranteed and verified in the wild you shouldn't lock others out.

Microsoft, be sensible about this and offer a way for trusted companies to install kernel patches that have been digitally signed and verified by you. Or better yet, digitally signed and reviewed by an independent company (SysInternals would have been nice, but you own them now so that's off limits!) to guarantee proper functionality with the Windows OS.

End rant. Opinions?

I heard about this anti hooking thing in x64 a while back.

Security is always at the top of the list when peeople complain about windows. By preventing call hooking this is a step in the right direction. The article I had read a month or so ago, does explain that YES software developers are going to have to rewrite things to operate in 64bit mode. However they also say that they are willing to work with devleopers to get those things done.
I cant find where i read that... but as always, people are trying to find there way around this protection already
http://www.uninformed.org/?v=3&a=3&t=pdf

Is this only in x64 and only testing?
I have recently been getting bsod's for no apparent reason, other then getting a few updates from MS. It seems tied to the SPTD.sys loading or stalling. Research led me to my emulation software as weel as my virus scanner having somthing to do with an SCSI abstraction layer. Some feel it is linked to KB914784 or BB891593 of which I have neither. Mcaffe must have been aware of a problem as they told me to uninstall my virus program and download the newer engine. It had killed my install twice and is a progressive issue that does it's best to hose IDE drives. It is also linked to kernel debuggers in some fasion.

SPTD.sys errors are related to Daemon tools I had the same problem a while back. I forget how i solved it though...(uninstalling daemon??)

Update your SPDT driver (same place you got daemon-tools from). There is an update out.

Saw this before also. Personally I think rootkits are a huge concern and this is one of the only ways to stop them, since detecting them can be near impossible. Its tough to say though, they could make it where the small guy can bypass this, but then what stops the rootkits from just doing the same thing. They could also do it like ZA and protect the system but allow programs to access it that you give permission, though the vast majority of people would have no idea how to properly use this and just allow everything. Then you could try a Blocked and Unblocked list, though with that what a problem could occur with a program not being on the list due to it being new/small; authentication could also be a problem, as it stands spoofing things in the PC world can be slightly easy, so would it work of a type of hash value? Anyway I am a bit torn as I see problems with each solution. So my solution is Windows should save what you have done each night, and reinstall all it's files once a day.