AMD 64 位模式下的段限制检查
我正在为 64 位处理器编写自己的操作系统，但我遇到了一般保护的问题。我的操作系统不会依赖页面错误来实现用户空间保护机制，因此我发现有一种方法可以通过段限制检查来实现：
VMWare 的演示
http://download3.vmware.com/vmworld/2005/pac346.pdf
第 20 页说道：
初始 AMD64 架构不包括 64 位模式下的分段
- EMT64T 也缺少分段
我们如何保护 VMM？
- 64 位访客支持需要额外的硬件帮助
- 在较新的 AMD 处理器上可在 64 位模式下进行段限制检查
现在，我有较新的 AMD 处理器型号，我的问题是如何在 64 位 AMD 处理器上实现限制段限制检查（长）模式？我已经下载了 2011 年 9 月版（最新）的开发人员手册，但在任何地方都找不到如何执行此操作，请帮忙。
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为他们可能正在谈论 LMSLE 位 13）。 amd.com/documentation/guides/Pages/default.aspx" rel="nofollow">第 2 卷 3.1.7 页。 55。第 114 页的“4.12.2 64 位模式下的数据限制检查”对此进行了更详细的描述。请注意，
EFER是特定于模型的寄存器（更多信息请参见“6.2.5 访问型号特定寄存器”第 156 页也在第 2 卷中）。I think they're probably talking about the Long Mode Segment Limit Enable bit (
LMSLEbit 13) in the "Extended Feature Enable Register" (EFER) in Volume 2 3.1.7 pg. 55. It is describe in a little more detail in "4.12.2 Data Limit Checks in 64-bit Mode" on page 114. Note thatEFERis a model-specific register (more in "6.2.5 Accessing Model-Specific Register" pg. 156 also in volume 2).分段是一种古老且非常缓慢的实现内存保护的方法。即使它问世了，也没有人使用它，因为它太慢了——英特尔发明了它，但实际上并没有与操作系统供应商交谈，看看他们首先想要什么。您确实需要像其他现代操作系统一样使用页面错误。
Segmentation is an old and very slow way to implement memory protection. Even when it came out, nobody used it because it was too slow - Intel invented this but didn't actually talk to OS vendors to see what they wanted first. You really need to use page faulting like other modern operating systems.
尽管这并没有回答问题，但这与删除 64 位模式下的段限制检查有关，据说在没有硬件虚拟化的情况下，“不可能”保护虚拟机管理程序陷阱处理程序，这是人们可能希望看到这个问题标题的讨论。我同意“打破一些现有的实现”，但并非“不可能”。
我看到了这一切，但我不相信。您不需要分段来保护虚拟机管理程序陷阱处理程序或 IDT。您可以通过分页来做到这一点。
使 SPT 中的某个虚拟地址范围始终映射虚拟机管理程序陷阱处理程序，并将 IDT 映射到主机上的虚拟地址。 IDT 需要 1 个 4KiB 页。 SPT 中的这些页面被设置为管理程序，这意味着环 1 中的来宾内核无法写入它们，因为这会导致映射到来宾的 IDT 陷入陷阱。现在响0，代码就可以执行了。当来宾对这些保留的虚拟地址范围进行读/写时，它需要不知道它是被保留的，即管理程序驱动程序默默地将对某些 CR3 的访问重定向到干净的页面。来自环 1 客户内核的读/写将导致 GPF，并且 CR2 将包含尝试写入的地址。通常，页面出现故障，然后推送的 RIP 是要重新尝试的指令，但在这种情况下不能这样做。它需要在陷阱帧中的 RIP 处解码并执行读/写操作，将其自身转换为新的主机物理页，方法是使用专门为来宾修改 PTE 时构建的保留区域的特殊内部表进行翻译，然后增加 RIP 。
Although this doesn't answer the question, this is related to removal of segment limit checks in 64 bit mode supposedly making protection of hypervisor trap handlers 'impossible' without hardware virtualisation, which is a discussion people may expect to see seeing this question title. 'breaking some existing implementations' I agree with, but not 'impossible'.
I see this all over but I'm not convinced. You don't need segmentation to protect hypervisor trap handlers or the IDT. You can do it with paging.
Make a certain virtual address range in the SPT always map the hypervisor trap handlers, and the IDT at the virtual address it is at on the host. The IDT requires 1 4KiB page. These pages in the SPT are made supervisor, meaning the guest kernel in ring 1 cannot write to them because it will cause a trap right into the IDT which is mapped into the guest. Now ring 0, the code can be executed. When the guest does read/write to those reserved virtual address ranges, it needs to be unaware that it is reserved, i.e. the hypervisor driver silently redirects the accesses with certain CR3s to a clean page. A read/write from a ring 1 guest kernel will cause a GPF, and the CR2 will contain the address that was attempted to be written to. Usually, the page is faulted in and then the RIP pushed is of the instruction to be reattempted, but it can't do this in this case. It needs to decode and perform the read/write itself at the RIP in the trap frame to a new host physical page by translating it using a special internal table purely for those reserved regions built when the guest modifies the PTEs, and then increase the RIP.