Occlum追加：(phase1) tcp grpcベースでのecnlave <-> host

[osuketh]

Issueへのリンク

やったこと

phase1

• occlum導入
• TCP gRPCベースでenclaveとHost間通信の疎通CIパス
• 既存remote attestationライブラリにstd feature追加

やらないこと

phase2

• occlumファイルシステムの /dev/sgx にioctlでQUOTE生成
• Remote attestationのCIパス

phase3

• occlum palを使ってdyn linkでenclaveをローディング
• enclave<->hostをuds gRPCに変更

動作検証

• CIパス

参考

• TODO部分は、phase2/3、該当PR merge後に対応します

[cipepser]

enclave<->hostをuds gRPCに変更

uds gRPCってなにものです？ :chimpan:

[laysakura]

uds == unix domain socket ですね（たぶん）

同一ノード前提で、TCPよりも速い

[laysakura]

細かい修正依頼をしました。その他の部分のコメントは主に質問や直さなくても良い指摘なので、反応ください。

---

別途、根本的な部分が読めておらず質問です。
enclaveにロードしたりecallしたりする部分を探し当てられなかったのですが、それはもしかして

occlum palを使ってdyn linkでenclaveをローディング

で行われるのでしょうか？

[osuketh]

enclaveにロードしたりecallしたりする部分を探し当てられなかったのですが、

今回の実装だと、別コンテナプロセスとしてenclave部分を動かしgrpcでecall相当のcommunicationをしています。
enclaveのローディングはここで行われています。

ただ、実際はenclaveで動かす必要のない機能はenclave外で動かすべきなので、同じSGXマシンで実装しudsでやりとりすべきか、別non-sgxマシンで実装しtcpでやりとりすべきかは考え中です

[laysakura]

enclaveのローディングはここで行われています。

なるほどありがとうございます。

• occlum buildはdocker build時に、
• occlum runはDockerfileのENTRYPOINTかCMDに書く

のがocclumのdockerイメージ作る上で素直かなと思ったのですが、そのへんいかがでしょう？全然素人なので変なこと言ってるかもですが...

[osuketh]

アプリケーションとして動かすコンテナであれば以下のような構成になると思います！

occlum buildはdocker build時に、
occlum runはDockerfileのENTRYPOINTかCMDに書く

今回は開発用のocclum dockerfileでCI動かしているので、コンテナに入ってゴニョゴニョしています。（CIでアプリケーション用コンテナ動かすためには、そのアプリのテストをしなくてはなので）

[laysakura]

🙆