《Windows内核编程第二版》英文原版解析

需积分: 5 13 浏览量更新于2024-06-14 收藏 9.47MB PDF 举报

"《Windows Kernel Programming》第二版是Pavel Yosifovich撰写的一本深入解析Windows系统的著作，特别适合那些想要学习Windows驱动基础的读者。本书提供了丰富的代码示例，有助于读者更好地理解和实践Windows内核编程。" 本书旨在帮助读者理解Windows操作系统的核心机制，包括但不限于以下几个关键知识点： 1. **进程**：书中详细介绍了进程的概念，它是系统中独立执行的程序实例，拥有自己的地址空间和资源。 2. **虚拟内存**：深入探讨了Windows如何通过虚拟内存管理技术，使得每个进程都有自己独立的地址空间，以及页表、分页和分段等概念。 3. **页面状态**：解释了内存页面的不同状态，如驻留、非驻留、交换等，以及如何根据需求动态调整内存使用。 4. **系统内存**：讨论了系统如何分配和管理物理内存，包括系统缓存、池内存等。 5. **线程**：涵盖了线程的基本概念，线程调度，以及线程栈的工作原理。 6. **线程栈**：深入分析线程栈的结构和使用，包括栈溢出和栈帧等重要概念。 7. **系统服务与系统调用**：阐述了进程如何通过系统调用来请求操作系统服务，以及系统调用的实现机制。 8. **整体系统架构**：概述了Windows操作系统的整体架构，包括用户模式和内核模式，以及它们之间的交互。 9. **句柄与对象**：详细讲解了Windows中的句柄和对象管理，如何创建、访问和销毁对象。 10. **对象命名**：介绍了对象命名的规则，以及命名空间的管理。 11. **访问现有对象**：讲述了如何安全地访问和操作已存在的系统对象，包括权限检查和对象安全性。在实践部分，本书引导读者进入内核开发的世界： 1. **安装工具**：指导读者安装必备的开发环境，如WDK（Windows Driver Kit）和其他调试工具。 2. **创建驱动项目**：详细步骤指导创建第一个驱动程序项目，设置编译和链接配置。 3. **DriverEntry和Unload例行程序**：解释了这两个关键的驱动入口点的作用和编写方法。 4. **部署驱动**：介绍驱动程序的安装和卸载过程，以及如何在目标系统上测试驱动。 5. **简单跟踪**：向读者展示了如何在驱动程序中添加简单的调试和追踪功能，以便于调试和性能分析。通过以上内容，本书不仅提供了理论知识，还强调了实践操作，让读者能够逐步掌握Windows内核编程的技能。无论你是初学者还是有经验的开发者，都能从中受益，提升对Windows内核的理解和开发能力。

Chapter 1: Windows Internals Overview 7

Each process has its own address space, which makes any process address relative, rather than absolute.

For example, when trying to determine what lies in address 0x20000, the address itself is not enough;

the process to which this address relates to must be specified.

The memory itself is called virtual, which means there is an indirect relationship between an address

and the exact location where it’s found in physical memory (RAM). A buffer within a process may

be mapped to physical memory, or it may temporarily reside in a file (such as a page file). The term

virtual refers to the fact that from an execution perspective, there is no need to know if the memory

about to be accessed is in RAM or not; if the memory is indeed mapped to RAM, the CPU will perform

the virtual-to-physical translation before accessing the data. if the memory is not resident (specified

by a flag in the translation table entry), the CPU will raise a page fault exception that causes the

memory manager’s page fault handler to fetch the data from the appropriate file (if indeed it’s a valid

page fault), copy it to RAM, make the required changes in the page table entries that map the buffer,

and instruct the CPU to try again. Figure 1-3 shows this conceptual mapping from virtual to physical

memory for two processes.

Figure 1-3: virtual memory mapping

The unit of memory management is called a page. Every attribute related to memory is always at a

page’s granularity, such as its protection or state. The size of a page is determined by CPU type (and

on some processors, may be configurable), and in any case, the memory manager must follow suit.

Normal (sometimes called small) page size is 4 KB on all Windows-supported architectures.

Apart from the normal (small) page size, Windows also supports large pages. The size of a large page is

2 MB (x86/x64/ARM64) or 4 MB (ARM). This is based on using the Page Directory Entry (PDE) to map

the large page without using a page table. This results in quicker translation, but most importantly

better use of the Translation Lookaside Buffer (TLB) – a cache of recently translated pages maintained

Chapter 1: Windows Internals Overview 8

by the CPU. In the case of a large page, a single TLB entry maps significantly more memory than a

small page.

