ジルコンのハイライト：vDSO（仮想動的共有オブジェクト）

ジルコン？ これは何ですか

2016年8月、Googleからの公式の発表なしで、新しいオペレーティングシステムのソースが発見されました フクシア。 このOSは、ジルコンと呼ばれるマイクロカーネルに基づいています。ジルコンは、 LK（リトルカーネル）に基づいています。

フクシアはLinuxではありません

この記事では何が議論されますか？

ZirconのvDSOは、 システムコール（syscalls）にアクセスする唯一の手段です。

しかし、コードからプロセッサ命令SYSENTER / SYSCALLを直接呼び出すことは本当に不可能ですか？ いいえ、これらのプロセッサ命令はシステムABIの一部ではありません。 ユーザーコードは、このような指示に直接従うことは禁止されています。

このようなアーキテクチャのステップに関する詳細を知りたい場合は、Catに招待します。

Zircon vDSO（仮想動的共有オブジェクト）

頭字語vDSOは、仮想動的共有オブジェクトの略です。

• 動的共有オブジェクトは、ELF形式（.soファイル）の共有ライブラリを指すために使用される用語です。
• このオブジェクトは、ファイルシステム上の既存の個別のファイルからロードされないため、仮想です。 vDSOイメージは、カーネルによって直接提供されます。

カーネルのサポート

ユーザーモードアプリケーションの唯一の制御されたABIとしてのvDSOのサポートは、2つの方法で実装されます。

1. 仮想メモリオブジェクトの投影（ VMO、仮想メモリオブジェクト ）。
   
   zx_vmar_mapがvDSOの VMOを処理する（および引数でZX_VM_PERM_EXECUTE要求される）場合、カーネルはオフセットとサイズが実行中のvDSOセグメントと厳密に一致することを要求します。 これにより、プロセスメモリへのvDSO投影が1つだけ保証されます。 プロセスへのvDSOの最初の正常な投影後、削除できなくなります。 また、vDSOをプロセスメモリに再投影しようとすると、誤ったオフセットやサイズを持つvDSOまたはプロジェクトの投影VMOを削除しようとすると、エラーZX_ERR_ACCESS_DENIED失敗します。
   vDSOコードのオフセットとサイズは、コンパイル段階でELFファイルから抽出され、カーネルコードで上記のチェックを実行するために使用されます。 vDSOプロジェクションが最初に成功した後、OSカーネルはチェックを高速化するためにターゲットプロセスのアドレスを記憶します。

   
   

2. システムコール関数のリターンアドレスを確認してください。
   
   ユーザーモードコードがカーネルを呼び出すと、低レベルのシステムコール番号がレジスタで送信されます。 低レベルシステムコールは、vDSOとZirconコア間の内部（プライベート）インターフェイスです。 一部（ほとんど）は、パブリックABIのシステムコールに直接対応しますが、そうでないものもあります。
   vDSOコードの低レベルシステムコールごとに、このコールを行うコードに固定された一連のオフセットがあります。 vDSOのソースコードは、そのような各場所を識別する内部文字を定義します。 コンパイル時に、これらの場所はvDSOシンボルテーブルから取得され、各低レベルシステムコールのコードアドレスの有効性の予測を決定するカーネルコードの生成に使用されます。 これらの述語を使用すると、vDSOコードセグメントの先頭からのオフセットが与えられると、呼び出し元のコードの有効性をすばやく確認できます。
   呼び出し元のコードがシステム呼び出しを行うことが許可されていないことが述語によって決定される場合、呼び出し元のコードが存在しないまたは特権のある命令を実行しようとしたかのように、合成例外がスローされます。

   
   

新しいプロセスを作成するときのvDSO

システムコールzx_process_startは 、新しく作成されたプロセスの最初のスレッドの実行を開始するために使用されます。 このシステムコールの最後のパラメーター（ドキュメントのarg2を参照）は、作成されたプロセスの最初のスレッドの引数を渡します。 受け入れられた合意に従って、プログラムローダーはvDSOを新しいプロセスのアドレス空間に（システムが選択したランダムな場所に）マッピングし、引数arg2を持つマッピングのベースアドレスを作成されたプロセスの最初のスレッドに転送します。 このアドレスはELFファイルのヘッダーアドレスです。これにより、システムコールを行うために必要な名前付き関数を見つけることができます。

