操作系统/虚拟化安全知识域：系统强化之​分区

分区

除了系统在不同安全域中的结构分解（例如，分解为进程和内核）之外，受隔离原语保护，有或没有硬件支持，还有很多操作系统采用的其他技术使攻击者更难破坏TCB。在本节中，我们将讨论最突出的。在X记忆。自防止代码注入攻击，攻击者将控制权转移到他们存储在内存区域中的一系列指令，这些指令不打算包含代码这样如这叠或这堆经营系统今天画a硬线之间代码和数据。内存的每一页都是可执行的（代码页）或可写的，但不能两者兼而有之在这相同时间。这政策经常述自如WX（'写异或执行'），防止在数据区域中执行指令，但也防止修改现有代码。在没有代码注入的情况下，有兴趣转移程序的攻击者被迫自再使用法典那是已经目前。类似机制是使用自做内核中的敏感数据（如系统调用表、中断向量表等）初始化后只读。所有主要操作系统都支持此机制，通常依赖于硬件支持（尼克现代处理器中的位12）-即使详细信息略有不同，并且名称可能因操作系统而异。例如，微软通过名称来引用其实现数据执行保护(DEP).阻止内核从访问用户空间。我们有已经明显那经营系统用这中央处理器的保护环自确保那用户过程不能访问任意数据或执行操作系统中的代码，符合Saltzer&Schroeder的安全原则，该原则规定所有此类访问都要进行调解。然而有时我们还需要保护这其他方向和防止这内核从盲目访问（或更糟正在执行）中的事情用户空间。

要了解为什么这可能是不好的，请考虑一个操作系统，其中内核映射到每个进程的地址空间，每当它执行系统调用时，它都会执行使用进程页表的内核代码。这就是Linux从1991年成立到2017年12月的工作方式。原因是这样做是有效的，因为在执行系统调用时不需要切换页表，而内核可以有效地访问所有内存。此外，由于内核页设置了主管（S）位，因此不存在用户进程访问内核内存的风险。但是，假设内核有一个错误，导致它取消引用在特定情况下恰好为NULL的函数指针。最有可能发生的事情是内核崩溃。毕竟，内核正在尝试在无效的页面上执行代码。但是，如果恶意进程故意将页面映射到地址0，并用代码填充该页面，将当前进程的权限更改为该页面，该怎么办？根？在这种情况下，内核将以内核权限执行代码。这很糟糕。

现在应该很清楚  ，内核可能不应该盲目地执行进程代码。它也不应该  盲目地从用户数据中读取。毕竟，攻击者可以使用它来向内核指令提供恶意数据。为了防止此类访问，我们需要比默认环提供的隔离更多的隔离。因此，目前许多 CPU 都提供监控器模式执行保护 （SMEP）和管理引擎模式访问保护 （SMAP）13。通过在  控制寄存器中设置适当的位来启用 SMEP 和 SMAP。一旦它们处于打开状态，任何访问或将控制权转移到用户内存的尝试都将导致页面错误。当然，这也意味着每当内核需要访问用户内存时，都应显式关闭SMAP。

包括Linux  在内的一些操作系统在  2017  年对易受  Meltdown漏洞影响的系统“免费”获得了类似SMEP的限制，这迫使他们采用带有价格标签的替代设计。特别是，由于 表 1  中的 Meltdown 乱序执行  侧通道，它们被迫放弃单个地址空间（内核在  进程的地址空间  中  执行）。  回顾一下，  Meltdown（以及相关的Spectre）攻击包括攻击者滥用CPU对其  无序或投机执行的指令  中发生的事情的（过度）乐观。例如，它错误地假设  加载指令具有   读取   它们访问       的数据  的权限，分支的结果与上一次相同执行了  类似地址的分支，或者加载指令所需的数据可能是刚刚写入的此临时 CPU 缓冲区 中的数据。但是，即使这些假设中的任何一个是错误的，CPU 也可以通过压缩无序或推测执行的代码的结果来恢复。

在类似Meltdown 的攻击中，  攻击者的进程执行无序指令以读取（据说无法访问的）内核地址的字节，CPU 乐观地假设一切正常  ，只是访问字节。在  CPU意识到事情毕竟不好并且不应该访问这个字节之前，攻击者已经使用该字节在他们自己的进程地址  空间中读取大型数组中的特定元素。尽管CPU最终会压缩所有  结果，但损害  已经造成：即使  无法直接读取字节，数组元素的索引缓存中（因此，比其他元素访问速度快得多）必须是内核字节。

为了在没有针对此漏洞的硬件修复程序的较旧的处理器上解决此问题，Linux 等操作系统使用了一种将内核的页表与进程的页表完全分开的设计。换句话说  ，内核也在自己的地址空间中运行，无  序指令读取内核地址的任何尝试  都将失败。内核仍然可以映射在用户进程的页面中，从而在需要时访问它们，但权限可以不同。具体来说，如果它们被映射为不可执行，我们  基本上可以免费获得 SMEP 功能。

对于其他基于推测执行的漏洞（例如Spectre和RIDL），修复程序的问题更大。通常，使用多种不同的现场解决方案来修补最严重的问题。例如，在可能受到不受信任的用户影响的边界检查之后，我们可能希望插入特殊说明以完全停止推测。同样，Windows等操作系统试图仅“安排”  属于同一内核上同一安全域的代码（因此从线程泄漏到同一内核上的另一个线程的问题较少），而OpenBSD等其他操作系统则完全禁用英特尔处理器上的超线程。但是，目前尚不清楚补丁集的完整性，而我们正在等待硬件修复。

对  微架构状态进行分区  复杂的侧信道攻击建立在  现代计算机系统中的聚合资源共享之上。多个安全域共享相同的高速缓存、相同的  TLB、相同的  分支预测器状态、相同的算术单元等。共享有利于提高效率，但正如最小共同机制原则所指出  的那样，它们也会产生侧渠道。为了防止此类攻击，操作系统可能需要牺牲一些效率和分区资源，即使是在细粒度上也是如此。例如  ，通过在软件或基于硬件的缓存分配技术  中进行页面着色，操作系统可以使不同的进程访问完全脱节的部分缓存（例如，分离缓存集或分离缓存集中的方式）。遗憾的是，分区并不总是简单的，目前许多低级资源不支持分区。

思维导图下载：GB-T 39276-2020 网络产品和服务安全通用要求

原文始发于微信公众号（河南等级保护测评）：操作系统/虚拟化安全知识域：系统强化之​分区