assembly - 您将操作系统源代码汇编或编译成什么格式?

标签 assembly operating-system binaryfiles fasm

一般来说,在编写内核和操作系统时,无论是汇编还是更高级别的内容,您都需要以平面二进制形式汇编或编译代码,对吗?

您无法将其汇编或编译为 ELF 格式或类似格式,对吗?

如果这样做,处理器会将格式误解为代码并开始执行非预期指令。

毕竟,您格式化可执行二进制文件,以便操作系统知道代码和日期段在哪里开始和停止,然后可以将它们加载到 GDT 中并将它们添加到分页结构中。

但是,如果您正在编写的程序实际上是一个操作系统,那么它就不会像用户应用程序那样在操作系统上运行,因为它操作系统,对吗?

也就是说,操作系统在金属上运行,而不是在任何其他软件上运行。

我的说法正确吗?

最佳答案

某种程度上,每个平台都有自己的启动顺序,这也定义了用户如何获得对机器的控制。

例如,在 x86 世界中,第一个代码运行来自 BIOS ROM(来自主板供应商的硬连线固件),然后它将加载初始引导加载程序(存储 block 设备上的扇区 0,因此 BIOS 固件必须已经包含一些简单/完整的内容)适用于各种不同设备的驱动程序 = 这不是某种微不足道的指令来预热 PC,而是一个小型操作系统本身)。然后引导加载程序将处理剩余代码的进一步加载(扩展引导加载程序代码,如果它不适合单个扇区或内核或用户提供的任何内容)。

因此,如果您的引导加载程序足够复杂,它甚至可以理解内核的 ELF 二进制文件,并从中加载它。

但是,只要您追踪到要运行的最初始代码(x86 PC 上的 BIOS 固件),那么该代码就必须是平面二进制文件,在某个指定地址处开始代码(由 CPU/主板供应商定义,具体取决于RST信号后CPU的状态)。

此外,操作系统可能已经太晚进入该过程,因此它不能保证它直接在裸机上运行,​​它可能已经进入了一些虚拟化环境。通常可以检测到它,但通过完美仿真/虚拟化,它可能无法检测到(话又说回来,在计算机世界中实现完美往往非常难以捉摸)。但从操作系统的角度来看,这并没有改变任何东西(*),它仍然可以像在裸机上运行一样继续进行,这取决于仿真/虚拟化是否能够 catch 并达到操作系统的期望。

*)实际上,对于安全敏感的安装来说,检测对环境的任何篡改并处理此类情况以减轻安全风险( self 破坏或删除敏感信息)可能非常重要。


更新:还支持 UEFI(现代 BIOS)、TPM(可信平台模块)芯片、IME(英特尔管理引擎)的现代主板,初始平面二进制文件可以加密并进行数字签名,因此 CPU 不会执行它除非解密和签名验证成功。

对于IME,情况更加复杂,就像计算机中的计算机一样,因此即使包装x86机器没有唤醒(只是处于待机状态),后台也可能会发生一些事情。

如果您刚刚开始研究操作系统开发,请不要担心这一点。如果您计划创建一些基于 x86 的安全/医疗设备,那么可能要额外注意这些。

关于assembly - 您将操作系统源代码汇编或编译成什么格式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46305007/

相关文章:

assembly - MIPS bne beq 计算机组织与设计

c - ASM 约束副作用

c - 服务器从客户端接收到一些垃圾值?

scala - 在 Spark Scala 中读取二进制文件

assembly - 为什么取消引用 `Arc<T> where T : MyTrait` 对齐到 0x10?

c - 在平面二进制文件中包含 char 数组的内容

operating-system - 存储和检索进程控制 block

user-interface - GUI是如何真正制作的?

c++ - 我可以对文件进行无格式写入,然后对整数类型的文件进行格式化读取吗?

arrays - Base64编码的字符串到二进制文件