In an interview with Computerworld, Ben Fathi Microsoft's vice president for the Windows core operating system, talked about the draft APIs and the company's rationale for releasing them. Excerpts from that interview follow:
What exactly did Microsoft announce today? We published two documents. The first one is a document called the Criteria Evaluation document and it really is a document that describes the criteria for evaluating the requirements as they come in from our partners and how we are going to address them in terms of adding APIs to the kernel. It is a list of processes that we have gone through to decide whether something should be added as an API or whether there is an existing way of doing that or whether there is a simpler design that [we] can work out with our partner that avoids introducing new APIs and potentially new attack surfaces on the kernel.
We are publishing this to be very clear and aboveboard on what our processes are for establishing the new APIs that we are going to add to the kernel. And we want to hear feedback from partners and the industry on whether this is a good set of criteria or not.
And the second document? The second document is the first draft of the actual APIs that we have been working on. We are publishing it for evaluation by our partners. The APIs will be available in Service Pack 1 [SP1] of Windows Vista later in 2007. We are working actively with our partners to get their feedback on things that aren't covered here in this first iteration of APIs. We plan to and are committed to working with them to continue to add APIs over time as needed to extend kernel functionality without compromising PatchGuard.
How many APIs did you release? There are four different classes of APIs. We took of all the requirements from our partners and prioritized them based on the most important needs they had. These are the top four areas that came up. The first set of APIs is around creating and opening processes and threads. So [that means] giving them the ability to set a policy in place that says when a thread is created or when a process is created what kind of security precautions they want to take. The second area is around protection of security software to make sure the security software that gets installed on the system is not itself being modified by viruses. The third one is around memory-based controls. The fourth area is image loading operations. This is a set of APIs that allows security software to block the loading of certain executables or DLLs [dynamic link libraries] into memory.
So what exactly does a draft API mean? What we have done is work with all the vendors. We have gotten their requirements and we have defined the APIs with all the arguments, the return values and everything they accomplish. This is our plan for what we will deliver with SP1. There is a period of time until the end of January where we will be talking with vendors and getting their detailed feedback. So far, we have gotten feedback on the scenarios they are trying to address and their requirements around those scenarios: Why is it that you want an API and what do you want to do with that API? Now we are giving them the actual API itself and they are going to read the document and tell us whether it accomplishes all the scenarios they want or not. Over the next few weeks, we will work with them to see if there are any changes that are needed. Hopefully everybody will agree this is the right set of APIs and this is what we will deliver in SP1.
How will Microsoft handle requests for new APIs from security vendors in future? We will continue to work with them. We have an e-mail alias and regular monthly meetings where they can come and ask for additional requirements. This set we described today is based on all of the things they brought to us so far. They can obviously come work directly with us, or they can send e-mail to that alias and we will prioritize it and add those APIs. To be clear, all of the vendors that we know about we have talked to directly and told them the approach we are taking. They are all fine with it. They all like the idea. They believe they can achieve a majority of the functionality they want with just this first set of APIs
Some vendors have asked that Microsoft allow them the same access to the kernel as they have been allowed in the past with 32-bit Windows. Has your position changed? You've got to be careful when talking about access to the kernel. All of our partners have always had access to the kernel. What we offer is access to extend the functionality of the kernel through documented APIs. What we have always said is that we don't want third parties modifying the kernel itself to achieve some functionality because that is not supportable, because is it not using documented interfaces. Every time we release a service pack or a new version of Windows we break their application. So our definition of access to the kernel is access through documented supported APIs and we haven't changed that.
We will continue to add APIs to make sure [vendors] get everything they want. But our stance on kernel patch protection has not changed. We do not turn it off. There is no way to turn it off because if we do turn it off, basically there is no security in the kernel. We didn't have that opportunity on 32-bit because of a lot of application compatibility issues. There were lots of applications and device drivers that patched the kernel and we felt that if we tightened security using the same measures it would break a lot of applications. So we decided to do it on 64-bit because those drivers and those applications have to be modified anyway. We felt this was the only opportunity and if we didn't do it now we would never be able to clean up the kernel ecosystem.