The downside of large pages is the need to have the memory contiguous in RAM, which

can fail if memory is tight or very fragmented. Also, large pages are always non-pageable

and can only use read/write protection.

Huge pages (1 GB in size) are supported on Windows 10 and Server 2016 and later. These

are used automatically with large pages if an allocation is at least 1 GB in size, and that

size can be located as contiguous in RAM.

Page States

Each page in virtual memory can be in one of three states:

• Free – the page is not allocated in any way; there is nothing there. Any attempt to access that

page would cause an access violation exception. Most pages in a newly created process are free.

• Committed – the reverse of free; an allocated page that can be accessed successfully (assuming

non-conflicting protection attributes; for example, writing to a read-only page causes an access

violation). Committed pages are mapped to RAM or to a file (such as a page file).

• Reserved – the page is not committed, but the address range is reserved for possible future

commitment. From the CPU’s perspective, it’s the same as Free – any access attempt raises

an access violation exception. However, new allocation attempts using the VirtualAlloc

function (or NtAllocateVirtualMemory, the related native API) that does not specify a specific

address would not allocate in the reserved region. A classic example of using reserved memory

to maintain contiguous virtual address space while conserving committed memory usage is

described later in this chapter in the section “Thread Stacks”.

System Memory

The lower part of the address space is for user-mode processes use. While a particular thread is

executing, its associated process address space is visible from address zero to the upper limit as

described in the previous section. The operating system, however, must also reside somewhere – and

that somewhere is the upper address range that’s supported on the system, as follows:

• On 32-bit systems running without the increase user virtual address space setting, the operating

system resides in the upper 2 GB of virtual address space, from address 0x80000000 to

0xFFFFFFFF.

• On 32-bit systems configured with the increase user virtual address space setting, the operating

system resides in the address space left. For example, if the system is configured with 3 GB

user address space per process (the maximum), the OS takes the upper 1 GB (from address

0xC0000000 to 0xFFFFFFFF). The component that suffers mostly from this address space

reduction is the file system cache.

• On 64-bit systems running Windows 8, Server 2012 and earlier, the OS takes the upper 8 TB of

virtual address space.

Chapter 1: Windows Internals Overview 9

• On 64-bit systems running Windows 8.1, Server 2012 R2 and later, the OS takes the upper 128

TB of virtual address space.

Figure 1-4 shows the virtual memory layout for the two “extreme” cases: 32-bit process on a 32-bit

system (left) and a 64-bit process on a 64-bit system (right).

Figure 1-4: virtual memory layout

System space is not process-relative – after all, it’s the same system, the same kernel, the same drivers

that service every process on the system (the exception is some system memory that is on a per-session

basis but is not important for this discussion). It follows that any address in system space is absolute

rather than relative, since it “looks” the same from every process context. Of course, actual access

from user mode into system space results in an access violation exception.

System space is where the kernel itself, the Hardware Abstraction Layer (HAL), and kernel drivers

reside once loaded. Thus, kernel drivers are automatically protected from direct user mode access. It

also means they have a potentially system-wide impact. For example, if a kernel driver leaks memory,

that memory will not be freed even after the driver unloads. User-mode processes, on the other

hand, can never leak anything beyond their lifetime. The kernel is responsible for closing and freeing

everything private to a dead process (all handles are closed and all private memory is freed).

Threads

The actual entities that execute code are threads. A Thread is contained within a process, using the

resources exposed by the process to do work (such as virtual memory and handles to kernel objects).

The most important details a thread owns are the following:

• Current access mode, either user or kernel.

• Execution context, including processor registers and execution state.

• One or two stacks, used for local variable allocations and call management.

• Thread Local Storage (TLS) array, which provides a way to store thread-private data with

uniform access semantics.

剩余617页未读，继续阅读

jordan22

粉丝: 0
资源: 9

《Windows内核编程第二版》英文原版解析

searchsploit windows-kernel-exploits\CVE-2017-0213\CvE-2017-0213.cpp这是什么意思

nfs-kernel-server depends on nfs-common (=1:1.3.4-2.5ubuntu3.4);however: Package nfs-common is not configured yet. dpkg:error processing package nfs-kernel-server(--configure):

grubby --args=\"user_namespace.enable=1\" \--update-kernel=\"\$(grubby --default kernel)\" 语法错误

api-ms-win-downlevel-kernel32-l2-1-0

restarting nfs-kernel-server (via systemctl): nfs-kernel-server.servicejob f

api-ms-win-downlevel-kernel32-l2-1-0.dll

bcmwl-kernel-source

large-separable-kernel-attention

itext7-kernel包

最新资源