assembly - 64 位内核中读取高半地址时出现页面错误

标签 assembly nasm x86-64 paging osdev

我正在使用 Rust 和 NASM 汇编器编写一个 64 位高半内核。我使用 Multiboot2 (GRUB2) 兼容引导加载程序来最初加载我的内核。当我的内核在 QEMU 中运行时,我遇到页面错误错误(0x0e 异常),但我不明白为什么。我遇到的问题出现在我的汇编代码中,然后才到达用 Rust 编写的代码。

我正在设置分页,以便内存看起来像:

0000000000000000: 0000000000000000 --PDA---W
0000000000200000: 0000000000200000 --P-----W
ffffff0000000000: 0000000000000000 --P-----W
ffffff7f80000000: 0000000000000000 X-P------

(这既是我的意图,也是来自 QEMUinfo mem 的结果)

表格如下所示:

p4: # pml4
    0o000 <- p3_low | PRESENT | WRITABLE
    0o776 <- p3_hgh | PRESENT | WRITABLE
p3_low: # pdpte
    0o000 <- p2_low | PRESENT | WRITABLE
p3_hgh: # pdpte
    0o000 <- p2_krn | PRESENT | WRITABLE
    0o667 <- p2_mbi | PRESENT | WRITABLE
p2_low: # pde
    0o000 <- 0o000000_000_000_000_000_0000 | PRESENT | WRITABLE | PAGESIZE
    0o001 <- 0o000000_000_000_001_000_0000 | PRESENT | WRITABLE | PAGESIZE
p2_krn: # pde
    0o000 <- 0o000000_000_000_000_000_0000 | PRESENT | WRITABLE | PAGESIZE
p2_mbi: # pde
    0o000 <- 0o000000_000_000_000_000_0000 | PRESENT | PAGESIZE | NOEXEC

其他一切都归零。


我的项目的相关代码位于这些文件中:

macros64.asm:

%macro pte_write 4
    mov rax, %4
    or rax, %3
    mov qword [%1+8*%2], rax
%endmacro

paging64.asm:

extern kernel_start
extern kernel_end

p_present  equ (1<<0)
p_writable equ (1<<1)
p_user     equ (1<<2)
p_pagesize equ (1<<7)
p_noexec   equ (1<<63)

[section .text]

enable_paging:
    ; Calculate start and end address of the multiboot2 info structure.
    mov r9, rdi
    mov r10, r9
    add r10d, dword [r9]
    and r9, 0xfffffffffffff000
    shr r10, 12
    inc r10
    shl r10, 12
    ; Clear out all the page tables.
    movaps xmm1, [blank]
    mov rcx, page_tables_start
.clear_page_tables_loop:
    movaps [rcx], xmm1
    add rcx, 16
    cmp rcx, page_tables_end
    jl .clear_page_tables_loop
    ; TODO Uncomment the recursive page mappings once things actually work -- for now, they just make "info tlb" in QEMU annoying to read.
    ; Fill out the P4 table.
    pte_write p4, 0o000, p3_low, p_present | p_writable
    pte_write p4, 0o776, p3_hgh, p_present | p_writable
;   pte_write p4, 0o777, p4,     p_present | p_writable | p_noexec
    ; Fill out the P3 tables.
    pte_write p3_low, 0o000, p2_low, p_present | p_writable
;   pte_write p3_low, 0o777, p3_low, p_present | p_writable | p_noexec
    pte_write p3_hgh, 0o000, p2_krn, p_present | p_writable
    pte_write p3_hgh, 0o776, p2_mbi, p_present | p_writable
;   pte_write p3_hgh, 0o777, p3_hgh, p_present | p_writable | p_noexec
    ; Identity map the lowest 2MiB.
    pte_write p2_low, 0o000, 0o000000_000_000_000_000_0000, p_present | p_writable | p_pagesize
    pte_write p2_low, 0o001, 0o000000_000_000_001_000_0000, p_present | p_writable | p_pagesize
;   pte_write p2_low, 0o777, p2_low, p_present | p_writable | p_noexec
    ; Map the kernel.
    xor rcx, rcx
    mov rsi, kernel_start
.kernel_loop:
    pte_write p2_krn, rcx, rsi, p_present | p_writable | p_pagesize
    inc rcx
    add rsi, 0o000000_000_000_001_000_0000
    cmp rsi, kernel_end
    jb .kernel_loop
    ; Map the multiboot2 information structure.
    xor rcx, rcx
    mov rsi, r9
.mbi_loop:
    pte_write p2_mbi, rcx, rsi, p_present | p_pagesize | p_noexec
    inc rcx
    add rsi, 0o000000_000_000_001_000_0000
    cmp rsi, r10
    jb .mbi_loop
    ; Load the new page table. We don't need to flush the TLB because we moved into CR3.
    mov rax, p4
    mov cr3, rax
    ; Return.
    ret

[section .data]
align 0x10
blank: times 0x10 db 0x00

[section .bss]

alignb 4096
page_tables_start:

p4: resb 4096
p3_low: resb 4096
p3_hgh: resb 4096
p2_low: resb 4096
p2_krn: resb 4096
p2_mbi: resb 4096

page_tables_end:

start64.asm:

bits 64

extern kmain
global start64

%include "macros64.asm"
%include "paging64.asm"

[section .text]

