Processor MSRs

The latest and greatest processors have greatly improved the methods through which user-mode to kernel-mode transitions are accomplished. Prior to these enhancements, most operating systems, including Windows, were forced to dedicate a soft-interrupt for exclusive use as a system call vector. Newer processors have a dedicated instruction set for dispatching system calls, such as the syscall and sysenter instructions. Part of the way in which these instructions work is by taking advantage of a processor-defined model-specific register (MSR) that contains the address of the routine that is intended to gain control in kernel-mode when a system call is received. On the x64 architecture, the MSR that controls this value is named LSTAR which is short for Long System Target-Address Register. The code associated with this MSR is 0xc0000082[1]. During boot, the x64 kernel initializes this MSR to nt!KiSystemCall64.

In order for Microsoft to prevent third parties from hooking system calls by changing the value of the LSTAR MSR, PatchGuard creates a protection sub-context of type 7 in order to cache the value of the MSR. The routine that is responsible for accomplishing this has been labeled PgCreateMsrSubContext and its prototype is shown below:

PPATCHGUARD_SUB_CONTEXT PgCreateMsrSubContext(
    IN PPATCHGUARD_CONTEXT ParentContext,
    IN UCHAR Processor);

Like the GDT/IDT protection, the LSTAR MSR value must be obtained on a per-processor basis since MSR values are inherently stored on individual processors. To support this, the routine is called in the context of a loop through all of the processors and is passed the processor identifier that it is to read from. In order to ensure that the MSR value is obtained from the right processor, PatchGuard makes use of nt!KeSetAffinityThread to cause the calling thread to run on the appropriate processor.