OracleVM 3.2：xen （OVMSA-2016-0090）

high Nessus プラグイン ID 92602

Language:

概要

リモート OracleVM ホストに 1 つ以上のセキュリティ更新が欠落しています。

説明

リモートの OracleVM システムに、重要なセキュリティ更新に対処するために必要なパッチがありません。

- x86/HVM：正しい CPUID リーフ 80000008 処理 - 6c733e54 xsa173_01_0001-x86-HVM-correct-CPUID-leaf-80000008-handl ing.patch は Upstream コミットに基づきます：
ef437690af8b75e6758dce77af75a22b63982883 x86/HVM：
正しい CPUID リーフ 80000008 処理。これは、Upstream コミットに基づいていたはずです：
6c733e549889a9b8c4e03140348b8e00241d4ce9 x86/HVM：
正しい CPUID リーフ 80000008 処理。このパッチの変更は、それらの 2 つのパッチの間の相違点です。

- x86/pv：mod_l?_entry ファストパスから安全でないビットを削除します。書き込み可能性およびキャッシュ可能性のすべての変更は、完全な再検証を経る必要があります。ロジックをホワイトリストに変更して、より従いやすくします。これは XSA-182 です

Upstream コミット 798c1498f764bfaa7b0b955bab40b01b0610d372 コンフリクト：xen/include/asm-x86/page.h

- x86/mm：ゲストページテーブルウォークで PS ビットを完全に尊重。L4 エントリでは、現在無条件に予約されます（そしてこのため、設定されるときは、常に予約ビットページ違反になります）。そして 1Gb ページをサポートしないハードウェアでも予約されます（そしてこのため、こうしたハードウェアで設定される際には、同様に予約済みビットページ違反が発生します）。これは CVE-2016-4480 / XSA-176 です。（CVE-2016-4480）

- x86/mm：ページテーブルウォーカーで 1GiB スーパーページを処理します。
このため、HAP ゲストは 1GiB スーパーページを使用できます。シャドウおよび PV ゲストは、shadow/* および mm.c でさらなるサポートがないため、今でもこれらを使用できません。

コンフリクト：xen/arch/x86/hvm/hvm.c xen/arch/x86/mm/guest_walk.cUpstream コミットからバックポート 96b740e209d0bea4c16d93211ceb139fc98d10c2（CVE-2016-4480）

- メインループ：Xen 設定のログファイルディスク DoS を修正するための大変更。メインループを回すたびに、今では fstat を stderr に出力します。これは大きすぎるために dup2 /dev/null をこれに出力します。
これは、非常に美しいパッチではありませんが、非常に単純であり、正しいことがわかりやすく、付随する損害のリスクが抑えられています。この制限は、デフォルトでは 1Mby ですが、新たな環境変数を設定することで調節できます。これにより CVE-2014-3672 が修正されます。（CVE-2014-3672）

- x86：make hvm_cpuid が NULL ポインターを許容します。このため他の HVM コードが hvm_cpuid のより広範な使用を行い始めました。対応されない出力のためにダミー変数を宣言しないようにあらゆる呼び出し側に強制しないでください。

xen/arch/x86/hvm/svm/svm.c および xen/arch/x86/hvm/vmx/vvmx.c の部分は、ソースが一致しないために削除されます。Upstream コミット 11b85dbd0ab068bad3beadda3aee2298205a3c01

- x86：シャドウスーパーページのために GFN を 32 ビットに制限します。
スーパーページシャドウが、シャドウされた GFN を、非 BIGMEM ビルドが 32 ビット幅である、バックポインターフィールドに保存します。ゲストの物理アドレスが 2^44 を超えるスーパーページマッピングをシャドウすることで、GFN が切り捨てられて、そのシャドウをハッシュテーブルから削除する際に、クラッシュする可能性があります。CPUID を通じて報告することを含めて、各ゲストのために GFN の有効な幅を追跡し、シャドウページテーブルでそれを強制します。
この切り捨てが発生しそうなところで、ゲストのために最大幅を 32 に設定します。これは XSA-173 です。

コンフリクト：xen/arch/x86/cpu/common.c arch/x86/mm/guest_walk.c Upstream コミット 95dd1b6e87b61222fc856724a5d828c9bdc30c80（CVE-2016-3960）

- x86/HVM：CPUID[80000008].EAX[23:16] 処理を処理する正しい CPUID リーフ 80000008 は、（ホストのより小さい必要がある場合）ゲスト物理アドレス制限の意味を与えられました。このため我々はそれを vCPUID[80000008].EAX[7:0] にミラーする必要があります。同時に下限、仮想アドレスビットのための固定値、ゲスト物理アドレスビットのためのゼロも強制します。vMTRR コードがこれらのオーバーライドを見られるようにするために、domain_cpuid ではなく hvm_cpuid を呼び出すようにする必要があります。これはコントロールドメインの特別なケーシング（およびリラクシング）を必要とします。これはさらにツールの順序問題を隠すはずです：ハイパーバイザーで CPUID ポリシーを設定する前に xend と xl の両方がゲストをそのイメージから復元するように見え、ゲストに以前に最小の 36 物理アドレスビットを超えるビット数がある場合に、domain_cpuid が全てゼロを戻すために、mtrr_var_range_msr_set のチェックが失敗します。

コンフリクト：xen/arch/x86/hvm/mtrr.c Upstream コミット ef437690af8b75e6758dce77af75a22b63982883（CVE-2016-3960）