Intel Software Guard Extensionsチュートリアル パート4、飛び地の設計

Intel Software Guard Extensions（Intel SGX）に関する一連のトレーニング資料の第4部では、飛び地とそのインターフェースを作成します。 第3部で定義されたエンクレーブの境界を検討し、ブリッジの必要な機能を決定し、ブリッジの機能がオブジェクトモデルに及ぼす影響を検討し、エンクレーブをアプリケーションに統合するために必要なプロジェクトインフラストラクチャを作成します。 ECALLエンクレーブの代わりに、これまでスタブを使用しています。 このシリーズの第5部では、飛び地の完全な統合に進みます。







シリーズのこの部分に加えて、ソースコードが提供されています。エンクレーブスタブとインターフェイス関数。 このコードはダウンロード可能です。

アプリケーションアーキテクチャ

エンクレーブインターフェイスを設計する前に、アプリケーションの全体的なアーキテクチャについて考える必要があります。 第1部で説明したように、エンクレーブはダイナミックリンクライブラリ（Windows *ではDLL、Linux *では共有ライブラリ）として実装され、100％ネイティブCコードとのみリンクする必要があります。



同時に、チュートリアルパスワードマネージャープログラムのグラフィカルユーザーインターフェイスはC＃で記述されています。 C ++ / CLIで記述された混合アセンブリは、マネージコードからアンマネージコードに切り替えるために使用されますが、このアセンブリには独自のコードが含まれていますが、100％ネイティブコードで構成されていないため、Intel SGXエンクレーブと直接やり取りすることはできません。 信頼できないエンクレーブブリッジ関数をC ++ / CLIアセンブリに導入しようとすると、致命的なエラーが発生します。

Command line error D8045: cannot compile C file 'Enclave_u.c'; with the /clr option
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、信頼できないブリッジの機能は、完全にネイティブコードで構成される別のDLLライブラリに配置する必要があります。 その結果、アプリケーションには少なくとも3つのDLLが含まれます。C++ / CLIコア、エンクレーブブリッジ、およびエンクレーブ自体です。 この構造を図に示します。 1。









図1.エンクレーブを含む混合アプリケーションのコンポーネント。

さらなる洗練

エンクレーブブリッジの関数は別のDLLライブラリにある必要があるため、次のステップを実行します。エンクレーブと直接対話するすべての関数をこのライブラリに入れます。 このアプリケーションレベルの分離は、プログラム管理とデバッグを簡素化し、他のモジュールへの影響を減らすことで統合の利便性を高めます。 クラスまたはモジュールが明確に定義された境界で特定のタスクを実行する場合、他のモジュールへの変更が影響を与える可能性は低くなります。



私たちの場合、 PasswordManagerCoreNativeクラスは、エンクレーブインスタンスを作成する追加のタスクを負担するべきではありません。 このクラスは、対応する機能を実行するために、Intel SGX拡張プラットフォームがサポートしている場合にのみ知る必要があります。



