CPU中的“模式位”

CPU中的“模式位”

操作系统（OS）处于软件和硬件之间，它管理内存、磁盘、网络、外设，并为用户程序提供接口。但问题来了：

为什么用户程序不能直接操作硬件？为什么一定要通过操作系统？

因为硬件资源是共享的。操作系统必须防止恶意程序（或者有bug的程序）直接操作硬件，否则可能导致数据损坏、隐私泄露甚至系统崩溃。

为了实现这个隔离，处理器使用了一个非常关键的机制：CPU模式控制（mode bit）

CPU的两种运行模式

现代处理器至少支持两种运行模式：

模式	权限	举例
内核模式	可执行所有指令	OS内核、驱动、BIOS等
用户模式	禁止特权操作（如I/O）	普通程序如微信、Chrome等

这种设计是一种“硬件隔离”：即使你用C语言写了个访问硬件端口的程序，CPU也不会让你执行——因为你在用户模式中，执行不了特权指令。

模式位（Mode Bit）如何工作？

在x86架构中，控制权限的是某些控制寄存器，但在抽象层面我们可以理解为：

+----------------------------+
|         Mode Bit           |
+----------------------------+
|  0 = 用户模式（User Mode）   |
|  1 = 内核模式（Kernel Mode） |
+----------------------------+

处理器每次执行指令时会检查当前模式位，只有在内核模式下，CPU才允许执行敏感操作：

• 操作磁盘寄存器
• 修改页表
• 控制中断
• 修改系统定时器
• 重启或关闭系统

例子：用户程序访问显卡失败

假设你有一段C代码：

unsigned char* vmem = (unsigned char*) 0xB8000;
vmem[0] = 'X';

你试图通过直接写显存来在屏幕上打印字符 'X'。这在裸机环境（如操作系统开发）中有效，但在用户态运行时会出错：

Segmentation fault (core dumped)

因为地址 0xB8000 是显卡显存，操作系统不会允许你直接写这个地址，更别说现代系统早已开启虚拟内存，映射规则也不同。

那用户程序怎么访问硬件？

通过系统调用（System Call），也就是“请求内核帮忙做特权操作”。

整个过程大致如下：

用户程序（用户模式，Mode Bit = 0）
        │
        │ 触发系统调用，如 write()
        ▼
CPU触发软中断（如 INT 0x80）
        │
        ▼
CPU自动：
  - 切换到内核栈
  - 设置 Mode Bit = 1（内核模式）
  - 跳转到内核中断处理例程
        │
        ▼
内核执行 write()，将内容写入磁盘/屏幕
        │
        ▼
内核返回：
  - Mode Bit = 0（用户模式）
  - 返回用户程序继续运行

这就是所谓的“陷入（Trap）”机制，CPU在硬件上强制完成模式切换，用户程序不能伪造这一过程。

系统调用举例：write()

write(fd, "Hello", 5);

• write() 是 libc 提供的函数，看似普通函数，其实底层执行的是 syscall 或 int 0x80
• CPU自动切换到内核态执行真正的硬件写入
• 完成后返回用户态

这是为什么C语言中“标准库函数”并不等于“系统调用”：只有那些最终陷入内核的才算。

硬中断 vs 软中断

类型	触发源	举例
硬中断	硬件设备	键盘按键、鼠标移动
软中断	程序主动触发	系统调用（如 int 0x80）

两者都会进入中断处理流程，但：

• 用户程序无法触发硬中断
• 用户程序只能通过指定接口请求软中断

为什么需要硬件支持？

你可能会问：我是不是可以直接调用系统调用的汇编指令伪造操作？

不能！因为系统调用入口地址是只读的、隐藏的，而且你的用户程序根本不能修改模式位。

CPU内部电路强制规定：

• 只有通过受控中断门（Interrupt Gate）才能切入内核
• 模式位切换只能由 CPU 控制
• 用户态不能访问内核态栈或页表

内核模式危险吗？

非常危险。内核中的错误不像用户程序那样“Segfault退出”，而是直接导致整个系统崩溃（kernel panic）。