メモリカード（レイアウト）vDSO

vDSOは一般的なEFL共有ライブラリであり、他のライブラリと同様に考えることができます。 ただし、vDSOでは、意図的にELF形式全体の小さなサブセットが選択されます。 これにはいくつかの利点があります。

• このようなELFのプロセスへのマッピングは単純であり、ELFプログラムを完全にサポートするために必要な複雑な境界ケースは含まれていません。
• vDSOの使用には、完全に機能する動的ELFバインディングは必要ありません。 特に、vDSOには動的な再配置はありません。 必要なアクションは、ELFファイルのPT_LOADセグメントを投影することだけです。
• vDSOコードはステートレスでリエントラントです。 プロセッサレジスタとスタックでのみ動作します。 これにより、最小限の制限でさまざまなコンテキストでの使用に適したものとなり、必須のABIオペレーティングシステムに準拠しています。 また、信頼性とセキュリティのコード分析と検証を簡素化します。

すべてのvDSOメモリは2つの連続したセグメントで表され、各セグメントには整列されたページ全体が含まれます。

1. 最初のセグメントは読み取り専用で、ELFヘッダーと定数データが​​含まれます。
2. 2番目のセグメントは実行可能で、vDSOコードが含まれています。

vDSOイメージ全体は、これら2つのセグメントのページのみで構成されています。 vDSOメモリを表示するには、ELFヘッダーから抽出された2つの値（各セグメントのページ数）のみが必要です。

OSブート時定数データ

一部のシステムコールは、単に定数の値を返します（値は実行時に要求する必要があり、ユーザーモードコードにコンパイルすることはできません）。 これらの値は、コンパイル時にカーネルで固定されるか、ブート時にカーネルによって決定されます（ブートパラメーターとハードウェアパラメーター）。 例： zx_system_get_version（） 、 zx_system_get_num_cpus（）およびzx_ticks_per_second（） 。 たとえば、最後の関数の戻り値は、 カーネルコマンドラインパラメーターの影響を受けます。

これらの値は一定であるため、OSカーネルへの実際のシステムコールに対して支払うことは意味がありません。 代わりに、vDSO定数セグメントから読み取られたデータを返す単純なC ++関数が実装されています。 コンパイル中にキャプチャされた値（システムのバージョン文字列など）は、単にvDSOにコンパイルされます。

ブート時に決定された値の場合、カーネルはvDSOの内容を変更する必要があります。 これは、カーネルが最初のユーザープロセスを開始する前にVMO vDSOを形成する（およびVMO記述子を渡す）早期実行可能コードを使用して行われます。 コンパイル中に、vDSOイメージ（ vdso_constants ）からのオフセットがELFファイルから抽出され、カーネルに埋め込まれます。 また、ブート中に、カーネルは自身のアドレス空間でvdso_constantsをカバーするページを一時的に表示して、正しい値で構造を事前初期化します（現在のシステム起動時）。

なぜこのすべての頭痛 ？

最も重要な理由の1つはセキュリティです。 つまり、攻撃者が任意の（シェル）コードを実行できた場合、vDSO関数を使用してシステム関数を呼び出す必要があります。 最初の障壁は、作成された各プロセスの前述のvDSOダウンロードアドレスのランダム化です。 また、OSカーネルはvDSOのVMO（仮想メモリオブジェクト）を担当するため、完全に異なるvDSOを特定のプロセスにマッピングすることを選択でき、それにより危険な（特定のプロセスには不要な）システムコールを禁止できます。 たとえば、 ドライバーが子プロセスを生成しないようにしたり、MMIOエリアの投影を処理したりできます。 これは、攻撃対象を減らすための優れたツールです。

注：現在、いくつかのvDSOのサポートが積極的に開発されています。 概念実証の実装と簡単なテストは既に存在しますが、実装の信頼性を向上させ、使用可能なオプションを決定するには、さらに作業が必要です。 現在のコンセプトでは、完全なvDSOシステムコールインターフェイスのサブセットのみをエクスポートするvDSOイメージオプションを提供しています。