;; The entry point for 64-bit code. We expect the address of the multiboot2
;; info structure in rdi.
start64:
    ; Save the address of the multiboot2 info structure.
    push rdi
    ; Clear interrupts. If we get an interrupt before we have an IDT, we'll
    ; triple fault. We can re-enable it from Rust, later.
    cli
    ; Nuke the segment registers.
    mov rax, 0x10
    mov ss, ax
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
    ; Set up paging.
    call enable_paging
    ; The first argument to kmain is the multiboot2 info structure. We need to
    ; adjust the address to the new higher-half location.
    pop rdi
    mov rax, 0xffffff7f80000000
    add rdi, rax
    ; DEBUG
    mov dword [0xb8004], 0xf021f021
    mov rbx, [rdi]
    mov dword [0xb8000], 0xf021f021
    hlt
    ; Call kmain. It's more than 4GiB away, so we have to do an indirect call.
    mov rax, kmain
    call rax
    ; kmain should never return; call halt if it does.
    jmp halt

halt:
    ; Write "kexit?!?" to the upper right corner.
    mov dword [0xb8000], 0x4f654f6b
    mov dword [0xb8004], 0x4f694f78
    mov dword [0xb8008], 0x4f3f4f74
    mov dword [0xb800c], 0x4f3f4f21
    ; Disable interrupts and halt.
    cli
    hlt
    ; Just in case... something? happens.
    jmp halt

将新页表移至CR3后,执行继续正确。但是,一旦我尝试从 start64.asm 中的高端内存读取值,就会出现页面错误。故障发生在这一行:

    mov rbx, [rdi]

之前的行 mov dword [0xb8004], 0xf021f021 正确地将 !! 写入屏幕。 [rdi]是可以找到Multiboot2信息记录的高半地址。

完整代码的副本可以在 my GIT repository 中找到。 .

最佳答案

我将根据我所做的另一项实验进行有根据的猜测。我怀疑,如果您向后滚动并查看抛出的异常(其中一张图像的开头被切断),您会在 QEMU 中看到如下输出:

check_exception old: 0xffffffff new 0xe
0: v=0e e=0009 i=0 cpl=0 ... [snip]

特别是,您将寻找以 new 0xe 开头的异常。这就是页面错误异常。为了简洁起见,我进行了剪裁。

在第二行,您可能会看到 e=0009 。这是在进入页面处理程序之前将被推送到堆栈上的错误代码。您没有页面处理程序,因此会出现三重错误,然后您会收到其他异常。

错误代码 0x0009 是什么意思? OSDev Wiki有描述:

31              4               0
+---+--  --+---+---+---+---+---+---+
|   Reserved   | I | R | U | W | P |
+---+--  --+---+---+---+---+---+---+

P 1 bit - Present - When set, the page fault was caused by a page-protection violation.
                    When not set, it was caused by a non-present page.
W 1 bit - Write   - When set, the page fault was caused by a page write.
                    When not set, it was caused by a page read.
U 1 bit - User    - When set, the page fault was caused while CPL = 3. This does not
                    necessarily mean that the page fault was a privilege violation.
R 1 bit - Reserved write    - When set, the page fault was caused by
                              reading a 1 in a reserved field.
I 1 bit - Instruction Fetch - When set, the page fault was caused by 
                              an instruction fetch.

您的值(value)e=0009是位掩码 01001。这意味着发生了页面保护违规(而不是页面不存在错误),并且意味着从保留字段读取了 1。

所讨论的保留字段(位)位于页表层次结构底部的页表 (PT) 的实际页表条目 (PTE) 中。使用 2MB 页面大小时 Page Attribute Tables页表中的 PTE 必须将位 12 到 20 设置为零。您当前的代码就是这种情况。保留位很特殊,因为如果它们包含值 1,那么您将得到 e=0009QEMU输出中。

要解决此问题,您必须确保实际页表 (PT) 中的页表条目 (PTE) 将这些位设置为 0。快速破解可能是在 macros64.asm 中执行类似的操作:

%macro pte_write 4
    mov rax, %4
    or rax, %3
    mov qword [%1+8*%2], rax
%endmacro

%macro pte_write_res 4
    mov rax, %4
    mov r11, 0x7fffffffffe00000
    and r11, %3
    or  rax, r11
    mov qword [%1+8*%2], rax
%endmacro

主要区别是pte_write_res通过将保留位设置为 0 来专门强制执行保留位的规则。然后您必须修改使用这些宏的代码。在您的情况下,它似乎位于 paging64.asm 内的这两个位置。 :

.kernel_loop:
    pte_write p2_krn, rcx, rsi, p_present | p_writable | p_pagesize
    inc rcx

现在会变成:

.kernel_loop:
    pte_write_res p2_krn, rcx, rsi, p_present | p_writable | p_pagesize
    inc rcx

还有

.mbi_loop:
    pte_write p2_mbi, rcx, rsi, p_present | p_pagesize | p_noexec
    inc rcx

现在会变成:

.mbi_loop:
    pte_write_res p2_mbi, rcx, rsi, p_present | p_pagesize | p_noexec
    inc rcx

在这两种情况下,我们都需要写入页表的页表条目,其中RSI可能具有我们需要设置为 0 的位。

关于assembly - 64 位内核中读取高半地址时出现页面错误,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43196609/

相关文章:

linux - execve函数的实现(unistd.h)

assembly - 16 位 x86 汇编器,使用 8 位内存存储的颜色变量在屏幕上绘制蓝色时遇到问题吗?

linux - x86 程序集从文件读取字节到堆栈但 gdb 找不到字节

linux - 在 x86 中将字符串定义为字节 (db) 和将字符串定义为字/双字 (dw/dd) 有什么区别

linux - 为什么写系统调用在 linux x86_64 (nasm) 上最后打印 `%`?

assembly - Piledriver 架构中有哪些指令集不在 Bulldozer 中?

llvm - 将 LLVM IR 分析与最终地址关联起来

macos - OS/X 64 位汇编代码生成总线错误

linux - NASM 获取参数并调用 sys_execve

linux - 如何在汇编 NASM 中打印数字?