web-dev-qa-db-ja.com

ハードウェア仮想化システムの非特権プロセスがカーネルの協力なしに「VMExit」を引き起こす可能性はありますか？

SVMまたはVT-xの場合、仮想マシンモニターに対してvmexitをトリガーする条件のセットはかなり複雑です。権限のないプロセスは、カーネルの支援なしにこれらのいずれかをトリガーできますか？ VMMCALLとVMCALLのドキュメントはどちらもリング0でしか機能しないと言っているので、大丈夫だと思います。

これは、先日のNinefingerの優れた response へのフォローアップ質問です。そこには非常に詳細があり、私が同化するのにしばらく時間がかかりました。 :)

virtualizationsandbox
8
Harry Collins

手順を理解するために必要なものは インテルソフトウェア開発者マニュアル です。それが価値があるものについて、私は時々それらを少し不透明に感じることがあります-それで私は私がグーグルで読んだものとAMDマニュアルで読んだものと対照的です、どちらもx86/x64アーキテクチャを実装しています。

具体的には、これには Vol 3C：Virtualization が必要です。現在のマニュアルでは、293ページ（「VMCALL-VM Monitorへの呼び出し）」が必要です。）には、次の役立つ式があります。

IF not in VMX operation
    THEN #UD;
ELSIF in VMX non-root operation
    THEN VM exit;
ELSIF (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)
    THEN #UD;
ELSIF CPL > 0
    THEN #GP(0);
...

英語への翻訳：#GPは一般的な保護例外であり、CPLは現在の特権レベルです。 VMX非ルート操作は次のとおりです。

VMX操作には、VMXルート操作とVMX非ルート操作の2種類があります。一般に、VMMはVMXルート操作で実行され、ゲストソフトウェアはVMX非ルート操作で実行されます。

したがって、これは、VMCall命令がguestの任意の特権レベルから発行できることを意味します。リング0の要件は、ホストシステムにのみ適用されます。しかし、私は免責事項を付けて警告します-すぐに私の意味の箇条書きを参照してください。

狂ったように狂った私は知っています。どうやら、しかし、それは本当です。 this thread を読んでください。ここでKVM=カーネル開発者はこれについて正確に説明しています。KVMパッチは問題を解決しました：

kvm_get_segment(vcpu,&cs, VCPU_SREG_CS);
if (cs.dpl != 0) {
    ret = -KVM_EPERM;
    goto out;
}

ゲストリング0から行われていない場合、「ハイパーコール」は無効と見なされます。

含意：

  1. ゲストレベルのコードは、VMCallを発行できます。しかし、私が行った非常に予備的な読みから、それはそれが何らかの方法で有用であるためにそれが（might）不可能であるかもしれないようです-リング3アドレスはおそらくゲストオペレーティングシステムの仮想WRT（したがって、ホストには何も意味しません）。私はこれが事実であると強く疑っていますが、（まだ）それを確認することはできません。
  2. あなたがそれについて考えるなら、これは理にかなっています-ゲストレベルのコードが他の種類のVM Exitをトリガーする場合、VMMが引き継ぐことを望みます。
  3. ただし、私は多くのハイパーバイザーが上記の制限を実装していると思います-リング0ゲストのみ、またはそれらが適用するハイパーコールAPIの他のいくつかの条件。
  4. ただし、そうでない場合もあります。

だから、本当にそれを掘り下げたいならあなたがする必要があるのは検証です：

  • VMMがサポートするハイパーコール（ある場合）。
  • ハイパーコールが有効と見なされる条件。私が言うように、私はVMCallがゲストリング0のみに制限されることを期待しています。

VMCall et alがリング0からのみ意味のある方法で実行できる場合は、クライアント側のゲストコードもリング0で実行できるか、既存のコードの一部に何かを実行させる必要があります。すべきではない。例えば：

  1. カーネルを説得して、VMCallを含む任意のコードを実行して、やりたいことをすべて実行することができます。
  2. VMCallを使用する既存のドライバーを説得して、通常使用するドライバーではなく、引数を使用して独自の方法で呼び出します。

エクスプロイトの成功は、ハイパーバイザーと、それらのVMCallが脆弱かどうかに完全に依存します。そうでない場合、なんとかそれらを呼び出すことができたかどうかは関係ありません。ハイパーバイザーはそれらを適切に拒否できます。この時点で、私はこのエクスプロイトルート（VMCall経由）が可能性が高いとは正直に思いません（もちろん、存在する場合、結果はかなり深刻です）。

ここで見逃した2つのこと：

  • VM Exitsには他にも多くのトリガーがあります。ゲストはを実行できますか？プログラムからではないので、考えていません-何かが原因で発生しますゲストは、オペコードに直接応答するのではなく、（VMMによって提供される出口の条件）を実行しています。
  • 繰り返しますが、VMの「脱出」は大まかな用語です。仮想マシンのユーザーは、ネットワークエミュレーションなどにも注意する必要があります-ゲストとホストがTCP/IPとホストIPスタックには脆弱性があり、ゲスト上のコードがそれを悪用する可能性があります-それでも危険にさらされる可能性があります同様に、ゲストからホストへのファイルの転送には固有のリスクがあります。
10
user2213

はい、権限のないゲストコードがVM出口をトリガーする可能性があります。

ただし、これはnotは、権限のないゲストコードがVMから抜け出す可能性があることを意味します。 VM出口がトリガーされると、仮想マシンモニターのコードに制御が移ります。 VMMコードが正しく記述されている場合、VMMコードはVM出口を安全に処理する責任があります。特に、悪意のあるゲストコードがVMから抜け出せないようにする方法です。

「VM出口」は技術用語であり、VMMに制御を移すことを意味することに注意してください。 Wordの「exit」を使用しているにもかかわらず、ゲストコードがVMから抜け出すことを意味するものではありません。これは、VMMを呼び出す方法を指しており、何らかのセキュリティ違反ではありません。 VMMにセキュリティの脆弱性がない場合、VMMがリング0（ゲスト内）で実行されているか、非特権モードで実行されているかに関係なく、ゲストコードはVMから抜け出すことができません。

したがって、あなたの質問に対する答えは「はい」ですが、最初に表示されるよりもはるかに危険性が低くなります。

4
D.W.