Page Comparison

Attendee

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

場所

大阪

日時

2020 1/22(水) : 13:00 - 18:00

...

14:30 - 15:00 : Wrap up

議事

ELISA

...

• ユースケースを提案(Telltale)
• SafetyとNon Safetyをわけることを提案
  • すべてLinuxでできないのか、と言われている。
    • 動くものはLinuxで作れる、と主張される
  • なぜLinuxでできないのか、を伝える必要がある。
    
    • 車に載せれない、という理由を具体的に説明する必要がある。日系、欧州で使わない理由。機能ではなく、品質面でLinuxを使うことを受け入れれないラインがある。
    • → できること、できないことを分けるアプローチをとっていることを説明する

AMMでIC EGで2つセッションを出す

• 品質(山口さん)
  • 量産に向けた課題解決
  • どうやって品質(QM)を担保するか
• アーキテクチャ(田口さん、丸山さん)
• 黒川さんがコンテナデモでわかったことを発表する
  • コンテナ化に紐づけて、AppFWについて見直しの提言

CESの反省

• 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コンテナの再起動が非常に早くなる）
        • ホストに軽量コンポジタを置く構成は良いと思う。
  • コンテナマネージメント
    • LXC-Launcher
      • デモ実装やっつけだったが、Nestコンポジタアーキをうまく動かすためには、ここが肝となるかも。
        • 理由：デモでは、IVI_SHELLで、ゲストWestonのライフサイクルを管理。一方で、LXCとホストWeston(IVI-SHELL)は、そのままでは、何も連携できない。
        • RunLXCでのアプローチ：LXCのAPIを使ってコンテナのライフサイクルと、ホストWeston（IVI-SHELL)のSurface/Layer管理を結合し、コンテナのライフサイクル管理（再起動デモ）を実現

TODO

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

アーキテクチャレビュー

ELISAメソッドを使ったQMアイソレーション in Kernel

...

...

...