在Linux内核中从真实模式转换为保护模式

Question

我目前正在研究操作系统的低级组织.为了实现我想要了解Linux内核是如何加载的.

我无法理解的是从16位(实模式)到32位(保护模式)的转换.它发生在这个文件中.

该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,32位函数的地址在下面声明protected_mode_jump:

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

的__BOOT_CS扇区基是0(GDT被设定预先这里),因此这意味着,偏移应该是基本上绝对地址in_pm32的功能.

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

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

所以我的问题:.byte 0x66, 0xea如果offset(.long in_pm32)是相对的,为什么Protected Mode()中的长跳设置正确的代码位置？

好像我错过了一些非常重要的东西.

Answer 1

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

 2:  .long   in_pm32         # offset

确实,这in_pm32是相对于链接器脚本使用的偏移量.特别是链接器脚本具有:

. = 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),然后将其加到存储在label处的值2f.这是您采用实模式段的方式:偏移对并将其转换为线性地址(在这种情况下与物理地址相同).Label 2f实际上是in_pm32此行中的偏移量:

2:  .long   in_pm32         # offset

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

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