Multiprocessor Systems

Multiprocessor systems (sometimes known as Symmetric Multi-Processing [SMP] systems) and hyper-threaded systems come with their own unique set of problems. The major issue they pose for rootkit developers is synchronization. If you have written multi-threaded applications, you have already come to understand thread safety (we hope!), and what can happen if two threads access a data object at the same time. If you haven't, suffice it to say that if two different operations access the same data object at the same time, the data object will become corrupted. It's like having too many cooks in the kitchen!

Multiple-processor systems are like multi-threaded environments in a way, because code can be executing on two or more CPUs at once. Chapter 7, Direct Kernel Object Manipulation, covers multiprocessor synchronization.

The layout of a typical multiprocessor system is shown in Figure 3-8. As the figure illustrates, multiple CPUs share access to a single memory area, set of controllers, and group of devices.

Figure 3-8. A typical multiprocessor bus layout.

Some points to remember about multiprocessor systems:

Every CPU Has its Own Interrupt Table. If you hook the interrupt table, remember to hook it for all the CPUs! If you don't, then your hook will only apply to a single CPU. This may be intentional if you don't need to have 100% control over an interrupt but this is rare.

• A driver that works fine on a single processor system may crash (produce a Blue Screen of Death) on a multiprocessor system. You must include multiprocessor systems into your test plan.

• The same driver function can be running in multiple contexts, on multiple CPUs, simultaneously. The only way to make this safe is to use locking and synchronization with shared resources.

• Multiprocessor systems provide interlock routines, Spinlocks, and Mutexes. These are tools provided by the system to help you synchronize access to data. Details on their use can be found in the DDK documentation.

• Don't implement your own locking mechanisms. Use the tools the system already provides. If you really must do it yourself, then you must familiarize yourself with memory barriers (KeMemoryBarrier, etc.) and hardware reordering of instructions. These topics are beyond the scope of this book.

• Detect which processor you are running on. You can use a call like KeGetCurrentProcessorNumber to determine which processor your code is currently running on. You can also use KeGetActiveProcessors to determine how many active processors are in the system.

• Force execution on a specific processor. You can schedule code to be run on a particular processor. See KeSetTargetProcessorDPC in the DDK documentation.