Windows NT内核函数调用追踪技术研究

129 浏览量更新于2024-07-14 收藏 3.26MB PDF 举报

"Tracing Function Calls in the Windows NT Kernel - Charles University in Prague - Roman Kápl - Bachelor Thesis - 2015" 这篇博士论文详细探讨了在Windows NT内核中追踪函数调用的技术和方法。作者Roman Kápl在查尔斯大学数学与物理学院的分布式和可靠系统部门完成了这项研究，指导教师是Pavel Ježek博士，专业方向为计算机科学编程。论文的主要目标是帮助理解和分析操作系统，特别是Windows NT内核的复杂性。对于那些希望深入了解操作系统工作原理的学生和研究人员来说，这是一个宝贵的资源。函数调用跟踪是操作系统调试和性能分析的关键工具，它允许开发者监控系统级别的事件，如系统调用、内核模式函数调用，以及它们之间的交互。在Windows NT内核中，函数调用的追踪涉及到了诸如IRP（I/O请求包）处理、中断处理、线程调度等核心操作。论文可能涵盖了如何利用内核调试器（如WinDbg）和其他专门的工具来实现这一点，这些工具可以帮助捕获和分析系统中的函数调用流。此外，可能还讨论了内核模式驱动程序编程，以及如何通过编写特定的驱动程序或扩展来增强跟踪能力。论文可能包括以下内容： 1. Windows NT内核架构简介：概述内核的基本组件和服务，如执行体、调度器和内存管理。 2. 跟踪技术：介绍各种函数调用跟踪技术，如软件断点、硬件断点、事件追踪（如ETW，Event Tracing for Windows）和内核日志记录。 3. 实践应用：通过具体的案例研究展示如何在实际环境中实施函数调用追踪，以诊断问题或优化性能。 4. 法律框架：提及了作品的版权法律，指出查尔斯大学有权根据版权法规定使用该作品。 5. 实验与结果：可能包括实验设计和分析，展示了追踪功能如何帮助识别和解决操作系统中的问题。通过这篇论文，读者不仅可以了解到Windows NT内核的内部工作，还可以学习到如何有效地使用调试工具进行系统级分析，这对于系统开发者、内核程序员和性能工程师来说都是非常实用的知识。

Since the tool is fairly low-level, we will often mention mechanisms speciﬁc

to the x86 architecture, like IDT, but we will try to explain them brieﬂy when

used. Intel’s Software Developer’s Manual [

] is the complete and authoritative

reference for these topics, although it may be a bit indigestible.

2. I/O in NT kernel

In the introductory Chapter 1, some concepts like interrupt request packets or

executive objects were introduced. This chapter will explain them properly, in the

breadth that is needed for further discussion in this thesis.

The intention is not to write a device-driver development tutorial. For this

reason, the focus will be on the general concepts, not on technical details. More

advanced topics like user-mode drivers, I/O cancellation, minidrivers or Kernel

Mode Driver Framework will not be covered either. Similarly, when we talk about

ﬁelds of some data-structure, we only mention the ones that are most important

and relevant to the concepts we are explaining. Readers that want to know more,

should visit the Kernel-Mode Driver Architecture section [6] on MSDN.

The explanation will begin with the relationship between NT kernel and the

rest of the system (section 2.1). After that, the focus will move on to the topics

we have already brieﬂy mentioned in the introduction (Chapter 1), but in greater

detail, that is drivers, devices and ﬁles (section 2.2), executive objects in general

(section 2.3), driver stack (section 2.4), I/O requests (section 2.6) and the problem

of eﬃcient handling of interrupts (section 2.7). One of the topics not mentioned

in the introduction is the Plug and Play support. Althought it is an addition to

the basic I/O model, it is important for the modern system and we cover it in

section 2.8.

2.1 NT API layers

To better understand the kernel of the contemporary Windows operating system

(like Windows 8 ), let us look in the history. Windows 8 is a descendant of

Windows NT 3.1, ﬁrst publicly released in 1993. Its kernel was designed by already

experienced David Cutler, who had previously worked on the VMS operating

system. From the start it was architected to be a modern, secure, portable,

multitasking system with memory protection and still retains the same basic

design – the topics covered by this chapter were already present in the original

release of Windows, with the exception of Plug and Play support. For more

information about the historical background of Windows NT, the reader can

consult the Showstopper book [5].

One of the lesser-known facts is that NT was designed to run applications

for multiple operating systems popular at the time: OS/2, 16-bit Windows and

POSIX. Only later in the development cycle of the NT kernel did a 32-bit version

of the Windows API became the prefered way of writing applications. The

consequence is the existence of a common base layer, called Native API, an

undocumented API hosted in the

ntdll.dll

library. All the remaining APIs call

into this undocumented native layer, while the Native API in turn communicates

directly with the kernel using system calls.

The diagram of this organization is in ﬁgure 2.1. At the top layer are the

APIs intended for use by regular applications. The Windows API is the primary

one, and other APIs may rely on it for some functions. However, in the end the

Windows API passes the functions calls to the the Native API.

The Native API then performs a system call to pass the request to the kernel.

connected devices. This structure contains a pointer to the driver managing the

