OracleVM 3.2：xen (OVMSA-2016-0090)

high Nessus 插件 ID 92602

语言：

简介

远程 OracleVM 主机缺少一个或多个安全更新。

描述

远程 OracleVM 系统缺少必要修补程序来解决关键安全更新：

- x86/HVM：修正 CPUID 叶 80000008 处理 - 6c733e54 xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handl ing.patch 基于上游提交：
ef437690af8b75e6758dce77af75a22b63982883 x86/HVM：
修正 CPUID 叶 80000008 处理应基于上游提交：
6c733e549889a9b8c4e03140348b8e00241d4ce9 x86/HVM：
修正 CPUID 叶 80000008 处理此修补程序中的变更为这两个修补程序之间的差异。

- x86/pv：删除 mod_l?_entry 快速路径中不安全的位可写入性和可缓存性中的所有变更都必须通过完整重新验证。作为白名单重新执行逻辑，使其更清晰以方便遵循。这是 XSA-182。

上游提交 798c1498f764bfaa7b0b955bab40b01b0610d372 Conflicts: xen/include/asm-x86/page.h

- x86/mm：完全接受客户机页表查询中的 PS 位在 L4 条目中，目前为无条件保留状态（因此在设置时，应始终会导致保留的位页面发生错误），而且会在不支持 1Gb 页面的硬件上保留（因此在设置时，应该也会在该硬件上造成保留的位页面发生错误)。这是 CVE-2016-4480/XSA-176。(CVE-2016-4480)

- x86/mm：在页表遍历器中处理 1GiB superpage。
这会允许 HAP 客户机使用 1GiB superpage。在 shadow/* 和 mm.c 中没有更多支持的情况下，阴影和 PV 客户机仍然无法使用它们。

冲突：xen/arch/x86/hvm/hvm.c xen/arch/x86/mm/guest_walk.c 从上游提交向后移植 96b740e209d0bea4c16d93211ceb139fc98d10c2 (CVE-2016-4480)

- 主要循环：可修复 Xen 设置中日志文件磁盘 DoS 的重大补丁每次主要循环来回时，我们现在会进行 fstat stderr。如果它太大，我们会在它上面进行 dup2 /dev/null。
这并不是非常完美的修补程序，但它很简单且容易看出它是正确的，并且具有较低的附带损害风险。默认限制为 1Mby，但可以通过设置新的环境变量来调整。这修复了 CVE-2014-3672。(CVE-2014-3672)

- x86：让 hvm_cpuid 容许空指针现在其他 HVM 代码已开始大量地使用 hvm_cpuid，我们不会强迫每个调用方针对不重要的输出宣告虚拟变量。

Xen/arch/x86/hvm/svm/svm.c 和 xen/arch/x86/hvm/vmx/vvmx.c 部分已经删除，因为没有源与之相符。上游提交 11b85dbd0ab068bad3beadda3aee2298205a3c01

- x86：针对隐藏的 superpage 将 GFN 限制为 32 位。
Superpage 阴影在反向指针字段中存储了隐藏的 GFN，非 BIGMEM 版本为 32 位宽。隐藏 2^44 以上的客户机物理地址的 superpage 映射，会导致 GFN 被截断，并且会在我们将阴影从哈希表删除时发生崩溃。针对每个客户机跟踪 GFN 的有效宽度，包括通过 CPUID 进行报告，以及在阴影页表中强制执行。
将客户机的最大宽度设置为 32，这是可能发生截断的宽度。这是 XSA-173。

冲突：xen/arch/x86/cpu/common.c arch/x86/mm/guest_walk.c 上游提交 95dd1b6e87b61222fc856724a5d828c9bdc30c80 (CVE-2016-3960)

- x86/HVM：修正 CPUID 叶 80000008 处理 CPUID[80000008].EAX[23:16] 已经提供客户机物理地址限制的意义（在它需要比主机小的情况下），因此，我们需要将它镜像到 vCPUID[80000008].EAX[7:0] 中。在相同的时间强制执行较低限制，以及针对虚拟地址位使用修复值，针对客户机物理地址则使用零。为了让 vMTRR 代码看到这些覆盖，我们需要使其调用 hvm_cpuid（而非 domain_cpuid），而这需要特殊设置（以及放宽）控制域。此外，这应该会隐藏工具中的排序问题：xend 和 xl 看似都会先将客户机从其映像还原，然后再于管理程序中设置 CPUID 策略，进而导致 domain_cpuid 返回所有的零，因此如果客户机之前的物理地址位数超出最小值 36，检入 mtrr_var_range_msr_set 就会失败。

冲突：xen/arch/x86/hvm/mtrr.c 上游提交 ef437690af8b75e6758dce77af75a22b63982883 (CVE-2016-3960)