Entering the kernel without a driver and getting interrupt information from APIC

Introduction

Although making user-mode application enter the kernel is definitely an exciting exercise, it is far from being something unheard of. It has been first done by Matt Pietrek (he did it on Windows 95 many years ago). His technique was later adjusted to Windows
NT by Prasad Dabak, Sandeep Phadke and Milind Borate. In order to enter the kernel right from an application, one has to set up call gate descriptor in Global Descriptor Table (GDT), so that an application can enter the kernel via the call gate. However,
once user-mode code is not allowed to access GDT, above mentioned authors used a kernel-mode driver in order to set up call gate descriptor. Certainly, quite logical question arises - what is the point of entering the kernel without a driver if you still need
a driver in order to make it work??? After all, it just defeats the purpose, don't you think?

This article describes how user-mode application can access the kernel address space and set up call gate descriptor in GDT without using a driver. It explains how virtual-to-physical address translation works on 32-bit processors, and describes how the user-mode
application can find out which physical address some given virtual address represents. "Methodology" of solving this task is 100% of my own design - you will be unable to find anything similar anywhere. This article also thoroughly explains how protection
of kernel address space is implemented by Windows NT, how the transition from non-privileged to privileged mode can be made on x86-based system, and how applications can enter the kernel without a driver.

In addition to the above, this article introduces the reader to Advanced Programmable Interrupt Controller (APIC), and explains how interrupt information can be obtained from it. This topic seems to be barely known to the Windows community, although
APIC is briefly mentioned by Mark Russinovich and David Solomon in Windows Internals, fourth edition. However, this book does not explain how to actually program APIC. I never came across any explanation of APIC programming in any Windows-focused article either
- I had to figure out everything myself from Intel manuals. Therefore, I believe this information must be of great interest to Windows developers.

To summarize, if you want to learn more about the system internals, this article is right for you.

虽然使用户模式应用程序进入内核，绝对是一个令人兴奋的经历，这是闻所未闻的东西。它已首次完成由Matt Pietrek（他很多年前在windows95实现了该技术 ）。他的技术，后来由Prasad Dabak, Sandeep Phadke 和 Milind Borate调整到Windows NT。为了从应用层进入内核，必须要在全局描述符表（GDT）设立调用门描述符，因此使应用程序可以通过调用门进入内核。然而，一旦用户模式代码是不允许访问GDT，上面提到的作者使用内核模式驱动程序才能去建立调用门描述符。当然，相当合乎逻辑的问题出现了
- 没有驱动程序进入内核，如果你还需要一个驱动程序，那么这个工作还有什么意义呢？？？毕竟，它只是失败的目的，你不觉得吗？

本文介绍了如何使 用户模式应用程序可以访问内核地址空间，并无需使用驱动程序在GDT设置调用门描述符。它解释了工作的32位处理器上虚拟到物理地址的转换，并介绍如何在用户模式应用程序可以找到一些给定虚拟地址代表的物理地址。解决这一任务的“Methodology”100％是我自己设计的， 在任何地方你将无法找到任何类似的信息。本文还详细地介绍了如何保护内核地址空间是在Windows NT中的实现，基于x86系统如何从非特权到特权模式的过渡，以及应用程序在没有驱动的情况下进入内核。

除了上述问题，本文向读者介绍了高级可编程中断控制器（APIC），并解释如何可以从中获得中断信息。在Windows交流社区这个话题似乎鲜为人知到，虽然APIC在 Windows Internals, fourth edition由Mark Russinovich和David Solomon简要提到了。然而，这本书没有解释如何实际APIC编程。在任何Windows的重点文章中我从来没有碰到任何解释APIC的编程的资料。 我必须自己从英特尔手册想出一切。因此，我相信这个信息必须是Windows开发人员的极大兴趣。

总结，如果你想了解更多有关系统内部，这篇文章是适合你的。

http://www.codeproject.com/Articles/11363/Entering-the-kernel-without-a-driver-and-getting-i