With Joe Wilcox, senior analyst, JupiterResearch. Microsoft and other security vendors are discussing what level of access should be provided to the kernel of the 64-bit version of the coming Windows Vista operating system.
Question: What is the issue?
Wilcox: The technology, which is referred to by one of two names: PatchGuard or Kernel Patch Protection. The bottom line is that Microsoft wants to minimize the amount of changes made to the kernel. This technology right now is available for the 64-bit versions of Windows XP and Windows Vista. There are a number of security companies that have [traditionally accessed] the kernel as part of the protection mechanism. Some of that may be logistical or preventative, depending on the vendor. The vendors say that they need kernel access as the best way for them to ensure that they protect the entire OS, including the kernel, from intrusion. Microsoft takes the position that the kernel should be basically unalterable. They want to keep everyone out, the bad guys and the good guys. So as part of its response to the EU [European Union], Microsoft says it will release APIs -- application program interfaces -- that will allow the security vendors to have some access around the kernel and to take information out of the kernel, but not direct access to the kernel. Microsoft claims its software security software would also be blocked from the kernel.
Question: Why is this contentious?
Wilcox: Here's the analogy I use: If the kernel is like the summit of a mountain, then the security vendors have been able to scale up there any way they want. They can pick the side, pick the path, and get up to the kernel. Under the new mechanism -- which won't be available for several years -- they will have to follow Microsoft's path, what I call the "Apian Way" -- the play is on "API" and the Roman Appian Way -- up the mountain. But they can't reach the summit. That's okay as long as the hackers don't have access. But if [the hackers] find their own path up the mountain and reach the summit, they can plant anything they want there, and there is no one to stop them. Right now, there is no access to the kernel. Future APIs will allow this path up the mountain, but not up to the summit. If I was an IT manager, I would stay the course with 32-bit Windows. With 32-bit, everyone has access to the kernel. 64-bit is in the future, but it's a ways off. The transition will not be the same as it was for 16-bit to 32-bit. The 32-bit offers a lot of power and performance already. [For 64-bit], there are a lot of issues to resolve in terms of supporting applications and software drivers. IT mangers want them to run smoothly and 64-bit already was a stretch. Now the controversy over the kernel is probably a good reason to stay the 32-bit course for a while until it shakes out.
Question: Microsoft now has a separate security software business. It seems that it could take advantage, even though it says that its own security developers won't have an unfair advantage over outsiders.
Wilcox: Let's talk about how security vendors may be judging Microsoft. They can listen to what Microsoft says or may want to look at Microsoft's behavior. They were fined twice by the EU, the second time for failure to disclose information in a way that satisfies the EU. In the U.S., Microsoft has agreed to a two-year extension to Justice Department oversight largely because of problems with information disclosure. So I'm not going to make a judgment either way, but I assume security vendors will be looking at actions rather than words. There will be no resolution in the near future, that's for sure. Microsoft said it will not allow access to the kernel and are sticking firmly to that approach. By the way, Microsoft's right to block access to the kernel from the security perspective. It's a good move. There are two caveats that would [make it okay]: A would be if Microsoft can keep the bad guys out of the kernel; B is if Microsoft wasn't competing with its security partners.
This 3 Questions originally appeared in a weekly report from IT Business Edge.
This was first published in November 2006