自制操作系统Antz day02——进入保护模式 (上) jmp到保护模式

简介: 最近在看操作系统底层方面的东西,最开始的为什么是07c00h这个问题就让我对操作系统有了很大的兴趣。所以准备在看书之余顺便写一个操作系统(Anz)。至于为什么这个系统会被叫做Antz,可以参考Antz Uhl Kone, 日语为アインズ·ウール·ゴウン , 与之对应的还有接下来准备写的自制脚本语言A.

  Antz系统更新地址: https://www.cnblogs.com/LexMoon/category/1262287.html

  Linux内核源码分析地址:https://www.cnblogs.com/LexMoon/category/1267413.html

  Github地址:https://github.com/CasterWx

0. 如果你不知道什么是保护模式

  你可能不知道什么是保护模式,没有关系,在你知道之前让我们先来看一段代码,如果你没有接触过这些内容,可能会觉得一头雾水,不知所云,不要紧,我们可以一点一点来分析。

  os.asm :  

%include    "pm.inc"    ; 常量, 宏, 以及一些说明

org    0100h
    jmp    LABEL_BEGIN

[SECTION .gdt]
; GDT
;                                         段基址,      段界限     , 属性
LABEL_GDT:        Descriptor           0,                0, 0             ; 空描述符
LABEL_DESC_CODE32:    Descriptor           0, SegCode32Len - 1, DA_C + DA_32    ; 非一致代码段, 32
LABEL_DESC_VIDEO:    Descriptor     0B8000h,           0ffffh, DA_DRW        ; 显存首地址
; GDT 结束

GdtLen        equ    $ - LABEL_GDT    ; GDT长度
GdtPtr        dw    GdtLen - 1    ; GDT界限
        dd    0        ; GDT基地址

; GDT 选择子
SelectorCode32        equ    LABEL_DESC_CODE32    - LABEL_GDT
SelectorVideo        equ    LABEL_DESC_VIDEO    - LABEL_GDT
; END of [SECTION .gdt]

[SECTION .s16]
[BITS    16]
LABEL_BEGIN:
    mov    ax, cs
    mov    ds, ax
    mov    es, ax
    mov    ss, ax
    mov    sp, 0100h

    ; 初始化 32 位代码段描述符
    xor    eax, eax
    mov    ax, cs
    shl    eax, 4
    add    eax, LABEL_SEG_CODE32
    mov    word [LABEL_DESC_CODE32 + 2], ax
    shr    eax, 16
    mov    byte [LABEL_DESC_CODE32 + 4], al
    mov    byte [LABEL_DESC_CODE32 + 7], ah

    ; 为加载 GDTR 作准备
    xor    eax, eax
    mov    ax, ds
    shl    eax, 4
    add    eax, LABEL_GDT        ; eax <- gdt 基地址
    mov    dword [GdtPtr + 2], eax    ; [GdtPtr + 2] <- gdt 基地址

    ; 加载 GDTR
    lgdt    [GdtPtr]

    ; 关中断
    cli

    ; 打开地址线A20
    in    al, 92h
    or    al, 00000010b
    out    92h, al

    ; 准备切换到保护模式
    mov    eax, cr0
    or    eax, 1
    mov    cr0, eax

    ; 真正进入保护模式
    jmp    dword SelectorCode32:0    ; 执行这一句会把 SelectorCode32 装入 cs, 并跳转到 Code32Selector:0  处
; END of [SECTION .s16]


[SECTION .s32]; 32 位代码段. 由实模式跳入.
[BITS    32]

LABEL_SEG_CODE32:
    mov    ax, SelectorVideo
    mov    gs, ax            ; 视频段选择子(目的)

    mov    edi, (80 * 10 + 0) * 2    ; 屏幕第 10 行, 第 0 列。
    mov    ah, 0Ch            ; 0000: 黑底    1100: 红字
    mov    al, 'P'
    mov    [gs:edi], ax

    ; 到此停止
    jmp    $

SegCode32Len    equ    $ - LABEL_SEG_CODE32
; END of [SECTION .s32]

  

  pm.inc节选 :

; 描述符
; usage: Descriptor Base, Limit, Attr
;        Base:  dd
;        Limit: dd (low 20 bits available)
;        Attr:  dw (lower 4 bits of higher byte are always 0)
%macro Descriptor 3
    dw    %2 & 0FFFFh                ; 段界限 1                (2 字节)
    dw    %1 & 0FFFFh                ; 段基址 1                (2 字节)
    db    (%1 >> 16) & 0FFh            ; 段基址 2                (1 字节)
    dw    ((%2 >> 8) & 0F00h) | (%3 & 0F0FFh)    ; 属性 1 + 段界限 2 + 属性 2        (2 字节)
    db    (%1 >> 24) & 0FFh            ; 段基址 3                (1 字节)
%endmacro ; 共 8 字节

 

  读完之后你可能一头雾水,但是这段代码已经完成了实模式到保护模式的转换。