例として、次のコードフラグメントはunlock（）メソッドを示しています。

 int PasswordManagerCoreNative::vault_unlock(const LPWSTR wpassphrase) { int rv; UINT16 size; char *mbpassphrase = tombs(wpassphrase, -1, &size); if (mbpassphrase == NULL) return NL_STATUS_ALLOC; rv= vault.unlock(mbpassphrase); SecureZeroMemory(mbpassphrase, size); delete[] mbpassphrase; return rv; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは非常に簡単な方法です。ユーザーのパスフレーズをwchar_tの形式で受け取り、可変長エンコード（UTF-8）に変換してから、ストレージオブジェクトでunlock（）メソッドを呼び出します。 このクラスとこのメソッドをエンクレーブ関数で乱雑にする代わりに、1行追加してこのメ​​ソッドにエンクレーブサポートを追加することをお勧めします。

 int PasswordManagerCoreNative::vault_unlock(const LPWSTR wpassphrase) { int rv; UINT16 size; char *mbpassphrase = tombs(wpassphrase, -1, &size); if (mbpassphrase == NULL) return NL_STATUS_ALLOC; // Call the enclave bridge function if we support Intel SGX if (supports_sgx()) rv = ew_unlock(mbpassphrase); else rv= vault.unlock(mbpassphrase); SecureZeroMemory(mbpassphrase, size); delete[] mbpassphrase; return rv; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちの目標は、このクラスを飛び地で最大限に働くことから解放することです。 PasswordManagerCoreNativeクラスに必要なその他の追加には、Intel SGXフラグのサポートと、このフラグを設定および受信するためのメソッドが含まれます。

 class PASSWORDMANAGERCORE_API PasswordManagerCoreNative { int _supports_sgx; // Other class members ommitted for clarity protected: void set_sgx_support(void) { _supports_sgx = 1; } int supports_sgx(void) { return _supports_sgx; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンクレーブデザイン

アプリケーションの一般的な計画の準備ができているので、エンクレーブとそのインターフェースを設計できます。 これを行うために、アプリケーションカーネルのクラスダイアグラムに戻ります。これについては、最初に第3部で説明しました。これを図に示します。 2.囲まれたオブジェクトは緑色で、信頼できないコンポーネントは青色で網掛けされます。









図2. Intel Software Guard Extensionsを使用したチュートリアルPassword Managerのクラス図。



エンクレーブの境界を越える接続は1つだけです。PasswordManagerCoreNativeオブジェクトとVaultオブジェクト間の接続です。 つまり、ほとんどのECALLは、単にVaultのクラスメソッドのラッパーになります。 エンクレーブインフラストラクチャを管理するには、追加のECALLも追加する必要があります。 エンクレーブの開発における困難の1つは、ECALL、OCALL、およびブリッジ関数がネイティブCコードでなければならず、C ++コンポーネントを広範囲に使用することです。 エンクレーブを開始した後、CとC ++の間のギャップを埋める関数（オブジェクト、コンストラクター、オーバーロードなど）も必要になります。



ブリッジのシェルと機能は、EnclaveBridge.dllと呼ばれる独自のDLLにあります。 明確にするために、シェル関数に接頭辞「ew _」（エンクレーブラッパー-エンクレーブシェル）を提供し、ECALLを構成するブリッジ関数に接頭辞「ve _」（ボールトエンクレーブ-エンクレーブストレージ）を提供します。



PasswordManagerCoreNativeからVaultの対応するメソッドへの呼び出しは、図に示すパスに従います。 3。









図3.ブリッジおよびECALL機能を実行するためのパス。



PasswordManagerCoreNativeのメソッドは、EnclaveBridge.dllのラッパー関数を呼び出します。 このシェルは、エンクレーブに入り、 Vaultオブジェクト内の対応するクラスメソッドを呼び出す1つ以上のECALLを呼び出します。 すべてのECALLが完了すると、ラッパー関数はPasswordManagerCoreNativeの呼び出しメソッドに戻り、戻り値を提供します。

物流エンクレーブ

エンクレーブを作成するときは、まずエンクレーブ自体を管理するシステムを決定する必要があります。 エンクレーブが実行されていて、結果のエンクレーブ識別子がECALL関数に提供されている必要があります。 理想的には、これらはすべてアプリケーションの上位レベルに対して透過的でなければなりません。



チュートリアルパスワードマネージャーの最も簡単なソリューションは、EnclaveBridge DLLのグローバル変数を使用してエンクレーブ情報をホストすることです。 このような決定には制限があります。1つのエンクレーブにアクティブなストリームは一度に1つしか存在できません。 これは、複数のスレッドを使用してリポジトリを操作するときにパスワードマネージャーのパフォーマンスが向上しないため、合理的なソリューションです。 ほとんどのアクションはユーザーインターフェイスによって制御され、CPUに大きな負荷をかけることはありません。



透明性の問題を解決するには、各ラッパー関数は最初に関数を呼び出して、エンクレーブが実行されているかどうかを確認し、まだ実行されていない場合は実行する必要があります。 ロジックは非常に簡単です。

 #define ENCLAVE_FILE _T("Enclave.signed.dll") static sgx_enclave_id_t enclaveId = 0; static sgx_launch_token_t launch_token = { 0 }; static int updated= 0; static int launched = 0; static sgx_status_t sgx_status= SGX_SUCCESS; // Ensure the enclave has been created/launched. static int get_enclave(sgx_enclave_id_t *eid) { if (launched) return 1; else return create_enclave(eid); } static int create_enclave(sgx_enclave_id_t *eid) { sgx_status = sgx_create_enclave(ENCLAVE_FILE, SGX_DEBUG_FLAG, &launch_token, &updated, &enclaveId, NULL); if (sgx_status == SGX_SUCCESS) { if ( eid != NULL ) *eid = enclaveId; launched = 1; return 1; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に、各ラッパー関数はget_enclave（）関数を呼び出します。この関数は、エンクレーブが静的変数に対して実行されているかどうかを確認します。 そうである場合、この関数は（必要に応じて） eidポインターにエンクレーブIDを配置します。 エンクレーブ識別子もグローバル変数enclaveIDに格納されるため、これはオプションの手順であり、直接使用できます。



停電または異常終了を引き起こすエラーのために飛び地が失われた場合はどうなりますか？ これを行うには、ECALLの戻り値をチェックします。ECALL操作自体の成功または失敗を示し、エンクレーブで呼び出された関数ではありません。

 sgx_status = ve_initialize(enclaveId, &vault_rv);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンクレーブで呼び出された関数の戻り値（ある場合）は、2番目のECALL引数として提供されるポインターを介して渡されます（これらの関数プロトタイプはEdger8rによって自動的に作成されます）。 ECALLの戻り値を常に確認してください。 SGX_SUCCESS以外の結果は、プログラムがエンクレーブに正常に入ることができず、要求された機能が起動されなかったことを示します。 （ sgx_statusもグローバル変数として定義したことに注意してください。これは、アプリケーションのシングルスレッドアーキテクチャによる別の単純化です）。



ECALL関数によって返されたエラーを分析し、飛び地の状態（ロスト、クラッシュ）をチェックする関数を追加します。

 static int lost_enclave() { if (sgx_status == SGX_ERROR_ENCLAVE_LOST || sgx_status == SGX_ERROR_ENCLAVE_CRASHED) { launched = 0; return 1; } return 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらは修正可能なエラーです。 上位レベルでは、これらの条件を処理できるロジックはまだありませんが、プログラムのさらなる開発をサポートするためにEnclaveBridge DLLで提供しています。



また、飛び地を破壊する機能がないことに注意してください。 ユーザーのシステムでパスワードマネージャーアプリケーションが開いている間、ユーザーがボールトをロックした場合でも、メモリ内に飛び地が存在します。 これは飛び地で作業するのに良い方法ではありません。 エンクレーブは、無操作であっても、無制限のプールから遠く離れた場所からリソースを消費します。 データのシーリングについて説明する際に、このシリーズの今後の記事でこの問題に対処します。

エンクレーブ定義言語

エンクレーブ設計に移る前に、エンクレーブ定義言語（EDL）の構文について少し話しましょう。 エンクレーブブリッジ関数（ECALLとOCALLの両方）のEDLファイルには、次の一般的な構造を持つプロトタイプがあります。

 enclave { // Include files // Import other edl files // Data structure declarations to be used as parameters of the function prototypes in edl trusted { // Include file if any. It will be inserted in the trusted header file (enclave_t.h) // Trusted function prototypes (ECALLs) }; untrusted { // Include file if any. It will be inserted in the untrusted header file (enclave_u.h) // Untrusted function prototypes (OCALLs) }; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ECALLプロトタイプは信頼できる部分にあり、OCALLは信頼できない部分にあります。 EDL言語の構文はCの構文に似ており、EDL関数のプロトタイプはC関数のプロトタイプに非常に似ていますが、同一ではありません。 特に、ブリッジ関数のパラメーターと戻り値はいくつかの基本的なデータ型に制限されており、EDLには、エンクレーブの動作を決定するための追加のキーワードと構文が含まれています。 インテルソフトウェアガードエクステンション（インテルSGX）SDKユーザーガイドでは、EDL構文について詳しく説明し、サンプルエンクレーブの作成に関するチュートリアルを提供しています。 そこで書かれていることをすべて繰り返すのではなく、アプリケーションに関連するこの言語の要素について簡単に説明します。



パラメータがエンクレーブ関数に渡されると、保護されたエンクレーブメモリ空間に配置されます。 値として渡されるパラメーターの場合、値はエンクレーブの保護されたスタックに配置されるため、他の関数の呼び出しと同様に、追加のアクションは不要です。 ポインターの場合、状況はまったく異なります。



ポインターとして渡されるパラメーターの場合、ポインターによって参照されるデータは、エンクレーブとの間で受け渡す必要があります。 このデータ転送を実行する境界プロシージャは、次の2つのことを「認識」する必要があります。

1. データをどの方向にコピーする必要がありますか：ブリッジ機能へ、ブリッジ機能から、またはその両方ですか？
2. ポインターによって参照されるデータバッファーのサイズは？

ポインターの方向

ポインターパラメーター関数を提供する場合、角括弧内のキーワードを使用して方向を指定する必要があります。したがって、[in]、[out]、または[in、out]です。 これらのキーワードの意味を表1に示します。

方向	ECALL	OCALL
で	バッファはアプリケーションからエンクレーブにコピーされます。 変更は、エンクレーブ内のバッファーにのみ影響します。	バッファーがエンクレーブからアプリケーションにコピーされます。 変更は、エンクレーブ外のバッファにのみ影響します。
アウト	バッファはエンクレーブ内に割り当てられ、ゼロ値で初期化されます。 ECALLが終了すると、ソースバッファにコピーされます。	バッファは飛び地の外側に割り当てられ、ゼロ値で初期化されます。 この信頼できないバッファは、OCALLの終了時に元のバッファにコピーされます。
イン、アウト	データは前後にコピーされます。	ECALLと同じです。

表1. ECALLおよびOCALLのポインター方向パラメーターとその値。



方向は、ブリッジの呼び出された関数に相対的であることに注意してください。 ECALL機能の場合、[in]は「エンクレーブへのコピーバッファー」を意味しますが、OCALLの場合、同じパラメーターは「バッファーを信頼できない機能へコピー」を意味します。 （代わりに使用できるuser_checkパラメーターもありますが、これは説明の主題とは関係ありません。その目的と使用については、SDKのドキュメントを参照してください。）

バッファサイズ

境界プロシージャは、次のように合計バッファサイズをバイト単位で計算します。

   = element_size * element_count
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、ボーダープロシージャの場合、 element_countの値は1であり、 element_sizeはポインターパラメーターによって参照される要素に基づいて計算されます。たとえば、整数ポインターの場合、 element_sizeは次のようになります 。

 sizeof(int)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

intやfloatなどの固定データ型の単一要素の場合、EDL関数のプロトタイプで追加情報を提供する必要はありません。 voidポインターは要素のサイズに設定する必要があります。そうしないと、コンパイル中にエラーが発生します。 データバッファーが1つの要素よりも長い配列、charおよびwchar_t文字列、およびその他のタイプの場合、バッファー内の要素の数を指定する必要があります。そうしないと、1つの要素のみがコピーされます。



角かっこ内のキーワードにカウントまたはサイズパラメータ（または両方）を追加します。 これらは、定数値または関数パラメーターのいずれかに設定できます。 ほとんどの場合、 カウントとサイズの機能は同じですが、適切なコンテキストで使用することをお勧めします。 厳密に言えば、サイズはvoidポインターを渡すときにのみ指定する必要があります。 それ以外の場合は、countを使用します。



文字列Cとwstring（NULL終端のcharまたはwchar_t配列）を渡すとき、 countまたはsizeの代わりにstringまたはwstringパラメーターを使用できます。 この場合、境界プロシージャは、文字列の長さを直接取得することにより、バッファのサイズを決定します。

 function([in, size=12] void *param); function([in, count=len] char *buffer, uint32_t len); function([in, string] char *cstr);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

stringまたはwstringは、[in]または[in、out]の方向が指定されている場合にのみ使用できることに注意してください。 [out]方向のみが指定されている場合、ラインはまだ作成されていないため、境界プロシージャはバッファのサイズを取得できません。 [out、string]を指定すると、コンパイル中にエラーが発生します。

シェルおよびブリッジ機能

これで、ブリッジのシェルと機能を定義できます。 前述のように、ほとんどのECALLはVaultのクラスメソッドのラッパーにすぎません。 パブリックメンバー関数のクラス定義を以下に示します。

 class PASSWORDMANAGERCORE_API Vault { // Non-public methods and members ommitted for brevity public: Vault(); ~Vault(); int initialize(); int initialize(const char *header, UINT16 size); int load_vault(const char *edata); int get_header(unsigned char *header, UINT16 *size); int get_vault(unsigned char *edate, UINT32 *size); UINT32 get_db_size(); void lock(); int unlock(const char *password); int set_master_password(const char *password); int change_master_password(const char *oldpass, const char *newpass); int accounts_get_count(UINT32 *count); int accounts_get_info(UINT32 idx, char *mbname, UINT16 *mbname_len, char *mblogin, UINT16 *mblogin_len, char *mburl, UINT16 *mburl_len); int accounts_get_password(UINT32 idx, char **mbpass, UINT16 *mbpass_len); int accounts_set_info(UINT32 idx, const char *mbname, UINT16 mbname_len, const char *mblogin, UINT16 mblogin_len, const char *mburl, UINT16 mburl_len); int accounts_set_password(UINT32 idx, const char *mbpass, UINT16 mbpass_len); int accounts_generate_password(UINT16 length, UINT16 pwflags, char *cpass); int is_valid() { return _VST_IS_VALID(state); } int is_locked() { return ((state&_VST_LOCKED) == _VST_LOCKED) ? 1 : 0; } };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスにはいくつかの問題のある機能があります。 それらのいくつかは明らかです：例えば、コンストラクタ、デストラクタ、およびinitialize（）のオーバーロード。 これらは、C関数を使用して呼び出す必要があるC ++コンポーネントですが、いくつかの問題は、関数デバイスに固有であるため、それほど明確ではありません。 これらの問題のあるメソッドのいくつかは、このチュートリアルの特定の問題に対処できるように、意図的に不適切に作成されましたが、他のメソッドは、広範囲に及ぶ目標なしに誤って作成されました。 シェル関数のプロトタイプとプロキシ/ブリッジプロシージャのEDLプロトタイプの両方を導入することにより、これらの問題を順次解決します。

コンストラクタとデストラクタ

Intel SGXを使用しないコードブランチでは、 VaultクラスはPasswordManagerCoreNativeのメンバーです。 これは、Intel SGXコードブランチでは実行できません。 ただし、ブリッジ関数自体がC関数である場合、エンクレーブにはC ++コードが含まれることがあります。



エンクレーブを単一のスレッドに制限したため、Vaultクラスをエンクレーブ内の静的なグローバルオブジェクトにすることができます。 これにより、コードが大幅に簡素化され、インスタンスを作成するためのブリッジおよびロジック機能が不要になります。

initialize（）メソッドのオーバーロード

initialize（）メソッドには2つのプロトタイプがあります 。

1. 引数なしのメソッドは、新しいパスワードなしボールトのVaultオブジェクトを初期化します。 これは、ユーザーが初めて作成したパスワードストアです。
2. 引数が2つのメソッドは、リポジトリファイルヘッダーからVaultオブジェクトを初期化します。 これは、ユーザーが開く（およびロックを解除しようとする）既存のパスワードストアです。

このメソッドは、2つのラッパー関数に分割されます。

 ENCLAVEBRIDGE_API int ew_initialize(); ENCLAVEBRIDGE_API int ew_initialize_from_header(const char *header, uint16_t hsize);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

対応するECALL関数は次のように定義されています。

 public int ve_initialize (); public int ve_initialize_from_header ([in, count=len] unsigned char *header, uint16_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

get_header（）

この方法には根本的な問題があります。 プロトタイプは次のとおりです。

 int get_header(unsigned char *header, uint16_t *size);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数は、次のタスクを実行します。

1. ストレージファイルのヘッダーブロックを受け取り、ヘッダーが指すバッファーに配置します。 呼び出しメソッドは、このデータを格納するのに十分なメモリを割り当てる必要があります。
2. ヘッダーパラメーターにNULLポインターを渡すと、ポインターが指すuint16_tがヘッダーブロックのサイズを設定するため、呼び出し元のメソッドは割り当てるメモリ量を認識します。

これは、一部のプログラミングコミュニティではかなり一般的な圧縮技術ですが、エンクレーブには問題があります：ECALLまたはOCALLにポインターを転送する場合、境界関数は、ポインターによって参照されるデータをエンクレーブ（またはその両方）にコピーします。 これらの境界関数では、コピーするバイト数を知るためにデータバッファーサイズが必要です。 最初のケースでは、可変サイズの有効なポインターが使用されますが、これは難しくありませんが、2番目のケースでは、NULLポインターとゼロに等しいサイズがあります。



ECALL関数のこのようなEDLプロトタイプを考え出すこともできますが、すべて機能しますが、通常は簡潔さよりも明確さが重要です。 したがって、コードを2つのECALL関数に分割することをお勧めします。

 public int ve_get_header_size ([out] uint16_t *sz); public int ve_get_header ([out, count=len] unsigned char *header, uint16_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

エンクレーブシェル関数は必要なロジックを提供するため、他のクラスを変更する必要はありません。

 ENCLAVEBRIDGE_API int ew_get_header(unsigned char *header, uint16_t *size) { int vault_rv; if (!get_enclave(NULL)) return NL_STATUS_SGXERROR; if ( header == NULL ) sgx_status = ve_get_header_size(enclaveId, &vault_rv, size); else sgx_status = ve_get_header(enclaveId, &vault_rv, header, *size); RETURN_SGXERROR_OR(vault_rv); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

accounts_get_info（）

このメソッドはget_header（）と同様に機能します。NULLポインターを渡し、対応するパラメーターでオブジェクトのサイズを返します。 ただし、このメソッドは、パラメーターの引数が多いため、優雅さと便利さでは区別されません。 2つのシェル関数に分割することをお勧めします。

 ENCLAVEBRIDGE_API int ew_accounts_get_info_sizes(uint32_t idx, uint16_t *mbname_sz, uint16_t *mblogin_sz, uint16_t *mburl_sz); ENCLAVEBRIDGE_API int ew_accounts_get_info(uint32_t idx, char *mbname, uint16_t mbname_sz, char *mblogin, uint16_t mblogin_sz, char *mburl, uint16_t mburl_sz);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、2つの対応するECALL関数：

 public int ve_accounts_get_info_sizes (uint32_t idx, [out] uint16_t *mbname_sz, [out] uint16_t *mblogin_sz, [out] uint16_t *mburl_sz); public int ve_accounts_get_info (uint32_t idx, [out, count=mbname_sz] char *mbname, uint16_t mbname_sz, [out, count=mblogin_sz] char *mblogin, uint16_t mblogin_sz, [out, count=mburl_sz] char *mburl, uint16_t mburl_sz );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

accounts_get_password（）

これは、アプリケーション全体で最も問題のあるコードです。 プロトタイプは次のとおりです。

 int accounts_get_password(UINT32 idx, char **mbpass, UINT16 *mbpass_len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初に目を引くのは、mbpassへのポインターへのポインターを渡すことです。 このメソッドはメモリを割り当てます。



明らかにこれは良い考えではありません。 Vault , , API , . , : .



-. , ECALL, , Vault , PasswordManagerCoreNative . : , — , . PasswordManagerCoreNative , - ( Intel SGX).

 ENCLAVEBRIDGE_API int ew_accounts_get_password_size(uint32_t idx, uint16_t *len); ENCLAVEBRIDGE_API int ew_accounts_get_password(uint32_t idx, char *mbpass, uint16_t len);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

EDL :

 public int ve_accounts_get_password_size (uint32_t idx, [out] uint16_t *mbpass_sz); public int ve_accounts_get_password (uint32_t idx, [out, count=mbpass_sz] char *mbpass, uint16_t mbpass_sz);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

load_vault()

load_vault() . :

 int load_vault(const char *edata);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Vault . Vault , , .



, . ECALL, , , . .



- :

 ENCLAVEBRIDGE_API int ew_load_vault(const unsigned char *edata);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ECALL , EDL:

 public int ve_load_vault ([in, count=len] unsigned char *edata, uint32_t len)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, - . ECALL.

 ENCLAVEBRIDGE_API int ew_load_vault(const unsigned char *edata) { int vault_rv; uint32_t dbsize; if (!get_enclave(NULL)) return NL_STATUS_SGXERROR; // We need to get the size of the password database before entering the enclave // to send the encrypted blob. sgx_status = ve_get_db_size(enclaveId, &dbsize); if (sgx_status == SGX_SUCCESS) { // Now we can send the encrypted vault data across. sgx_status = ve_load_vault(enclaveId, &vault_rv, (unsigned char *) edata, dbsize); } RETURN_SGXERROR_OR(vault_rv); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, PasswordManagerCoreNative wchar_t char. , wchar_t?



. Windows wchar_t API- Win32, UTF-16 . UTF-16 16 : , ASCII, , , . UTF-16 , 16 , ASCII.



, ASCII. , . Tutorial Password Manager , .NET, UTF-8 . UTF-8 — , 8 . ASCII UTF-16 ASCII. , UTF-8 , UTF-16, , , .



( , , ).

コード例

前述のように、このパートではダウンロードするサンプルコードを提供します 。添付のアーカイブには、チュートリアルパスワードマネージャーブリッジDLLおよびエンクレーブDLLのソースコードが含まれています。これまでのエンクレーブ関数は単なるスタブであり、5番目の部分で埋められます。

将来のリリースで

このチュートリアルの第5部では、暗号、DRNG、およびVaultクラスをエンクレーブに移動し、それらをECALL関数に接続して、エンクレーブの作成を完了します。 ニュースをフォローしてください！