OracleVM 3.0：xen (OVMSA-2012-0020)

high Nessus 插件 ID 79476

语言：

简介

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

描述

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

- x86-64：检测服从于 AMD 勘误表 #121 的处理器并拒绝引导 (CVE-2006-0744)

- syscall/sysenter 异常生成时的客户机拒绝服务 (CVE-2012-0217)

- 创建 vm 时删除不必要的 balloon 重试这是用于缺陷 14143327 的向后移植的补丁。

- 这从 3.1.1 向后移植：作者：amisherf 放回用于防止使用 kudzu 的旧客户机在重新启动时挂起的修补程序。修复了修补程序以防止过量监视器写入，这会导致 xend、xenstored 以 100% cpu 使用率运行。现在，仅当控制台处于 Initialising、InitWait、Initialised 状态时才写入监视（在引导时发生一次）。[缺陷 13523487]

- 从上游变更集 20968 向后移植 xend：向 xenpv 设备模型通知控制台信息已就绪包含 vfb 的 PV 域有时不会启动。/sbin/kudzu 卡住。调查之后，我发现控制台的 evtchn 根本未绑定。xenpv 的 qemu-dm 中 evtchn 初始化的正常顺序为：1) 监视 xenstore backpath (/local/domain/0/backend/console/<domid>/0) 2) 读取控制台信息 (/local/domain/<domid>/console/[type, ring-ref, port..= ]) 3) 将 evtchn 绑定到端口。但在某些情况下，xend 会在准备好控制台信息之前写入到 backpath，并且再也不会写入到 backpath。因此，qemu-dm 会在 2) 发生故障并且永远不会到达 3)。发生此情况时，Domain-0 上的 xenstore-write 命令会恢复客户机。

- 将 max cstate 设置为 1。这是针对缺陷 13703504 的向后移植要求。我们发现 cstate 使系统不稳定的多个缺陷，ovm2 和 ovm3 都有：对于 OVM3.x：缺陷 13703504 - 无法解释的网络中断导致 ocfs 屏蔽服务器对于 OVM2.x