EricK's Weblog

The 2007 Revolution!

2006-05-23T10:24:00Z

I recently built a new computer at home and took the opportunity to make it a beta software testing platform. I run Vista and Office 2007 on it along with Windows Live Messenger Beta and of course IE7 Beta and Media Player 11 Beta (exclusively, it is not a dual boot machine). I would be running the OneCare Beta on here but that isn't supported yet. I do run it on some other machines I manage though.

I have definitely run into some issues with software compatibility and a couple of small OS issues, but overall it has been an incredible experience. Before Vista I used to always look at Windows 2000 and think it just looked old and dated compared to XP. Now when I see XP it feels so outdated. There is such a slick look and experience with our latest products.

I know people have compared the improvements to Apple, but I think it's more than that. I've always appreciated Apple's dedication to design, but I've never been a fan of what they produced, including the OS. I do really like the new look of Windows in Vista. I think we have done a good job of moving forward while still being different. When you run Vista, no matter how much people compare it to Apple, you can still tell you are running Windows (and I don't mean that in a bad way).

I haven't used Office enough to comment a lot on it now, but I do think Outlook 2007 is a large improvement. The integration of RSS feeds along with the new look and ease of use is great. I also appreciate the greater flexibility in categorizing e-mails.

The bottom line is that we've been able to incorporate cool new features and a cool new look into our products. In XP I used to maximize every window I had open. Now I want to see as many windows on my screen as possible because everything looks so slick.

I'll have updates on my experience as I go along (it has only been 2 days now as my exclusive home platform), but so far I am pretty impressed. 2007 looks like a great year for us. And I really do stand behind that. I have been buying our stock because I feel we are currently undervalued and do a large positive correction in our stock price that will hopefully come after the launch of Vista and Office 2007.

I Am Back (Hopefully)

2006-05-23T10:02:00Z

I have to start off by saying it's been a rough couple of months. I started at Microsoft late November and started getting ill in the middle of January. I can't say I am completely better yet, but I am taking a lot of steps to get things under control.

Basically my whole digestive system has stopped functioning properly. A lot of things came together at once to make it just a horrible experience. First I started having acid reflux and intense heartburn caused by GERD. Then I stopped being able to digest a variety of foods. And finally I had a lot of inflammation throughout my digestive system that put me in almost constant pain.

The acid reflux is being controlled by medicine I have to take twice a day timed with my meals so that I don't have intense pain for hours. I am waiting for the results of some tests to determine what my body can no longer digest and am controlling my diet in the meantime. And finally, I am taking lots of supplements to make sure my body has all of the enzymes, etc. for digestion.

Currently I am taking 16 pills a day to control everything. Hopefully my inflammation will go down shortly and I'll be able to cut down the amount of medicine I am taking. In the meantime I am just happy for every mostly pain-free day I have.

I am extremely lucky to be working at Microsoft during all of this. My schedule has been tailored to my needs and my manager has been more than understanding. At a lot of companies I would have been fired long ago considering I haven't been working that long. Hopefully I'll be able to repay them with some hard work and great results.

User Mode Component of the Filter Manager

2006-04-25T06:32:00Z

Someone sent me an e-mail asking about the user mode component of the Filter Manager. Since I am still not feeling well I won't be writing an entry covering it right now, but you can take a look at this presentation. It is a pretty simple overview of what you can/can't do in user mode. If this is not at all what you were looking for feel free to post a comment on this entry.

Programming While Ill

2006-04-20T11:08:00Z

First of all, I am still sick, but I wanted to at least write something. So, I thought I would write about something that is bugging me right now.

In all of my previous jobs I could work while I was sick; I got things done a little bit slower, but stuff still got done. That includes jobs I have had in the service industry and jobs I've had at other computer companies. But, the programming project I am working on right now requires a lot of concentration and math. It's not a difficult project in terms of architecture, but there are a lot of little details that I could get wrong and it is a pretty important part of the tool we will be releasing.

I haven't been sick all day every day, part of the day I will feel well and part of the day I won’t feel like moving. The problem is that by the time I feel better, do some thinking, and try to get into the design/coding I start to feel sick again. It’s not the project that is causing me to not feel well; it is interesting and I am excited to get it done. This is starting to get frustrating because each time I have to start the thought process over again.

So, tomorrow I think I will try writing out every thought I have as I think through the implementation. I’m hoping that will enable me to pick-up where I left off when I do feel well and make some real progress so that I can finish the prototype for this component by the end of this weekend.

I hope you are all doing well and I promise to start the technical posts again as soon as I feel better.

Sorry for the lack of posts...

2006-04-07T08:31:00Z

I apologize for not posting much the last couple weeks. A lot of stuff has been on the back burner because I have been having some medical issues and am going through a bunch of testing. They don't know what it is for sure yet, but I'm hoping it is something minor. Hopefully I can rest up this weekend and get back to posting regularly next week. I hope all of you are having a great week and I'll be sure to finish up answering your questions and posting new content as soon as I feel better.

Eric

How dangerous are kernel mode rootkits?

2006-04-03T13:54:00Z

This post was originally going to be a comment in response to rootbeer's question in a comment to my last blog entry, but it became such a long reply that I decided to make it a post. The question was:

“How dangerous are kernel-level rootkits today?”

I’m not sure how much you know about rootkits, but I’ll assume you know at least the ideas behind how they work. If not, there are plenty of resources that explain how they work online. Basically a rootkit is the name for a mechanism used to try to hide the existence of code, files, processes, etc. from the rest of the system. Technically the code hidden inside a rootkit may not have been written to be malicious (in fact it may try to provide a service to the user). However, most people in the operating systems community feel that rootkit methods should never be used. The reason for this is that by hiding files, etc. rootkits negatively impact a user’s ability to control and manage their own system. From now on when I talk about rootkits I will be discussing rootkits that hide malicious code.

Rootkits can operate in user mode or kernel mode; more recent and more powerful rootkits operate in kernel mode where they are completely able to hide themselves from user mode. As viruses have become more sophisticated over the years anti-viruses have had to become more intelligent to detect and destroy viruses. The same thing is happening currently with rootkits. As rootkits get better and better at hiding themselves from the system anti-rootkits have to adapt to these changes in the rootkits they try to detect.

The good news is that (as far as I know) as of now no one has come up with a way to completely hide a rootkit from the system. In trying to hide themselves, rootkits have to interpose at some layer within the operating system so that they can hide whatever they are trying to hide from the rest of the system. The problem (for rootkit writers) is that it is extremely, extremely difficult to fully hide their interposition mechanism from the system.

For instance, earlier kernel mode rootkits hid system resources by hooking the system call table. This allowed them to hide files from the rest of the system, but all it took to discover the rootkit was looking at the system call table for abnormal entries (its not quite this simple because some drivers, like the one with regmon, hooks the system service table for completely different reasons). The latest kernel mode rootkits (that I am aware of) interpose on the page fault handler so that they can hide the malicious code unless it is trying to be executed. However, this requires them to fail access to their code in nonpaged pool. This is something that should never occur (think page fault in nonpaged pool blue screens) and hence it can be detected. Also, so far they have not been able to hide their interposed page fault handler and so that can be detected also.

After that long winded discussion there are basically two things to remember. First of all, a kernel mode rootkit only gets installed if it is able to find an existing vulnerability to take advantage of (which there are). And second, up until now, and in the foreseeable future, rootkits will always have some component that can be detected.

Just like viruses and all code exploits, the race will be between hackers trying to find more sophisticated ways to infiltrate the system and hide their code and the good guys finding ways to detect and remove rootkits. I don’t think the situation is hopeless and I have a suspicion that years from now we will discuss rootkits the same way we discuss viruses today.

I will end this by saying I am not on the security team and by no means am I a security expert. So, if I got something wrong (it is 4 am after all), something needs to be clarified, or you want to add something to this discussion feel free to leave a comment.

What do you want to know about the Windows kernel?

2006-04-01T10:36:00Z

I am by no means a kernel expert, but I do have a couple years of experience working with the Windows kernel and I have done a fair amount of reading about the internals of Windows and operating system development in general. And of course I have looked over a large amount of the Windows code.

While I've spent the last four months or so getting dug into my position, I need to expand my horizons and choose some areas of the Windows kernel to learn about. I was hoping all of you could help me out by leaving comments with your questions about the Windows kernel. Now, if you are driver developer with over five years of experience there is probably no way I can tell you something you don't know. But, if you are an application developer wanting to know more about the internals of Windows or someone that knows a lot about operating systems theory who is wondering how Windows does something I may be able to help out.

I'll try to answer as many questions immediately as I can myself; then I will pick from the remaining questions to research (by talking to the person who wrote the Windows component) and get back to you with an answer. I would prefer to stick to general questions about Windows components, no function or parameter specific questions or anything of that sort please.

Of course I won't release any information that isn't public knowledge. And, as always, please be respectful when asking your questions.

File System Minifilter Drivers (Part 2)

2006-04-01T09:52:00Z

In my last entry I covered some basic information about file system minifilter drivers. This entry I want to talk about more about them, specifically their context support. I don’t think I will make this as long as I previously planned on because I think I want to separate my discussion of callback rules and top tips into a separate entry.

A driver’s support for contexts begins with the call to FltRegisterFilter. The FLT_REGISTRATION typed variable passed into that function includes a pointer to a FLT_CONTEXT_REGISTRATION structure. This structure is pretty simple:

typedef struct _FLT_CONTEXT_REGISTRATION {

FLT_CONTEXT_TYPE ContextType;

FLT_CONTEXT_REGISTRATION_FLAGS Flags;

PFLT_CONTEXT_CLEANUP_CALLBACK ContextCleanupCallback;

SIZE_T Size;

ULONG PoolTag;

PFLT_CONTEXT_ALLOCATE_CALLBACK ContextAllocateCallback;

PFLT_CONTEXT_FREE_CALLBACK ContextFreeCallback;

PVOID Reserved1;

} FLT_CONTEXT_REGISTRATION, *PFLT_CONTEXT_REGISTRATION;

Most of this is explained well in MSDN so I won’t go into what each field is, but it is important to remember that if you register multiple context definitions (for the same context type) with varying sizes you need to specify FLTFL_CONTEXT_REGISTRATION_NO_EXACT_SIZE_MATCH so that the Filter Manager does not fail the allocations of your contexts.

After that it is easy to allocate a context using FltAllocateContext. Currently the context types supported are: FLT_INSTANCE_CONTEXT, FLT_STREAM_CONTEXT, FLT_STREAMHANDLE_CONTEXT, and FLT_VOLUME_CONTEXT (file contexts are not yet supported). Finally, after being allocated, a context can be set by calling the respective FltSetxxxContext routine. The point of these contexts is to have an easy mechanism for attaching information to an instance, a stream, a stream handle, or a volume that is easily retrievable, reference counted, and garbage collected by the Filter Manager.

When I was using stream handle contexts in my first minifilter, the main problem I had was with reference counting. At a basic level it is pretty simple. The reference count on a context is increased whenever you call an FltGetxxxContext routine and you’ll need to call FltReleaseContext when you are done working with the context you retrieved. You can also manually reference a context with FltReferenceContext. The problem I had was in understanding what happens when you allocate and set a context.

The simple answer is that both increment the reference count. So, in the MSDN entry for FltSetxxxContext it says you need to call FltReleaseContext for a successful or a failed FltSetxxxContext call. The problem is that there is actually a bit of a difference in the failure and successful case. If the set context fails you actually need to call FltReleaseContext twice to remove the reference from the allocation and the failed set context call to get the context to be garbage collected. In the successful case you call FltReleaseContext to get rid of the reference count from the allocation and you are left with a reference count of one on the context.

The other thing to watch out for is close operations. For instance, the reference count on my stream handle contexts was automatically decremented on a successful close of the file (in between the PreClose and PostClose callbacks). If you understand what causes reference count events on your contexts and keep close track of them the Filter Manager’s support for reference counting and context cleanup callbacks are extremely helpful.

That is about all I have to say about context support in the Filter Manager. The Filter Manager’s support for contexts makes them extremely powerful and easy to use, but also very generic. They should be a good fit for any information you need to attach to a specific instance, stream, stream handle, or volume.

In my next post I will discuss some general rules of callbacks (specifically IRQL levels and the issues around handling that) and some of my general tips for working with the Filter Manager.

File System Minifilter Drivers (Part 1)

2006-03-27T22:24:00Z

For my first technical post I wanted to talk about the Windows component I have been learning about and working with the most, the Filter Manager. After working on Nooks at college, I came to Microsoft aware of the difficulty in writing a driver for Windows. When I get really frustrated I compare understanding IRPs to understanding quantum mechanics, but that isn’t exactly a fair comparison.

The Filter Manager was meant to create a simple mechanism for drivers to filter file system operations: file system minifilter drivers. File system minifilter driver are located between the I/O manager and the base filesystem, not between the filesystem and the storage driver(s) like legacy file system filter drivers.

Now, I should mention that this isn’t a new mechanism; it has been around for a while. But, undoubtedly some people are aware of it but haven’t used it yet (like me until recently) and I feel it is important that every driver writer be aware of how they work. If a file system minifilter driver provides the functionality you need then you should write one; file system minifilter drivers are simpler than legacy drivers and hence less prone to bugs (at least theoretically). If you already know how the Filter Manager works I won’t be providing any inside information or upcoming updates, so feel free to skip this post.

The old mechanism of filtering file system operations (between the filesystem and storage driver(s)) required handling IRPs and the creation/handling of device objects. On the other hand, file system minifilter drivers that utilize the Filter Manager utilize a callback mechanism. This callback mechanism specifies what IRPs you are interested in filtering. The structure for doing this is extremely simple.

const FLT_OPERATION_REGISTRATION FilterCallbacks[] = {

{IRP_MJ_CREATE,

PreCreate,

PostCreate,

NULL},

{IRP_MJ_WRITE,

PreWrite,

NULL,

NULL},

{IRP_MJ_CLOSE,

PreClose,

PostClose,

NULL},

{IRP_MJ_OPERATION_END}

};

This structure is passed to the Filter Manager (with some other registration information) in a call to FltRegisterFilter. These callback functions (PreCreate, PostClose, etc.) then need to be defined in the driver and the filter manager ensures that the appropriate functions are called when it receives the IRPs you specified you wanted callbacks for. The pre-callbacks are for IRPs going from the I/O manager to the base filesystem. The function signature for pre-callbacks is:

typedef FLT_PREOP_CALLBACK_STATUS
(*PFLT_PRE_OPERATION_CALLBACK) (
    IN OUT PFLT_CALLBACK_DATA Data,
    IN PCFLT_RELATED_OBJECTS FltObjects,
    OUT PVOID *CompletionContext
    );

Post-callbacks are for IRPs going in the opposite direction, from the base filesystem to the I/O manager and their function signature is:

typedef FLT_POSTOP_CALLBACK_STATUS
  (*PFLT_POST_OPERATION_CALLBACK) (
    IN OUT PFLT_CALLBACK_DATA Data,
    IN PCFLT_RELATED_OBJECTS FltObjects,
    IN PVOID CompletionContext,
    IN FLT_POST_OPERATION_FLAGS Flags
    );

There are a couple parameter differences between the pre- and post-callbacks, but the general idea is the same. The Data parameter specifies information about an I/O operation. Basically it represents the IRP information but in a simple to use container. The FltObjects parameter provides pointers to objects related to the operation including the volume and file object. The CompletionContext parameter is extremely helpful for passing information between the callbacks. Any pre-callback can set CompletionContext and that pointer will be passed in to the post-callback.

The CompletionContext mechanism and context support are my two most used components of the Filter Manager. While CompletionContext allows you to attach information to a specific IRP operation, the Filter Manager’s context support allows you to attach information to a volume, instance, file, stream, or stream handle (support for all of these are not yet completed, so check the latest information in MSDN to see what is currently supported). While being able to transfer information to a post-callback is useful, sometimes higher-level tracking is required. For instance, a filter driver wanting to track all operations across the lifetime of a particular file open would use stream handles (which operates at the file object level).

In my next post I will continue with a more in-depth discussion of the Filter Manager’s context support. Anyone wanting to learn more about file system minifilter drivers should look at MSDN and the file system minifilter driver WHDC page.

My kernel development experience

2006-03-21T11:50:00Z

In a previous post I mentioned that I would discuss my qualifications for being the kernel-mode go-to-guy for my group despite only having a bachelor’s degree and so I figured now is as good a time as any to discuss it.

Well, first of all, I spent six years at University of Washington getting a BS in computer engineering and a BS in physics. That's enough time for a normal person to get a masters degree, but I've never been very normal. I was interested in pretty much every class at school and so I ended up with 341 credits. The last year and a half I tried to get involved in research and so I got involved with the Nooks project.

At a high level Nooks is a system for driver reliability that isolates drivers in order to detect errors and then handle the errors by unloading and reloading the driver without user interaction and with only a very short interruption to system responsiveness. There are a lot of good papers and presentations on Nooks at http://nooks.cs.washington.edu/.

There were a lot of factors that came together to allow me to work on Nooks and I feel extremely lucky. First, I had Professor Hank Levy for operating systems and Mike Swift as my TA. Hank* is an incredible professor and got a lot of the people in the class excited about operating systems, including me. Mike had come back to graduate school after working at Microsoft and spent some time discussing his research project (Nooks) and it sounded very interesting. A group of us decided to take the operating systems capstone (basically a quarter long project course for seniors) the following quarter.

Second, Gary Kimura, one of the original NT designers that came from DEC with Dave Cutler, is a visiting professor at UW. Besides teaching the undergraduate operating systems class and the software engineering courses, Gary teaches the operating systems capstone class. As anyone that was around at Microsoft when Gary was working there will tell you, Gary is incredibly sharp and a great person. He was a great resource for us and got us excited about NT with his stories about the history and personalities of NT. He also brought in lectures from Microsoft, including Landy Wang and Darryl Havens who both recently were promoted to Distinguished Engineers.

Third, Gary had worked with Microsoft to allow us (nearly) full access to the Windows 2000 source code. While Mike was working on Nooks for Linux, a couple of us decided to spend our time in the operating system capstone, and several research quarters after that, working on writing Nooks for NT. It was incredibly overwhelming and rewarding at the same time. Hank and Mike weren’t able to look at the source code and so sometimes it became difficult trying to work through issues without discussing any internals of the operating system that weren’t publicly available.

And lastly, Nooks was an amazing project. It won best paper at SOSP and several other awards. All of these factors combined to provide the most amazing combination of talent and projects that I had ever experienced (and that has only since been surpassed by working at Microsoft).

This has already gone a bit long, but I had a lot of kernel experience from working on Nooks for Windows. I wrote a loader based off of the driver verifier loader, the object tracker, the garbage collector, the memory manager for Nooks, and various other bits and pieces. I learned a lot and had some incredible teachers and I will forever be in debt to them.

Well after writing all of that I’m not sure if it really stated my credentials, but it at least gave an idea of some of my background.

* I always feel disrespectful calling Hank, Mike, and Gary by their first names, but that’s what they always insisted I call them by.

What do people think of MSDN?

2006-03-18T05:24:00Z

One of the things about being a new employee at any company is learning how to find the information to do your job. One of the primary resources is of course the code, but usually you don’t want to have to look at the code itself to determine how to use it. If you always looked at the code, you’d never get anything done. The people are also a large resource too, but you don’t want to bother people all the time because they too have things to get done.

So, a lot of the time I end up using MSDN to look up information about functions/systems. Some examples of things I read a lot about were Windows Management Instrumentation (WMI) and the Filter Manager.

Now, before I say anything negative, I should mention that MSDN (from my viewpoint) has a lot of useful information and I can’t even imagine being tasked with keeping it up-to-date, organized, and easy to read. But, one experience I have had several times is that MSDN will get me started, but I will have some errors pop up in my code. Usually those errors are caused by not realizing something small but important. For instance, it could be that a parameter is set to NULL in an error case or that the data I received is formatted in a certain way, etc.

Usually I end up solving these types of issues by doing a search on the web/intranet. That usually leads me to a presentation that the authors of the subsystem made at some point to clarify things that people seemed to be missing. For instance, the case where I was missing that a parameter was set to NULL in the error case was in regards to registry callbacks using CmRegisterCallback. In the RegNtPostCreateKey callback, (*Argument2)->Object is set to NULL if the create failed. Now, I should probably have thought about this, but sometimes when you are moving fast or dealing with other complexities at the same time (like the fact that you have to do a double dereference on Argument2 for RegNtPostCreateKey) shifts your mind from catching these things.

So, I started to think that it might be a good idea to tie the developers to their MSDN content more. I’m not saying that the developers should be tasked with managing MSDN, but that they should learn to keep it in mind. For instance, obviously that issue was included in the presentation because some people were having problems with it. Wouldn’t it have been nice if the person who made the presentation sat down and said, “Hey, I have to clarify this in my presentation, maybe we should clarify it in MSDN also.” I am not trying to pick on the writer of CmRegisterCallback as I also had this issue with the Filter Manager and other components.

So, I’m curious about people’s experiences with MSDN, specifically people with much more experience using it than me. Now, I don’t want this to turn into an MSDN hate thread, so please only give constructive feedback on your experiences. If you only want to say that you think it is horrible, I am aware that there are a lot of people that feel that way and that that feedback does not help make it better. I should also say that I don’t work on MSDN, but I may follow up with the people that are if I feel I have some concrete steps/actions that would help to improve MSDN.

My Position

2006-03-18T05:02:00Z

So, I guess I should start off with some information about what exactly I do at Microsoft. As I mentioned, I started almost four months ago as a software development engineer (SDE). I work in the Windows Core division in what is known as Windows Fundamentals. And, within Windows Fundamentals I work with the application compatibility group.

My group is the one in charge of making sure that your applications keep running across operating system upgrades. There are several components to that: testing applications with new versions of operating systems, serving as a resource for other Windows groups to ask about the impact of operating systems changes they are considering, and finding ways to help companies detect and fix compatibility problems in their software (after all, companies have a lot of internal-only software that they rely on).

I was hired to focus on low-level issues. A large portion of the group I work on focuses on user-mode components (although they of course know a lot about the internals of the OS). My job is to become an expert on the kernel mode components of the operating system and to be the go-to guy for any kernel mode components that need to be written.

Now, someone might ask why someone fresh out of college with only a bachelor’s degree would be in the position I am in, but that’s something I will address in a future post. For now, suffice it to say that I have a decent background in Windows kernel development despite being fresh out of college.

I will write more about what I do later, but that’s the high level view for now.

Getting started

2006-03-18T04:55:00Z

I should probably rename this blog a bit since I've actually been at Microsoft for almost four months now, but the name will work for now. I have several main interests in starting this blog: talking about working at Microsoft, talking about my first job after college, and various technical topics. A lot of the blogs on this site have a lot of technical information, which is great, but I think that if I just tried to write about technical information I would have almost nothing to say (and I'd probably get corrected a lot).

So, I'll start off with some background about myself in future entries and then will try to keep the content fairly mixed. As I get more experience the balance may change, but I will always try to keep things interesting. Feel free to leave comments as long as they are kept respectful.