gpt4 book ai didi

assembly - Linux 内核从实模式到保护模式的转换

转载 作者:行者123 更新时间:2023-12-02 10:41:22 25 4
gpt4 key购买 nike

我目前正在研究操作系统的低层组织。为了实现这一目标,我试图了解 Linux 内核是如何加载的。

我无法理解的一件事是从 16 位(实模式)到 32 位(保护模式)的转换。它发生在 this file .

protected_mode_jump函数对稍后执行的 32 位代码执行各种辅助计算,然后启用 PE位在 CR0注册

    movl    %cr0, %edx
orb $X86_CR0_PE, %dl # Protected mode
movl %edx, %cr0

然后执行长跳转到 32 位代码:

    # Transition to 32-bit mode
.byte 0x66, 0xea # ljmpl opcode
2: .long in_pm32 # offset
.word __BOOT_CS # segment

据我了解in_pm32是在 protected_mode_jump 正下方声明的 32 位函数的地址:

    .code32
.section ".text32","ax"
GLOBAL(in_pm32)
# some code
# ...
# some code
ENDPROC(in_pm32)

__BOOT_CS扇区基址为 0(GDT 预先设置 here ),因此这意味着偏移量基本上应该是 in_pm32 的绝对地址。功能。

这就是问题所在。在机器代码生成期间,汇编器/链接器不应该知道in_pm32的绝对地址。函数,因为它不知道在实模式下它将被加载到内存中的哪个位置(各种引导加载程序可以占用不同数量的空间,并且实模式内核在引导加载程序之后加载)。

此外,链接器脚本(setup.ld在同一文件夹中)将代码的起源设置为0,所以看起来像in_pm32地址将是距实模式内核开头的偏移量。它应该可以很好地处理 16 位代码,因为 CS寄存器设置正确,但是当发生长跳转时,CPU已经处于保护模式,因此相对偏移不应该起作用。

所以我的问题是:如果偏移量 ( .byte 0x66, 0xea ) 是相对的,为什么保护模式 ( .long in_pm32 ) 中的长跳转会设置正确的代码位置?

似乎我错过了一些非常重要的东西。

最佳答案

看来您的问题实际上是关于存储在下一行的偏移量如何工作,因为它是相对于段的开头,而不一定是内存的开头:

 2:  .long   in_pm32         # offset

确实,in_pm32 是相对于 linker script 的偏移量而言的。用途。特别是链接描述文件具有:

. = 0;
.bstext : { *(.bstext) }
.bsdata : { *(.bsdata) }

. = 495;
.header : { *(.header) }
.entrytext : { *(.entrytext) }
.inittext : { *(.inittext) }
.initdata : { *(.initdata) }
__end_init = .;

.text : { *(.text) }
.text32 : { *(.text32) }

虚拟内存地址设置为零(随后设置为 495),因此人们会认为 .text32 部分中的任何内容都必须固定在低内存中。如果没有 protected_mode_jump 中的这些指令,这将是一个正确的观察结果:

    xorl    %ebx, %ebx
movw %cs, %bx
shll $4, %ebx
addl %ebx, 2f

[snip]

# Transition to 32-bit mode
.byte 0x66, 0xea # ljmpl opcode
2: .long in_pm32 # offset
.word __BOOT_CS # segment

末尾有一个手动编码的FAR JMP,用于将CS选择器设置为32位代码描述符,以最终完成到32位的转换保护模式。但要观察的关键是以下几行:

    xorl    %ebx, %ebx
movw %cs, %bx
shll $4, %ebx
addl %ebx, 2f

这会将 CS 中的值左移 4 位(乘以 16),然后将其添加到存储在标签 2f 中的值。这就是你采取real mode segment:offset的方式并将其转换为线性地址(在本例中与物理地址相同)。标签 2f 实际上是此行中的偏移量 in_pm32:

2:  .long   in_pm32         # offset

当这些指令完成后,FAR JMP 中的长字值 in_pm32 将通过添加当前实模式的线性地址来调整(在运行时)代码段到值in_pm32。此 .long (DWORD) 值将替换为 (CS<<4)+in_pm32。

此代码设计为可重定位到任何实模式段。最终线性地址是在FAR JMP之前的运行时计算的。这实际上是自修改代码。

关于assembly - Linux 内核从实模式到保护模式的转换,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41778188/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com