因此，驱动程序、内核模块、系统调用实现必须极度谨慎：

// 错误的驱动代码
*null_ptr = 42; // 会内核崩溃

内核态驱动程序：既强大又危险的系统组件

驱动程序（Device Driver） 是一种特殊的系统软件，它运行在 内核态（Ring 0），负责操作系统与硬件之间的通信，比如磁盘、键盘、显卡、网卡，甚至是虚拟设备（如反作弊模块）都靠驱动控制。

但驱动不仅仅用于硬件控制 —— 很多软件功能，如杀毒、调试器、虚拟机、反作弊系统等，也会以“驱动”的形式直接在内核中运行，从而获得对系统的最高访问权限。

Ring 0：驱动程序的特权地位

在现代操作系统（如 Windows、Linux）中，系统执行权限分为多个级别，称为 “环（Ring）”。

Ring 0：内核态（最高权限） → 操作系统内核、驱动程序运行于此
Ring 3：用户态（最低权限） → 应用程序（浏览器、游戏等）运行于此

处于 Ring 0 的驱动程序拥有绝对控制权，可以：

• 访问任何进程内存（包括用户态程序的数据）
• 直接调用 CPU 指令、操纵中断表（IDT）或系统服务表（SSDT）
• 控制硬件 I/O，例如读写磁盘、网络通信
• 修改内核行为或替换系统函数（Hook）

统一的内核地址空间：风险根源

内核态的驱动程序共享同一个地址空间，这意味着：

所有驱动、公用内核代码都位于同一块高地址内存区域，没有隔离。

简化内存结构（x64 架构）：

+--------------------------+
|  内核空间（共享区域）        |
|  - 操作系统核心模块         |
|  - 所有加载的驱动程序       |
+--------------------------+
|  用户空间（每进程独立）      |
|  - 进程 A                 |
|  - 进程 B                 |
+---------------------------+

这使得驱动：

• 能操作一切，但
• 一旦出错就影响全局

驱动程序出错可能导致蓝屏

因为驱动运行在核心地址空间，一旦有 bug 或错误操作，比如：

• 访问了无效内存地址（空指针或越界）
• 使用了已释放的对象
• 锁顺序错误导致死锁
• 非法操作页表或中断向量

Windows 就会立刻触发蓝屏（BSOD）来保护系统。

常见驱动相关蓝屏错误：

• IRQL_NOT_LESS_OR_EQUAL
• PAGE_FAULT_IN_NONPAGED_AREA
• KERNEL_SECURITY_CHECK_FAILURE
• DRIVER_IRQL_NOT_LESS_OR_EQUAL

驱动程序在安全软件与反作弊中的作用

许多软件会出于“系统控制”的需要，在用户同意下安装自己的驱动模块，典型包括：

1. 杀毒软件（Antivirus）

如 BitDefender、ESET、360、Windows Defender 等会安装内核驱动，以实现：

• 实时拦截系统调用（监控文件读写、网络连接）
• 检测 Rootkit、隐藏进程、非法驱动加载
• 控制防火墙规则
• 修复关键内核结构（如 SSDT、IDT）

2. 游戏反作弊系统（Anti-Cheat）

如 Vanguard（Valorant）、EasyAntiCheat（EAC）、BattlEye、XIGNCODE 等，使用驱动来：

• 拦截外挂读取游戏内存（如 NtReadVirtualMemory）
• 阻止 DLL 注入、内联 Hook
• 扫描内核模块列表，识别未签名驱动
• 禁止调试器、虚拟机运行

用户启动游戏 → 驱动加载 → 监视所有系统行为
                         ↘ 阻止注入/调试
                          ↘ 扫描非法驱动/模块

为什么它们都要用内核驱动？

• 因为外挂、病毒本身也常以驱动形式运行在内核态
• 如果反作弊/杀毒只在用户态运行，无法检测也无法阻止 Ring 0 的行为
• 所以只能用“以毒攻毒”的方式——同样用驱动进入内核，与其抗衡