device, any driver-speciﬁc device data, the number of times this device is opened

and the security descriptor, identifying who can access the device.

For representing the drivers, the system uses a

DRIVER_OBJECT

structure. The

word driver can refer to either this structure, or to the code of the driver in

the form of

.sys

ﬁle, but this rarely causes confusion, since each driver has

corresponding DRIVER_OBJECT and vice versa.

For us, the most important part of the

DRIVER_OBJECT

is an array of pointers

to functions. These functions are responsible for writing to, reading from, opening

and otherwise manipulating the device managed by this driver. This array is

called the driver dispatch-table and is how the kernel communicates with the

driver. Using an analogy from C++, a driver can be thought of as a class and the

device is instance of this class.

As on most systems, before a particular ﬁle is accessed, it must be opened. On

NT this is done using the

NtCreateFile

function (corresponds to

CreateFile

Windows API ). The ﬁle to be opened is identiﬁed by a path – but in diﬀerent format

then the usual Windows/DOS path. Suppose that the user wanted to open a ﬁle

named

C:\TEST.TXT

. The ﬁle-name gets translated to

\GLOBAL??\C:\TEST.TXT

before calling NtCreateFile in the Native API.

The

\GLOBAL??\C:

is the name of the device where the ﬁle resides and is used

by NT to ﬁnd the associated

DEVICE_OBJECT

. The

GLOBAL??

preﬁx signiﬁes that

the name is a system-wide driver-letter mapping. The name translation is more

complex then described, but for our purposes we only need to know how devices

are named internally in NT.

The remainder of the path is the name of the ﬁle on the device, in this case

\TEST.TXT

. Some devices, serial port for example, do not have a ﬁle-system, but

still can be opened. In that case, the path consists only of the device name, like

\GLOBAL??\COM1

. Windows does not distinguish between ﬁles and devices in any

important ways and when we speak about open ﬁle, it can mean an open device

as well.

Each time a ﬁle on a device is opened a new structure called

FILE_OBJECT

created, to represent the open ﬁle. The structure keeps track of current ﬁle position,

the underlying device, permitted access, locks etc. Because the

FILE_OBJECT

will

be used for any subsequent I/O operations, the driver can use it to cache data

about the ﬁle for quicker access (in its FileContext member).

Since the pointer to the

FILE_OBJECT

can not be returned to the user-space

application, an identiﬁer called handle is created and the mapping from the handle

to the

FILE_OBJECT

is stored in the handle table of the calling process (similar to

ﬁle descriptor on Unix ).

Once the ﬁle is opened and the process gets a handle, it can use the handle to

perform all I/O operations, such as reading and writing. The operating system

can perform the I/O, because the

FILE_OBJECT

contains the ﬁle name and the

underlying device. When the program is done manipulating the ﬁle, it closes the

handle using NtClose and the associated FILE_OBJECT is destroyed.

2.3 Objects

The previous section 2.2 has introduced three data structures: drivers, devices

and ﬁles. They have properties in common with lot of other kernel structures.

All three are referencou-counted. Devices have names (like

\GLOBAL??\COM1

) and

their use can be restricted using security descriptors. File objects can be accessed

from user-space, using handles.

Let us look at another kernel structure - the mutex synchronization primitive.

It too can be named, accessed using handle, protected using security descriptor

and its lifetime is managed using reference-count. It makes sense to abstract these

four traits into a general structure.

This common abstraction is called an executive object (or sometimes just

object). The component of NT kernel called the object manager is responsible

for providing the common functionality. Under the hood, each executive object is

a heap-allocated data-structure, preceded by an

OBJECT_HEADER

structure that

maintains the common information.

For illustration, the memory layout is shown in 2.2, with the

FILE_OBJECT

an example. The ﬁle object starts with the common object header, identifying it as

a ﬁle object. The number of handles and pointers referencing it is also maintained

in the header. Information about the security can also be stored there, but it is

unused for a

FILE_OBJECT

. Security information only makes sense for objects that

can be opened, like devices or synchronization primitives, but the

FILE_OBJECT

already represents an opened ﬁle. User-mode components refer to the ﬁle object

indirectly, using the process handle table. The kernel-mode components can also

use handles, but have the option of referring to the object directly by the pointer.

Pointer Y

Kernel Component

…

Handle Table

Type

PointerCount

HandleCount

SecurityDescriptor

DeviceObject

ReadAccess

CurrentByteOffset

WriteAccess

...

Figure 2.2: Layout of the executive object, FILE_OBJECT in this case.

Windows uses exectuive objects as a basis for wide range of data structures,

from synchronization primitives to processes. For our purposes, executive objects

are most important as the basis for devices, drivers and open ﬁles.

剩余121页未读，继续阅读

weixin_38567956

粉丝: 1
资源: 944

Windows NT内核函数调用追踪技术研究

ftrace-kernel-hooks-2014-More than just tracing.pdf | 注释

2--tracing--avoidance-code.rar_51避障_寻迹避障 51

2HelloAttachment-ray-tracing_射线追踪_raytracing_bornvdd_raytracingm

sys/kernel/debug/tracing/trace_marker

最新资源