Cinux · 大内核的 GDT:给内核铺好段的地基如果您是想尝试 Cinux并对一些驱动、前沿细节的实现感兴趣的朋友请移步到下面的仓库https://github.com/Awesome-Embedded-Learning-Studio/Cinux如果您对手写一个现代 C 操作系统感兴趣的朋友请到这里https://github.com/Awesome-Embedded-Learning-Studio/Cinux-Book或者直接访问文档站开始阅读https://awesome-embedded-learning-studio.github.io/Cinux-Book/如果上面的内容对您的学习和实际的开发哪怕有一丝帮助都是笔者极大的荣幸喜欢的话麻烦小小的赏一个 ⭐QAQ。自己的知识仍不精湛文章必然还有很多错误还请各位大佬批评斧正本篇是 010 的上半篇。下半篇 010b 讲 IDT 与异常处理。两篇合起来,就是 big kernel 从只会打印到能扛住 CPU 异常的完整一跳。这一章我们要点亮什么跑到这里,我们的 big kernel 已经能被 mini kernel 从磁盘加载、跳进来,还能用kprintf往串口吐字。但它有个尴尬的处境:它脚下的段是别人铺的。mini kernel 为了把 big kernel 跑起来,顺手塞了一张临时 GDT 进去。那张 GDT 只够别崩,谈不上结构。这一章,我们要让 big kernel 自己建一张正式的 GDT:7 个 entry,空段、内核代码、内核数据、用户代码、用户数据各占一个,再加上占两个槽的 TSS;然后用lgdt把它交给 CPU,再借一次远跳把CS切到我们自己写的内核代码段;等一切就位,CS是0x08、DS/SS/ES是0x10,段寄存器全部指向我们定义的段。验证也很直接:make run-big-kernel-test里有一组断言,直接读CS/DS/SS/ES的值,确认它们等于我们设的选择子。段铺没铺对,机器替你检查。为什么现在需要它很多人写到 long mode 会卡在一个问题上,我们先把它的皮扒掉——“段基址在 64 位下都被忽略了,GDT 不是该退休了吗?”没退休。long mode 忽略的是段描述符里的 base 和 limit(也就是段的起始地址和长度),但选择子(selector)这东西本身仍然必需,而且后面的几乎每一章都在踩它。最直接的,CS必须指向一个有效的、L 位为 1 的长模式代码段——CPU 虽然不再看 base,但它照样要检查这个描述符的属性位:是不是 present、是不是 code、是不是 64 位。这里给错了,收获的就是一个干脆利落的 #GP。再往下,特权级的切换全靠选择子最低两位的 RPL 和 CPL,后面我们要进 ring3 跑用户程序,本质就是把CS从0x08换成0x1B,而能换的前提是 GDT 里得有对应的用户段。中断返回(IRETQ)也一样,它要恢复的CS、SS都是选择子,背后必须有有效描述符撑着。就连 TSS 也得挂在 GDT 里——任务切换、IST 中断栈切换,全靠TR指向 GDT 中的 TSS 描述符。所以结论有点反直觉:long mode 不是不要 GDT,而是 GDT 的角色从管内存分段退化成了管段属性、特权、TSS 的查表入口。地基换了种铺法,但还是地基,这一章铺的就是它。那 009 的时候为什么没崩?因为 mini kernel 留下的临时 GDT 恰好够 big kernel 用kprintf蹭两步。可一旦要碰特权级、碰中断、碰 TSS,那张临时表就不够看了——必须自己来。外部依据:Intel SDM Vol.3A 在 Segment Descriptors 一节说明,long mode 下代码段描述符的 L 位为 1 时进入 64 位模式,此时 base/limit 被视为 0/无限。OSDev 的 Global Descriptor Table 页对64 位下 GDT 的精简角色有社区视角的总结。(精确章节号我们在写完后用本地 SDM 核实,见篇末参考。)设计图先把要建的 GDT 画出来。它是一段连续内存,每 8 字节一个 entry:偏移 entry 选择子 access 用途 0x00 [ null ] — 0x00 第 0 项必须全 0(CPU 规定) 0x08 [ kernel code ] 0x08 0x9A 内核代码段,L1 长模式 0x10 [ kernel data ] 0x10 0x92 内核数据段 0x18 [ user code ] 0x1B 0xFA 用户代码段(RPL3) 0x20 [ user data ] 0x23 0xF2 用户数据段(RPL3) 0x28 [ TSS low ] ┐ 0x28 0x89 64 位 TSS,104 字节, 0x30 [ TSS high ] ┘ 跨两个 8 字节槽两个关键点先记牢:选择子 (entry 偏移) | RPL。0x08 “第 1 项,RPL0”;0x1B “第 3 项(偏移 0x18)再| 0x03” 0x1B,RPL3。选择子低 3 位里,bit 2 是 TI(0查 GDT),bit 0-1 是 RPL。TSS 占两个槽。64 位 TSS 是 104 字节,一个 8 字节描述符装不下它的 64 位 base,所以用两个连续槽:一个装 limit 低 32 位 base,一个装高 32 位 base。这就是为什么 entries 数组是7而不是 6。再看一个 8 字节段描述符的内部结构:字节: 0 1 2 3 4 5 6 7 ┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐ │ limit │ base │ base │ access │ flags │ base │ (续) │ (续) │ │ low │ low │ mid │ byte │lim hi │ high │ │ │ │ (16b) │ (16b) │ (8b) │ (8b) │ (8b) │ (8b) │ │ │ └────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘ access byte 各位(8 位): | P | DPL(2) | S | Type(4) | flags nibble(字节高 4 位): | G | D/B | L | AVL |long mode 代码段的标志组合是access0x9A、flags0xA(G1, L1)。下面我们把这几个数一行行算给你看,不是背下来的。代码路线源码主要在 gdt.hpp 和 gdt.cpp。从怎么描述一个段讲到怎么把整张表加载进 CPU。1. 用 scoped enum 描述段属性,而不是裸位操作最朴素的写法是直接拿uint8_t拼位:写个0x9A代表内核代码段。能用,但有两个毛病——写的人得记住每一位的含义,读的人更惨;而且拼错了编译器不会吱声,要等到运行时某个莫名其妙的 #GP 才暴露。Cinux 的选择是把每个属性位定义成强类型枚举(scoped enum),再用constexpr工厂函数拼成 entry:enumclassSegmentAccess:uint8_t{Present1u7,// P 位:描述符是否有效Ring00u5,// DPL 00Ring33u5,// DPL 11CodeData1u4,// S 位:1代码/数据段,0系统段(如 TSS)Executable1u3,// E:1代码段ReadWrite1u1,// RWTSS64Avail0x09,// 系统段类型:64 位可用 TSS};staticconstexprEntrysegment_entry(SegmentAccess access,SegmentFlags flags){return{.limit_low0xFFFF,.base_low0,.base_middle0,.accessstatic_castuint8_t(access),.flags_limit_highstatic_castuint8_t((static_castuint8_t(flags)4)|0x0F),.base_high0,};}好处不是好看,是编译期可验证。配合static_assert(sizeof(Entry) 8)和static_assert(sizeof(TaskStateSegment) 104),结构错位直接卡在编译期——这种错要是漏到运行时,你面对的会是一个极难定位的 #GP。选择子也用常量,不写魔法数:constexpruint16_tGDT_KERNEL_CODE0x08;constexpruint16_tGDT_KERNEL_DATA0x10;constexpruint16_tGDT_USER_CODE0x1B;constexpruint16_tGDT_USER_DATA0x23;constexpruint16_tGDT_TSS0x28;2. 7 个 entry 怎么填gdt.cpp 的init()一口气把表填好。我们把内核代码段那行拎出来算一遍:entries_[1]segment_entry(SegmentAccess::Present|SegmentAccess::Ring0|SegmentAccess::CodeData|SegmentAccess::Executable|SegmentAccess::ReadWrite,SegmentFlags::Granularity4K|SegmentFlags::LongMode);把 access 那串枚举 OR 起来:0x80 | 0x00 | 0x10 | 0x08 | 0x02 0x9A。flags 是Granularity4K(0x08) | LongMode(0x02) 0x0A,放进字节高 4 位再| 0x0F(limit 高 4 位全 1),得到0xAF。所以内核代码段描述符就是access0x9A, flags_limit_high0xAF——和设计图对上了。其余几项同理,只换属性位。内核数据段把 Executable 去掉就是0x80 | 0x10 | 0x02 0x92,flags 换成Granularity4K | Size32;用户段把 Ring0 换成 Ring3,代码段得0xFA、数据段得0xF2。顺手提一句数据段为什么用Size32而不是LongMode:数据段的 D/B 位(对应这里的 Size32)决定默认操作数和栈指针大小,内核数据段设成 32 位兼容语义即可;而 L 位(对应 LongMode)只对代码段有意义,数据段不用碰它。TSS 是个特例。它是系统段(S0),而且 64 位 TSS 的 base 是 64 位的,一个 8 字节槽装不下,得拆两个:constautotss_addrreinterpret_castuint64_t(tss_);entries_[5]tss_low_entry(tss_addr,sizeof(TaskStateSegment)-1);entries_[6]tss_high_entry(tss_addr);limit sizeof(TSS) - 1 103;access Present | TSS64Avail 0x80 | 0x09 0x89;高 32 位 base 进entries_[6]。这就是 entry 数为 7、TSS 选择子是0x28而它后面紧跟一个0x30影子槽的原因。为什么 TSS 恰好 104 字节?Intel SDM Vol.3A 的 64 位 TSS 布局图(Figure 8-11,64-Bit TSS Format)定义了它的字段:1 个保留 3 个 RSP(给 ring 0/1/2) 7 个 IST I/O 位图基址等。顺带一提,源码注释里把它写成 “Table 8-2”,但 8-2 其实是 32 位 TSS 的图(Figure 8-2),64 位 TSS 的正确编号是 Figure 8-11——这是写文档时拿本地 SDM 核实出来的一个源码注释笔误。3. load():lgdt、远跳、ltr表填好了,但 CPU 还不知道它在哪。load()干三件事:gdtr_.limitsizeof(entries_)-1;// GDTR:limit 表长 - 1gdtr_.basereinterpret_castuint64_t(entries_);__asm__volatile(lgdt %[gdtr]\n\t// ① 告诉 CPU:GDT 在这pushq %[cs]\n\t// ② 把目标 CS 压栈leaq 1f(%%rip), %%rax\n\t// 算出 1: 标号地址(之后的返回点)pushq %%rax\n\t// 压栈作为返回 RIPlretq\n\t// 远返回:弹出 CS 和 RIP → CS 被刷新1:\n\tmovw %[ds], %%ax\n\t// ③ 刷新各数据段寄存器movw %%ax, %%ds\n\t/* ... es / fs / gs / ss 同理 ... */::[gdtr]m(gdtr_),[cs]i(GDT_KERNEL_CODE),[ds]i(GDT_KERNEL_DATA):rax,memory);为什么要用push cs lretq这么绕的方式刷新CS?因为 x86-64 根本没有mov cs, ...这条指令——CS不能用mov改。能改CS的只有远跳/远返回一类(ljmp、lret)。所以这里的套路是:在栈上伪造一个远返回现场(压入目标 CS 返回地址),再用lretq把它们弹进CS/RIP,顺便跳到1:标号继续往下跑。这是加载新 GDT 后刷新 CS的标准姿势,绕不开。数据段就省事了,mov直接刷。最后挂上 TSS:constuint16_ttss_selGDT_TSS;__asm__volatile(ltr %[sel]\n\t::[sel]r(tss_sel):memory);ltr把 TSS 选择子装进TR,从此TR指向我们的 TSS。下半篇讲异常时你会发现,IST(中断栈表)就藏在这个 TSS 里——这也是 TSS 必须现在就建好的原因。验证讲完了,得能跑出来。make run-big-kernel-test会在 QEMU 里跑一组测试,其中四条直接读段寄存器:voidtest_cs_register(){uint16_tcs0;__asm__volatile(movw %%cs, %0:r(cs));TEST_ASSERT_EQ(cs,GDT_KERNEL_CODE);// 期望 0x08}DS/SS/ES同理期望0x10。要是lgdt之后忘了刷新CS、或选择子算错位,这几条断言当场挂——比在真机上莫名其妙重启友好太多了。手动看的话,make run会打印:[BIG] Big kernel running 0x1000000 [BIG] GDT loaded.看到GDT loaded.就说明init()load()一路走通。