Page Comparison

Attendee

原木、黒川、日下部、遠藤、田口、駒形、山口、谷川、丸山、光成(敬称略)

...

• Lessons learned from AGL UCBコンテナデモ
  • init
    
    • Host : systemd, Guest: systemd
      • 図らずも、systemd serviceのツリーは、きれいに構築された。逆に言うと、ゲストでSystemdを使う限り、HostにSystemdを残す必要あり？
      • もしかすると、
        • ホストでは、ベースとしてA：FS Container（独自init）と、B:QM Isolation Container（sysytemd)と置き、QM Isolation Containerの中に、IVIやICのゲストコンテナ(systemd)をネスト？
    • 全コンテナの下に、最小構成のホストRootfsを置くアーキは理想だけど、現実的ではない？　
      •  全デバイスドライバがユーザーランド化でもしない限り、例外的なバイパスを開けまくるか、ゲストからホストに処理を移動する形になり、全体アーキが崩壊しかねない
      • minimum init (fork)-> systemdを起動したほうがよいのでは。
        • FS containerはminimum initが起動。
        • initも分離しないといけないと考えた。
      • 思ったほどHost環境を守れない
      • 例）CESデモでは、MOSTドライバの初期化が(sysfsのwriteを利用する方法で）ユーザーランドにあるため、これをホスト環境に組み込む必要があった
        • 理由：LXCでは、sysfsは原則ro、rw可すると、全sysfsがゲストに丸見えになる。LXCでないとしても、sysfsの原則roは正しいと思う
  • Security Model
    • AGLは、AppFwとLSM(SMACK）が密結合（ついでにいうならsystemdとも密結合）
      • きほんてきにSMACKはhostで設定しないといけないのに、AppFWが設定している
        • 本来は、システム構成(インストール時)に基本システムのセキュリティが決まる。
        • 後からインストールされるアプリには、後から3rdパーティ用のセキュリティポリシーを割り当てるべき
      • AppFWはSmackを利用しないようになるが、我々でもセキュリティモデルを考えないと
      • SELinux, AppArmorをコンテナでどのようにマネジメントしていくかを検討したほうがいい
        • 専門家がいない。
        • Android, サーバー屋さん
        • コンテナとLSMの連携がどうなっているのか知りたい
        • システムコンテナのレベルで一度制約をかける。その中で、アプリ単位で制限をかける。もちろん、コンテナの制約を破れないように。AppFW + SMACKだとうまくいかない
        • namespaceは対応しているはず。
      • 結果、SMACKを丸ごとホストからバイパスしないと、アプリケーションがインストールも起動もできないというトンデモな事態に
      • 結論：AppFwとLSMを密結合してはいけない？　AGL UCBのセキュリティモデル（特にMAC)を再考する必要あり？
  • USBホットプラグ
    • LXCは、USBホットプラグが難しい。コンテナにデバイスを追加、削除するプリミティブなAPIは存在するが、それだけでは足りない。
    • LXCは、コンテナの中でudevが機能しない。udevはホストにあり、udevの対象は基本ホスト。技術的には、例えば、udev経由でLXCのコマンドやAPI叩いてゲストに作用させる方法はあるが。。。
    • 例）USBメモリ
      • ホスト環境では、USBのデバイスの接続・切断、USBストレージデバイスの認識が可能だが、ゲストからは、ただのSCSIディスクにしか見えない
        • AGL UCBには、ストレージマネージャのようなサービスが存在しないので、まだ課題が顕在化していないだけ。
        • USBが抜かれても、ゲストに通知がこない。(USBデバイスが見れないので)
    • いまのAGLにストレージマネジャーがない
    • Bluetoothも同じような悩みがある。
      • Bluezをホストに置かないと、Bluetoothの接続、切断イベントがとれない
    • 動的に出現/消滅するデバイス
      • AGL UCBで解決することは難しいかもしれない
      • e.g. ストレージが抜かれたときにアプリをsigtermを送る機構など
    • それをホストで実装するとホストが膨らむ
    • ゲストでやると、ホストとの連携が課題
    • 既存のソリューション(Tier1が持っているストレージマネジャなど) を入れて、分離できるように
    • USB認証
    • 車載で使えるUSB, Bluetooth, その他ネットワーク系(WiFi, DCM)のコンテナでのハンドリングは、サーバーやPCでは利用しない。車載特有のため、AGLで議論するしかない。
      • 課題を明確にして、商品開発の段階で作りこむのが現実解か
      • 商品開発に移行しやすいような環境をオープンソース
      • Requirementを渡さないと、オープンソースの人は理解できない
      • AMMでABに申請したい
  • Sound
    • Unicens
      
      • agl-serviceの責務が明確化されていないため、本来サービスにあるべきではない処理が含まれる場合がある？
        • 例）agl-service-unicensをホストとゲストの両方で実行しないと、MOSTが正しく初期化されず、音がでない、曲の再生が始まらない、という不具合あり
    • Pipewire
      • 現状は、IVIゲストに存在。AGL AppFw？Signal composer?とPipewireが密結合している模様　→　ホストや別コンテナに分離ができない　→　ICゲストから音を鳴らす方法が存在しない
    • サウンドのあるべき論を出してガイドラインを作って、サービスを作ってもらう。
  • Grahpics
    • DRM問題
      • Waltham backend
      • Nested westonは、当初の想定外に上手く機能している（wayland-backendのwestonは起動が軽く、結果、IVI,ICコンテナの再起動が非常に早くなる）
        • ホストに軽量コンポジタを置く構成は良いと思う。
        • wayland通信は軽量なので、ネストの影響は小さい
  • コンテナマネージメント
    • LXC-Launcher
      • デモ実装やっつけだったが、Nestコンポジタアーキをうまく動かすためには、ここが肝となるかも。
        • 理由：デモでは、IVI_SHELLで、ゲストWestonのライフサイクルを管理。一方で、LXCとホストWeston(IVI-SHELL)は、そのままでは、何も連携できない。
        • RunLXCでのアプローチ：LXCのAPIを使ってコンテナのライフサイクルと、ホストWeston（IVI-SHELL)のSurface/Layer管理を結合し、コンテナのライフサイクル管理（再起動デモ）を実現
      • サーフェス、ディスプレイマネジメントとコンテナマネジメントは統合する必要があると考えている
      • コンテナマネージャもGUIを認識しないといけない。
    • IVIのリブートは5sec程度、Clusterコンテナは1sec程度でリブート可能
    • DRMのマネジメントをゲストに見せるのはローレベル過ぎる

