|< Day Day Up >|
In addition to being responsible for keeping track of rings, the CPU also is responsible for making many other decisions. For example, the CPU must decide what to do when an interrupt is thrown, when a software program crashes, when hardware signals for attention, when user-mode programs try to communicate with kernel-mode programs, and when multi-threaded programs switch threads. Clearly the operating system code must deal with such matters but the CPU always deals with them first.
For every important event, the CPU must figure out which software routine deals with that event. Since every software routine lives in memory, it makes sense for the CPU to store addresses for important software routines. More specifically, the CPU needs to know where to find the address of an important software routine. The CPU cannot store all of the addresses internally, so it must look up the values. It does this by using tables of addresses. When an event occurs, such as an interrupt, the CPU looks up the event in a table and finds a corresponding address for some software to deal with that event. The only information the CPU needs is the base address of these tables in memory.
There are many important CPU tables, including:
In addition to CPU tables, the operating system itself may also keep tables. These OS-implemented tables are not directly supported by the CPU, so the OS includes special functions and code to manage them.
An important OS-implemented table is:
These tables are used in a variety of ways. In the following sections, we make reference to these tables and explore how they work. We also suggest ways a rootkit developer can modify or hook these tables in order to provide stealth or to capture data.
|< Day Day Up >|