32位多任务任务段更新及同特权级切换TSS寄存器保存机制问询

你看到的「同特权级场景下寄存器不会自动保存到TSS」的描述，对应的是现代操作系统普遍采用的软件任务切换场景，和x86原生硬件任务切换的逻辑并不冲突，二者需要区分开。

1. 同特权级硬件任务切换的真实行为 #

只要触发x86定义的硬件任务切换流程（触发条件包括：CALL/JMP指令指向TSS描述符或任务门、中断/异常对应门描述符为任务门类型、IRET执行时EFLAGS的NT位为1），无论源任务和目标任务的特权级是否相同，CPU都会自动完成以下操作：

• 将当前任务的所有执行上下文（通用寄存器、段寄存器、EFLAGS、EIP、CR3控制寄存器等）完整写入当前TR寄存器指向的当前任务TSS中
• 从目标任务的TSS中读取对应上下文加载到CPU寄存器
• 更新TR寄存器指向目标任务的TSS，同时标记旧TSS为忙状态
  整个过程完全由硬件实现，不需要软件介入，不存在同特权级就跳过保存的情况。

2. OSDev相关描述的实际指代场景 #

现代操作系统几乎都废弃了硬件任务切换机制，改为软件实现任务调度，这种场景下每个CPU核心只会维护一个全局TSS，它的作用仅局限于：

• 存储特权级提升时（比如ring3用户态进入ring0内核态）需要加载的ring0栈指针
• 存储当前CPU的IO权限位图
  此时同特权级任务切换（比如两个ring3用户进程的切换）完全由操作系统内核手动完成：内核会把当前进程的上下文保存到进程专属的内存结构体（比如进程控制块PCB）里，再从目标进程的结构体中加载上下文。这个流程根本不会触发CPU的硬件任务切换逻辑，CPU自然不会自动把寄存器值写入TSS，这就是相关文档描述的实际场景。

3. TSS更新逻辑与安全风险说明 #

• 若采用原生硬件任务切换：TSS的上下文写入、加载全由CPU硬件自动完成，不需要任务自身操作。操作系统只需为每个任务分配独立的TSS，将TSS描述符的DPL设置为0（禁止用户态直接访问、修改TSS），就不会产生安全问题——用户态进程没有权限读写TSS内存，也无法随意触发任务切换，不存在上下文泄露或越权修改的风险。
• 若采用软件任务切换：全局TSS根本不需要存储用户任务的上下文，自然也不需要用户任务更新，仅由内核在必要时修改ring0栈指针等少数字段，也不会有安全风险。

内容的提问来源于stack exchange，提问作者Mark Dyks