CES2020(1/23) - 黒川さんから

• アプリケーションコンテナは利用していない
  • アプリケーションからどのコンポジタとバインドするのか、ホスト
  • ホスト側
  • 全部アプリケーションコンテナにするのは、組み込みには向いていないかもしれない
• SMACKは本来介入しなくてよいはず
  • ホスト側で設定したセキュリティポリシーに従って、アプリFWがMACコントロール
• QM isolationも含め、hostの分離の仕方(initから) を考える
  • LXCそのままで続けていくのは無理があるかもしれない
• Ethernet
  
  • systemdがDNSを起こすと、LXCと競合する
    • 名前解決ができなくなる
  • DNSマスカレードの設定をレシピ化
  • ネットワークのネームスペースはホスト側に置くべき。
  • ローカルリンクはLXC
  • Hostのconnmanは物理デバイスの制御
  • 将来的にはスライサーが欲しい
• バックエンドはホスト → ホストは大きくならざるを得ない → ホストの検証範囲が広がってしまうので、どのように切り分けるか、がコツ
• アプリケーションはアプリコンテナ
  • 早いところ、アプリを分離したい

TODO

• USBのRequirementを提案する必要がある
  • Requirementのたたき台を日下部さんに出していただく → Dr. Yamaguchiがまとめる。
• Security Modelの構築(SELinux, AppArmor)

...

...

...