議事録 2020/01/22, 1/23
Attendee
原木、黒川、日下部、遠藤、田口、駒形、山口、谷川、丸山、光成(敬称略)
場所
大阪
日時
2020 1/22(水) : 13:00 - 18:00
2020 1/23(木) : 10:00 - 15:00
日時
1/22
13:00 - 15:00 : CESの反省
15:00 - 16:30 : アーキテクチャ Review, 日本精機さんから提案
16:30 - 18:00 : 今後のタスク、技術的改善点
1/23
10:00 - 12:00 : GUI
13:00 - 14:30 : 予備
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コンテナの再起動が非常に早くなる)
ホストに軽量コンポジタを置く構成は良いと思う。
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は大きい