Versions Compared

Old Version 17

changes.mady.by.user knimitz

Saved on

compared with

New Version 18

changes.mady.by.user knimitz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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のマネジメントをゲストに見せるのはローレベル過ぎる
  • Host環境
    • systemdをベースにする
    • minimum構成に外せないものは何か
    • yoctoを使ったsystemdは大きい

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

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

...

  • 複数の独立したコンテナでディスプレイを分配したい。
  • DRM leaseを利用すれば、Hostのmasterがゲストのコンポジタにdisplayのmaster権限を貸し出しできる
    • unix domainなどでfile descriptorを渡す必要がある。
  • 1GPU - 2 Display というケースで必要
  • R-CARはRender Nodeの仕組みが必要
  • lease managerはmaster権限を貸し出すだけで、初期化はコンテナのweston
  • アーリーレンダリングに必要
  • GPU描画をQMの対象外にしたい
    • メータの中でもQMのレベルを分ける必要がある。
    • GPUのドライバは検証できない。GPUのIPベンダのみ。
      • セットの動作保証はできない
  • Pros
    • 出力の宛先を切り替えたい
    • 1GPU - 2 Displayのようなユースケースに対応できる
    • IVIの中を分けることもできる(IVI + RSE)
  • inputについてはユースケースの定義が必要 
    • 一つのタッチイベントやボタンイベントを共有する
  • 4月から開発スタートしたい
    • CESでプロダクトレディーの状態にしたい

次のミーティング

  • 2/20
  • AMMのどこか