nasm os.asm -o os.com

  先使用nasm编译os.asm生成os.com文件。

  然后使用DOS-BOX打开。

    

  屏幕中显示了一个黑底红字的字符 "P"

  接下来分析上面的代码:

   [SECTION.gdt]段中有三个Descriptor,是一个叫GDT的数组。接下来的GdtLen是GDT的长度。GdtPtr也是个小的数据结构,它有6个字节,前两个字节是GDT的长度GdtLen,后四个字节是GDT的基地址。

   另外定义了两个SelectorCode32,SelectorVideo的常量。暂时可不管它。

   [BITS 16]明确指明了它是一个16位的代码段,它修改了一些GDT的值,然后执行了一些不常见的指令,最后通过jmp指令进行了跳转。jmp Selectorcode32:0 ,执行这一句会真正进入保护模式,把 SelectorCode32 装入 cs, 并跳转到 SelectorCode32:0  处 。也就是第三个section,即[SECTION.s32]中,这个段是32位的,在结束处的 jmp $ 进入了无限循环。

  你可能会疑惑什么是GDT,那些看上去怪怪的指令到底做了什么。它们的内容如下:

    1)定义一个叫做GDT的数据结构。

    2)后面的16位代码进行了一些与GDT有关的操作。

    3)程序最后跳到了32位代码中做了一点操作显存的工作。

  那么GDT是什么?它是用来干什么的呢? 程序对GDT做了什么? jmp SelectorCode32:0和我们之前的jmp有什么不同呢?

  有了这些问题,我们现在就可以出发去了解保护模式了。

 

1. GDT

  CPU有两种工作模式:实模式和保护模式。

  当我们开机时,开始的CPU是工作在实模式下的,经过某种机制之后,才进入保护模式。在保护模式下,CPU有着巨大的寻址模式,并为操作系统提供了更好的硬件模式。 那么从实模式到保护模式的转换其实就类似于政权的更替,开机时是在实模式下,就像皇帝A在执政,他有他的政策。后来通过了一种转换,类似于革命,皇帝B登基,新皇帝登基的那一刻就是一个历史性的 jmp , 然后开始了皇帝B的统治,他也有了他的一套全新的政策。当然新政策比老政策好得多,虽然他变复杂了,这套新政策就是保护模式。

  先来回顾一些旧政策,实模式。一个地址是由段地址和偏移地址两部分组成的,物理地址遵从这样的计算公式。

      物理地址 = 段地址 x 16 + 偏移地址 

  其中段值和偏移都是16位的。

  从386开始的32位时代,寻址空间可以达到4GB,所以16位寄存器已经不够用了。

  在实模式下,16位寄存器需要“段:偏移”才有 1MB的寻址能力,如今我们有了32位寄存器,一个寄存器就有了4GB的寻址哪里。那么是不是段值就可以被抛弃了呢?  

  其实不然,新政策下仍然使用 “SEG:OFFSET”的形式表示 , 只不保护模式下的段值概念发生了根本性的变化。实模式下,段值还可以看作是地址的一部分。而保护模式下,虽然段值仍然由原来的16位的CS,DS等寄存器表示,但此时他仅仅变成了一个索引,这个索引指向了一个数据结构的表项,其中详细定义了段的起始地址,界限,属性等内容。这个数据结构就是GDT(也可能是LDT)。GDT中的表项也有一个专门的名字,叫做描述符(Descriptor)。

    

  也就是说,GDT的作用是用来提供段式存储机制,这种机制是通过段寄存器和GDT中的描述符共同提供的。

  之前代码中的宏定义Descriptor这个宏用比较自动化的方法把段基址,段界限和段属性安排在描述符中合适的位置。

  再来看看之前代码中定义的一个Descriptor数组,LABEL_GDT ,LABEL_DESC_CODE32 , LABEL_DESC_VIDEO 。  

  LABEL_DESC_VIDEO的段基址0B8000h,这个描述符指向的正是显存。

  那么CS,DS等段寄存器如何与这些段对应起来呢?

  在[SECTION.32]中有两句代码是:

    mov ax,SelectorVideo

    mov gs,ax

  段寄存器gs的值变成了SelectorVideo, SelectorVideo的定义是:

    SelectorVideo  equ  LABEL_DESC_VIDEO - LABEL_GDT

  直观的看,它好像是DESC_VIDEO这个描述符相对GDT基址的偏移。实际上它有一个专门的名称叫做选择子,它也表示一个偏移,而是稍微复杂一点。

    mov  [gs:edi] , ax

  gs的值是SelectorVideo,它只是对应显存的描述符LABEL_DESC_VIDEO, 这条指令把ax的值写入显存中偏移位edi的位置。

  到了这里,可以想到,既然[SECTION.S32]是32位程序,并且在保护模式下执行,那么[SECTION.s16]的任务一定是从实模式向保护模式跳转了。

 

