x86 IO 映射 IO 端口保护和 DOS 扩展器

Question

我正在使用 DOS Extender 为 FreeDOS 开发一个保护模式应用程序。我的应用程序执行密集的 I/O。

由于所有 DOS 扩展程序都在 Ring3（即 CPL=3）中运行他们的应用程序，而它们自己在 Ring 0（即 CPL=0）中运行，我想到了一些关于 I/O 保护的问题。

从 x86 文档中，我得到以下信息：

IOPL 敏感指令：IN、INS、OUT、OUTS、CLI 和 STI。

如果 CPL

如果 CPL > IOPL，并且指令是这些指令之一（IN、OUT、INS 或 OUTS），则处理器检查当前任务的 IO 权限位图（在其 TSS 中）以确定当前应用程序是否被允许访问寻址的 IO 端口。如果位图指示允许任务访问指示的 IO 端口，则不产生异常并执行 IO 指令。否则会产生 GP 异常。

如果 CPL > IOPL，并且指令是 CLI 或 STI，则处理器会生成 GP 异常。

这意味着如果我们的应用程序。在 Ring3 上运行，然后要执行 IN,OUT,INS,OUTS 指令，我们必须有 CPL IOPL（转换为 IOPL 任何 I/O端口。

但在后一种情况下，我们仍然不能使用 Ring3 应用程序中的 CLI 和 STI 指令，因为 CPL > IOPL。

所以，事实证明，只有当 CPL

现在我的问题是，所有 dos 扩展程序是否在它们启动的任务/应用程序的 TSS 中设置 IOPL = 3？

如果他们不这样做，那么他们必须在 Ring0 (CPL=0) 中运行任务/应用程序，否则应用程序无法执行 IOPL 敏感指令。

文档还声明：

程序或任务只能通过 POPF 和 IRET 指令改变其 IOPL； 然而，这样的改变是有特权的。 除非以特权级别 0 即 CPL=0 运行，否则任何程序都不能更改当前的 IOPL。较低特权的过程尝试更改 IOPL 不会导致异常； IOPL 保持不变。

这意味着：如果在 Ring 3 代码中遇到 POPF 或 IRET 指令，则 IOPL 字段将不会被修改/恢复，CPU 不会产生异常。

这没关系，因为我们不想修改 IOPL 字段，让它由 DOS Extender 处理。 但是这是否意味着其他标志（EFLAGS reg.的bit0到bit11）将被恢复？

我的应用程序。可能还需要执行POPF指令和IRET。

该文档还指出：

只有当 CPL

这意味着：如果在 Ring3 代码中遇到 POF 指令，则仅当 CPL

我正在寻找一个通用的答案——即不是 DOS Extender 特定的。这是因为，似乎虽然它们在实现上有所不同，但基本原则仍然是相同的 b/w DOS 扩展器——例如他们在 Ring3 中运行应用程序。

Answer 1

我不明白为什么 DOS 扩展程序会要求在 Ring 3 中运行您的应用程序代码。我认为 DPMI 规范要求这样做，但如果您的应用程序是唯一一个在运行。 This forum post 提到了一些据称在 Ring 0 中运行的扩展器：

所有已知的 Ring0 主机（DOS32/A、WDOSX、CWSDPR0）不交换 - 它是这个 只是巧合还是存在阻止 Ring0 的根本“问题” 主机交换？

来自CWSDPMI 页面：

CWSDPR0.EXE 是一个替代版本，在禁用虚拟内存的情况下在环 0 上运行。如果需要访问 ring-0 功能，可以使用它。

来自DOS/32 page：

• 受保护模式的应用程序以 CPL 0 运行

如果这些都不起作用，还有其他选择：

1. 设置您自己的保护模式 - 没那么难

2. 获取现有的 DOS 扩展程序并对其进行修改以在 Ring 0 中运行。HX-DOS 源可用，以及 a couple of others。

---

Answer 2

可能由您决定谁来负责。如果这是系统上唯一的应用程序，则可以授予它所有权限。如果有其他应用程序需要系统保护，允许一个应用程序做任何它想做的事，可能不是那么好。

在 Windows 和 Linux 等保护模式操作系统中，您需要编写设备驱动程序并将其安装在内核中以访问硬件。

我相信 POPF 指令将恢复您使用早期 PUSHF 指令保存的所有标志。只是如果您首先尝试摆弄堆栈上的位，保护规则就会生效。

如果不设置 I/O 权限位，另一个选项是拦截保护中断并根据具体情况决定是否允许应用程序读取或写入端口。在这种情况下，扩展程序可以代表应用程序执行操作，然后恢复它。虽然有点棘手...