09.17.05
PDC Day 4
Not really much to say about day 4. Today it was all panels for me, on the future directions for .NET and Windows Internals. Rather than the traditional presentation format, it was audience driven with 4-6 speakers responding to questions from the floor. The .NET panels were interesting to listen to but I really couldn’t take much away from them. Future directions seem to be largely driven by demand and performance, with the only vaguely interesting thing (to me) being the possible addition of default implementations for interfaces which will give a poor-man’s multiple inheritance.
The Windows Internals session was more interesting in the line of discussion I concluded with yesterday. I was able to actually talk with the Windows kernel team about the restrictions being placed on kernel mode code and get their feeling on it. It was made rather overwhelmingly clear to me that the driver signing implementation was going in from massive corporate pressure to do something about malware and that sort of pressure (which really affects Microsoft’s bottom line on the business desktop where Linux is far more of a threat) isn’t something they can give way to easily. However, the line being pushed was a little less severe than the one I was hearing yesterday:
- Windows kernel protections will definitely be turned off when a kernel debugger is present.
- The decision to have Microsoft as the only signing authority hasn’t been made yet – it’s just one of the options being considered. Alternately some form of code signing could be used and managed as a group policy (something I’d be quite comfortable with).
- Local kernel debugging tools are likely to go away as they can be used to introduce unsigned code into the kernel. While this was obvious for Windbg, what this means for tools like SoftICE is far more ambiguous. I’m not sure Microsoft could get away with eliminating entire products like that.
- Sysinternals tools aren’t really a consideration in their thinking. While they acknowledge their usefulness, the pressure to restrict kernel mode is overwhelming.
- Kernel debugging through VM connections will be an interesting avenue to continue to use if looking into kernel structures.
- Windows XP-64 already includes code that scans for unauthorized patching and hooking of kernel routines and will bugcheck if it finds something.
- Microsoft recognizes that any security attempt is worthless unless they control the boot sequence from hardware. My take is that they believe raising the bar is better than doing nothing.
I’m still a little annoyed about the whole “need a kernel debugger present” restriction but I can see the point of view from Microsoft’s side, especially when expressed in terms of corporate pressure. Unfortunately that means that despite my love of the NT kernel, it seems Linux is going to become much more the OS of choice for people that want to mess around at the hardware/OS level to create new and interesting things. One of the strengths of Windows has always been its openness which attracted developers over other products, it seems that’s going to change. While I understand the loss, I still mourn it.