2. 实模式到保护模式,不一般的 jmp

  在[SECTION.s16]段最后。

  jmp dword SelectorCode32:0   ;执行这一句会把 SelectorCode32 装入 cs, 并跳转到 SelectorCode32:0 处

  跳转的目标是描述符 DESC_CODE32对应的段的首地址,即标号LABEL_SEG_CODDE32处。

  此时,新皇帝登基,开始了保护模式。

  不过,这个jmp比看起来还要复杂一点,因为它不得不放在16位的段中,目标地址却是32位。从这一点来看,它是混合16位和32位代码。所以写为jmp SelectorCode32:0 是不严谨的,因为偏移地址是32位的,这样编译出来的只是16位的代码。假设目标地址的偏移不是0,而是一个32位的值,比如 jmp SelectorCode32:0x12345678,则编译之后偏移会被截断,只剩下0x5678。

  所以需要加上dword,但Nasm允许加在整个地址之前,就是我们之前写的那样,也就是我们为什么那样写了。

  那么进入保护模式的步骤就是:

    1)准备GDT

    2)用 lgdt 加载 gdtr

    3)打开 A20

    4)  跳转,进入保护模式

 

目录
相关文章
|
算法 Unix BI
操作系统(5.2)--请求分页储存管理模式
在请求分页系统中所需要的主要数据结构是页表。为支持请求分页,须在页表中再增加若干项,供程序(数据)在换进、换出时参考。
317 0
|
2月前
|
机器学习/深度学习 Dart 前端开发
移动应用与系统:构建现代数字生态的基石在当今这个高度数字化的社会中,移动应用与操作系统已成为我们日常生活不可或缺的一部分。它们不仅改变了我们的沟通方式,还重塑了我们的工作、学习和娱乐模式。本文将深入探讨移动应用开发的基础、移动操作系统的功能以及这两者如何共同塑造了我们的数字世界。
随着智能手机和平板电脑的普及,移动应用与系统的重要性日益凸显。它们不仅为用户提供了便捷的服务和丰富的功能,还为开发者提供了广阔的创新平台。本文将介绍移动应用开发的基本概念、技术栈以及最佳实践,并探讨主流移动操作系统的特点和发展趋势。通过分析移动应用与系统的相互作用,我们可以更好地理解它们在现代社会中的重要地位。
|
1月前
|
存储 Java C语言
MacOS环境-手写操作系统-04-实模式进入保护模式
MacOS环境-手写操作系统-04-实模式进入保护模式
13 1
|
2月前
|
安全
探索操作系统的心脏:内核与用户模式的交互之旅
【9月更文挑战第12天】在数字世界的海洋中,操作系统扮演着灯塔的角色,指引着每一条数据流的方向。本文将深入探讨操作系统的核心机制——内核与用户模式,揭示它们如何协同工作以保障计算机系统的高效与安全。我们将从基础概念出发,逐步深入到实际代码示例,旨在为读者呈现一幅清晰的操作系统工作原理图景。
|
1月前
|
存储 iOS开发 C++
MacOS环境-手写操作系统-05-保护模式超强寻址
MacOS环境-手写操作系统-05-保护模式超强寻址
21 0
|
2月前
|
安全
探索操作系统的心脏:内核与用户模式的奥秘
在数字世界的海洋中,操作系统如同一艘巨轮,承载着无数数据的流动。本文将揭开这艘巨轮的核心机密——内核与用户模式,带你领略它们如何协同工作,确保系统的稳定与安全。通过浅显易懂的语言和生动的比喻,我们将一探究竟,看看这两种模式如何在幕后默默支撑着我们的日常计算体验。准备好了吗?让我们启航,深入操作系统的心脏地带!
|
3月前
|
安全 调度 开发者
探索操作系统的心脏:内核与用户模式
【8月更文挑战第30天】在数字世界的每一次跳动中,操作系统扮演着至关重要的角色。本文将深入浅出地探讨操作系统的核心概念——内核与用户模式,通过生动的比喻和直观的解释,带领读者理解这一复杂主题。我们将从内核的定义和功能出发,逐步揭示用户模式的秘密,并通过代码示例,展示如何在实际应用中区分和利用这两种模式。无论你是计算机科学的初学者还是资深开发者,这篇文章都将为你打开一扇了解操作系统深层工作原理的大门。
|
3月前
|
安全 Linux Windows
探索操作系统的心脏:内核与用户模式的奥秘
本文将深入探讨操作系统的核心组件——内核,以及它如何通过用户模式和内核模式的切换来管理资源和保护系统安全。我们将从基础概念出发,逐步深入到内核的设计原理,最后讨论现代操作系统中用户模式与内核模式的交互机制。通过这篇文章,读者将获得对操作系统内核工作原理的深刻理解,并认识到它在计算机系统中的重要性。
|
6月前
|
存储 SQL 缓存
手写操作系统(5)——CPU工作模式与虚拟地址(下)
手写操作系统(5)——CPU工作模式与虚拟地址
56 0
|
6月前
|
存储 缓存 Linux
手写操作系统(5)——CPU工作模式与虚拟地址(上)
手写操作系统(5)——CPU工作模式与虚拟地址
71 0