深入理解BlogOS项目中的双重故障异常处理

深入理解BlogOS项目中的双重故障异常处理

blog_os Writing an OS in Rust 项目地址: https://gitcode.com/gh_mirrors/bl/blog_os

什么是双重故障？

在x86架构中，双重故障(Double Fault)是一种特殊的CPU异常，当处理器无法正常调用异常处理程序时触发。简单来说，它就像是异常处理机制中的"安全网"——当第一个异常无法被处理时，双重故障作为后备机制被触发。

双重故障与常规异常类似，它有一个特定的向量号(8)，我们可以在中断描述符表(IDT)中为其定义处理程序。处理双重故障至关重要，因为如果双重故障本身也无法处理，就会导致致命的三重故障(Triple Fault)，这将引发系统重启。

双重故障的触发场景

让我们通过一个具体例子来理解双重故障的产生：

unsafe {
    *(0xdeadbeef as *mut u8) = 42;  // 写入无效内存地址
}

这段代码尝试向未映射的内存地址0xdeadbeef写入数据，正常情况下这会触发页错误(Page Fault)。但如果IDT中没有注册页错误处理程序，CPU就无法处理这个异常，于是双重故障就被触发。

实现基础双重故障处理

在BlogOS中，我们可以这样定义一个简单的双重故障处理程序：

lazy_static! {
    static ref IDT: InterruptDescriptorTable = {
        let mut idt = InterruptDescriptorTable::new();
        idt.double_fault.set_handler_fn(double_fault_handler);
        idt
    };
}

extern "x86-interrupt" fn double_fault_handler(
    stack_frame: InterruptStackFrame, _error_code: u64) -> !
{
    panic!("双重故障发生:\n{:#?}", stack_frame);
}

这个处理程序会打印错误信息并显示异常时的栈帧。注意这个处理函数被标记为发散函数(diverging)，因为x86_64架构不允许从双重故障异常返回。

双重故障的特殊情况

虽然上述实现能处理大多数双重故障情况，但有一个重要例外——内核栈溢出。当内核栈溢出时：

1. 访问栈底保护页触发页错误
2. CPU尝试调用页错误处理程序，但需要将异常信息压栈
3. 由于栈指针仍在保护页位置，再次触发页错误
4. 导致双重故障，但处理双重故障同样需要压栈
5. 再次触发页错误，最终导致三重故障

使用中断栈表(IST)解决问题

x86_64架构提供了中断栈表(IST)机制来解决这个问题。IST是任务状态段(TSS)的一部分，包含7个预定义的栈指针。我们可以为双重故障处理程序指定一个独立的栈：

pub const DOUBLE_FAULT_IST_INDEX: u16 = 0;

lazy_static! {
    static ref TSS: TaskStateSegment = {
        let mut tss = TaskStateSegment::new();
        tss.interrupt_stack_table[DOUBLE_FAULT_IST_INDEX as usize] = {
            const STACK_SIZE: usize = 4096 * 5;
            static mut STACK: [u8; STACK_SIZE] = [0; STACK_SIZE];
            
            let stack_start = VirtAddr::from_ptr(unsafe { &STACK });
            stack_start + STACK_SIZE  // 栈向下增长，所以返回栈顶地址
        };
        tss
    };
}

然后我们需要通过全局描述符表(GDT)加载这个TSS：

lazy_static! {
    static ref GDT: (GlobalDescriptorTable, Selectors) = {
        let mut gdt = GlobalDescriptorTable::new();
        let code_selector = gdt.add_entry(Descriptor::kernel_code_segment());
        let tss_selector = gdt.add_entry(Descriptor::tss_segment(&TSS));
        (gdt, Selectors { code_selector, tss_selector })
    };
}

pub fn init() {
    GDT.0.load();
    unsafe {
        set_cs(GDT.1.code_selector);
        load_tss(GDT.1.tss_selector);
    }
}

最后，在IDT中指定使用IST栈：

idt.double_fault.set_handler_fn(double_fault_handler)
    .set_stack_index(DOUBLE_FAULT_IST_INDEX);

测试栈溢出处理

现在我们可以测试栈溢出情况：

fn stack_overflow() {
    stack_overflow(); // 无限递归
}

stack_overflow();  // 触发栈溢出

有了IST机制，即使内核栈溢出，双重故障处理程序也能在独立的栈上运行，避免三重故障的发生。

总结

在BlogOS项目中正确处理双重故障需要：

1. 在IDT中定义双重故障处理程序
2. 设置独立的中断栈表(IST)来处理栈溢出情况
3. 通过GDT加载包含IST的任务状态段(TSS)

这种机制不仅保护系统免受未处理异常的影响，还为后续开发更复杂的异常处理功能奠定了基础。理解这些底层机制对于操作系统开发者至关重要，它帮助我们构建更健壮、可靠的操作系统内核。

blog_os Writing an OS in Rust 项目地址: https://gitcode.com/gh_mirrors/bl/blog_os