8

I'm trying to understand the difference between SGX threads enabled by TCS and untrusted threading provided by SDK.

If I understand correctly, TCS enables multiple logical processors to enter the same enclave. Each logical processor will have its own TCS and hence its own entry point (the OENTRY field in TCS). Each thread runs until an AEX happens or reaches the end of the thread. However, these threads enabled by TCS have no way to synchronize with each other yet. At least, there is no SGX instruction for synchronize.

Then, on the other hand, the SGX SDK offers a set of Thread Synchronization Primitives, mainly mutex and condition variable. These primitives are not trusted since they're eventually served by OS.

My question is, are these Thread Synchronization Primitives meant to be used by TCS threads? If so, wouldn't this deteriorate the security? The OS is able to play with scheduling as it wishes.

4

2 に答える 2

7

最初に、やや不明確な用語について説明しましょう。

TCS によって有効化された SGX スレッドと、SDK によって提供される信頼されていないスレッド。

エンクレーブ内では、「信頼できる」スレッドのみが実行できます。エンクレーブ内には「信頼されていない」スレッドはありません。おそらく、SDK ガイド [1] の次の文が誤解を招く可能性があります。

エンクレーブ内でのスレッドの作成はサポートされていません。エンクレーブ内で実行されるスレッドは、(信頼されていない) アプリケーション内で作成されます。

信頼できないアプリケーションは、TCS ページを設定する必要があります (TCS の背景については、[2] を参照してください)。では、信頼されていないアプリケーションによって設定された TCS が、エンクレーブ内の信頼されたスレッドの基盤となるにはどうすればよいでしょうか? [2]は答えを与えます：

EENTER は、すべての TCS ページの内容が測定される場合にのみ、エンクレーブのコード内で制御されたジャンプを実行することが保証されます。

TCS ページを測定することにより、スレッドの整合性 (TCS は許可されたエントリ ポイントを定義します) をエンクレーブ構成証明によって検証できます。したがって、既知の適切な実行パスのみがエンクレーブ内で実行できます。

次に、同期プリミティブを見てみましょう。

SDK は同期プリミティブを提供しますが、これは最終的に OS によって提供されるため、信頼されるべきではありません。[1] のこれらのプリミティブの説明を見てみましょう。

  • sgx_spin_lock()と unlock はエンクレーブ内でのみ (アトミック操作を使用して) 動作し、OS との対話は必要ありません (OCALL はありません)。スピンロックを使用すると、高レベルのプリミティブを自分で実装できます。
  • sgx_thread_mutex_init()も OCALL を作成しません。ミューテックス データ構造は、エンクレーブ内で初期化されます。
  • sgx_thread_mutex_lock()と unlock は OCALLS を実行する可能性があります。ただし、mutex データはエンクレーブ内にあるため、安全なエンクレーブ内でロックの正確性を常に強制できます。

ミューテックス関数の説明を見ると、OCALL はエンクレーブ外での非ビジー待機を実装する役割を果たしていると思います。これは実際には OS によって処理され、攻撃の影響を受けやすくなります。OS は、エンクレーブの外で待機しているスレッドを起こさないことを選択する場合があります。ただし、エンクレーブ内で実行されているスレッドを中断することもできます。SGX は、(侵害された可能性のある) OS からの DoS 攻撃(サービス拒否) から保護しません。

要約すると、スピンロック (および拡張による高レベルの同期) は、エンクレーブ内で安全に実装できます。ただし、SGX は DoS 攻撃から保護しないため、スレッドが実行されるとは想定できません。これはロック プリミティブにも当てはまります。mutex で待機しているスレッドは、mutex が解放されたときに起動されない場合があります。この固有の制限を認識して、SDK 設計者は (信頼されていない) OCALL を使用して、いくつかの同期プリミティブ (つまり、ビジーでない待機) を効率的に実装することを選択しました。

[1] SGX SDK ガイド

[2] SGX の説明

于 2016-03-25T09:25:20.427 に答える