TODO

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

      アーキテクチャレビュー

      Image Removed

      今後のタスク、技術的改善点

      Nuttxを用いたCANのシステム構成.pptx

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

      とりあえず、リンク

        • 考え方の整理からスタートする
      • IC Service ... メータTier1 ですり合わせていただく
      • Linux Graphic stackのQM実現方法
        • 既存のほかのOSのやり方を学ぶ ... メータTier1 ワーキングから出してもらいたい
          • GPU(OpenGL)
          • デジタルクラスタのときに、どういうQMの考え方をしたのか
          • モータから絵を描画することに変化して、QMのレべルをどう切り分けたか
      • カーネルのQM Isolationについて、ELISA(SIL2Linux)に考え方を確認する
      • DRM lease
      • Connectivity のデバイスに対する要件の整理 ... 担当者を探す
        • ある程度要件がまとまった時点でContainer Managerのデザインを行う

      アーキテクチャレビュー

      Image Added

      今後のタスク

      Nuttxを用いたCANのシステム構成.pptx

      DRM lease : 

      Security Model : 

      USBのハンドリング : 

      IC service : 

      Container Manager : 



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

      とりあえず、リンク

      カーネル(まだ荒い。。。)

      https://makelinux.github.io/kernel/map/

      ...

      キャラクタデバイス


      drm/kms(graphics関連)

      GUI

      競争領域と非競争領域

      ...

      )

      ...

      === Appendix 12/4の議事 ====

      ...

      日時内容TODORemark
      10/9IC EG meeting

      10/11ボードセッションのアウトライン

      10/21事前打ち合わせ

      10/22-23AMM
      • キーノート
      • Session x 2

      10/24SAT
      • IC EG Update 1h
      • 前回残った話(IC EG core profile, branch)
      10/31Open Source Safety Critical Summit
      • ELISAと話す
      • 山口さんがCFPを出している→ 採択されました。おめでとうございます。
      11/5IC EG Call

      11/6IC EG Tech Meeting 13:30 - 16:30

      11/11 - 13Integration Session(SC)

      CES #3?

      各社デモ

      • IC EGがFundする
      11/19IC EG Call

      12/3IC EG Call

      12/10 - 12hackfest/CES Integration session in San Francisco

      CES #3?

      各社デモ?


      12/?発送

      1/7 - 10CES

      ...

      日時内容TODORemark
      10/9IC EG meeting

      10/11ボードセッションのアウトライン

      10/21事前打ち合わせ

      10/22-23AMM
      • キーノート
      • Session x 2

      10/24SAT
      • IC EG Update 1h
      • 前回残った話(IC EG core profile, branch)
      10/31Open Source Safety Critical Summit
      • ELISAと話す
      • 山口さんがCFPを出している→ 採択されました。おめでとうございます。
      11/5IC EG Call

      11/6IC EG Tech Meeting 13:30 - 16:30

      11/11 - 13Integration Session

      CES #3?

      各社デモ


      11/19IC EG Call

      12/3IC EG Call

      12/10 - 12hackfest/CES Integration session in San Francisco

      CES #3?

      各社デモ?


      12/?発送

      1/7 - 10CES

      ...

      • 機能安全と非機能安全の境界
        • ライブラリのレベルでinterfaceを切ってみた
          • kernel subsystemのレベルで吸収したほうがよいのではないか
        • ブザーもASILの対象
        • 「機能安全を達成する機能」と、「達成手段」は分けて考えたほうがよい
        • 機能安全の方法は網羅的に出したほうがよいか？
          • やりかたは各社それぞれ
      • 目標性能
        • No update
      • Sound
        • CarPlayとAndroid Autoの経路の確認
          • 構成図があるのでConfluenceにアップする
          • レイテンシ要件が厳しい。
            • Softwareで解決が難しい場合、SoCに性能達成を要求する必要がある
            • 目標性能のみ記載する(NDAが絡むので、なぜそれくらい必要なのかは記載しない)
          • Softwareでのノイズキャンセリング/エコーキャンセリングはPrivileged Containerに配置すると思うが、パスが多くて複雑
            • パスは一つのサーバーに集約したほうがよい
        • pulseaudioでの音声出力
          • ユーザセッションでコンテナ内で起動、音声出力確認できた
            • システムワイドで起動しない
            • pulseaudioみたいなユーザで起動する
          • コンテナ間通信をトライする。(domain socketの共有)
      • CAN
        • Gatewayの使い方、性能
          • no update
        • LXCでCANを使えるようにする
          • LXCでCANを配信可能
          • Domain socket(コンテナ間の通信)はcontainer managerで設定してあげる必要がある。
            • Readmeに記載する
          • パスを空ける = そのパスを通じてコンテナ内の全アプリが外部アクセスできる。セキュリティ的に大丈夫?
            • パスを空けないと通信できない
            • セキュリティが必要であれば、カスケードできるものが必要。それは必須事項ではない。
        • GUI
          • Qemu環境でX11 or Westonを動かす
            • no update
          • R-Carでコンテナ上でwaylandを動かす
            • まずデスクトップで、dockerを使って確認
              • Docker Clientでhostのwestonと通信し、wayland clientを動かすことができることを確認した。
            • LXCで動かしてみる
      • Yoctoのバージョン
        • thudに変更する
      • Container Manager
        • リファレンス実装を作成する。製品ではオリジナルになる
        • LXCを前提としたものにしたくない
        • 機能がAPIやライブラリになっているほうがいい(westonとlibwestonみたいな関係)
        • LXDを参考に、どのようなマネジメントが必要なのか整理する

      TODO

      • アーキテクチャコンセプト
        • 機能安全ソリューションは、手段はいろいろある、程度でとどめる。機能安全の解決方法の例を追加(山口さん)
      •  機能安全と非機能安全のインターフェイス
        • 機能安全達成とinterfaceの絵を分ける、どういう機能が機能安全で必要なのか説明する絵が必要(光成)
      • 要件整理(原木さん)
        • 目標性能
      • 全体アーキテクチャの整理(山口さん)
      • 技術課題
        • Sound
          • CarPlayとAndroid Autoの構成図(日下部さん)
          • Container間でSound出力を行う(光成)
        • CAN
          • Gatewayの使い方、性能(日下部さん)
        • コンテナ間通信の方法をREADMEに追記(山口さん)
        • GUI
          • Qemu環境でLXC上でX11 or westonを起動(谷川さん)
          • R-CarでwestonをLXC上で起動(黒川さんチーム)
        • Container Manager
          • LXDを参考に、どんなマネジメントが必要なのか整理する(光成)

      ...