議事録 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は大きい
CES2020(1/23) - 黒川さんから
アプリケーションコンテナは利用していない
アプリケーションからどのコンポジタとバインドするのか、ホスト
ホスト側
全部アプリケーションコンテナにするのは、組み込みには向いていないかもしれない
SMACKは本来介入しなくてよいはず
ホスト側で設定したセキュリティポリシーに従って、アプリFWがMACコントロール
QM isolationも含め、hostの分離の仕方(initから) を考える
LXCそのままで続けていくのは無理があるかもしれない
Ethernet
systemdがDNSを起こすと、LXCと競合する
名前解決ができなくなる
DNSマスカレードの設定をレシピ化
ネットワークのネームスペースはホスト側に置くべき。
ローカルリンクはLXC
Hostのconnmanは物理デバイスの制御
将来的にはスライサーが欲しい
バックエンドはホスト → ホストは大きくならざるを得ない → ホストの検証範囲が広がってしまうので、どのように切り分けるか、がコツ
アプリケーションはアプリコンテナ
早いところ、アプリを分離したい
DRM lease
複数の独立したコンテナでディスプレイを分配したい。
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
考え方の整理からスタートする
IC Service ... メータTier1 ですり合わせていただく
Linux Graphic stackのQM実現方法
既存のほかのOSのやり方を学ぶ ... メータTier1 ワーキングから出してもらいたい
GPU(OpenGL)
デジタルクラスタのときに、どういうQMの考え方をしたのか
モータから絵を描画することに変化して、QMのレべルをどう切り分けたか
カーネルのQM Isolationについて、ELISA(SIL2Linux)に考え方を確認する
DRM lease
Connectivity のデバイスに対する要件の整理 ... 担当者を探す
ある程度要件がまとまった時点でContainer Managerのデザインを行う
GUI Reference ... 田口さん
3月までに
アーキテクチャレビュー
今後のタスク
DRM lease :
Security Model :
USBのハンドリング :
IC service :
Container Manager :
ELISAメソッドを使ったQMアイソレーション in Kernel
とりあえず、リンク
カーネル(まだ荒い。。。)
https://makelinux.github.io/kernel/map/
ブロックデバイス
キャラクタデバイス
drm/kms(graphics関連)
=== Appendix 12/4の議事 ====
進捗の確認
IC EG Callの内容
関係者に資料は共有している
プロジェクトを開始する前にしなければいけないこと
インフラ
Contribution
UCBに入れるのはやりにくい。いらないもの、ビルド環境がIVI用に特化して構築されていて、修正しにくい構造になっている。
CESデモはUCB
リリースプロセス
プロジェクトの進め方のたたき台?
回せるものを作成して、進めていく
手を動かせる環境を整えないといけない
AGL UCBをスタートにすると、土台が大きすぎて難しい。仕切り直したい。
合流できるなら合流しましょうというスタンス、を伝える
CESからAMMの間に環境を整えたい
山口さんの環境はUCBを外している。ホストだけでよい
Cluster固有の作業は、Hostの環境構築とは分離
レシピセットは山口さん
レイヤーデザインは谷川さん
CES後
セキュリティ
(サイバー)セキュリティのデザインを決めないといけない
smackfsを共有していて、全ゲストから参照できるようになっている
chrootを破られると、リソースが別のコンテナから参照できるようになる。
製品にするまでには解決
今後の課題
Sound
特に進捗なし
PulseaudioのAuthenticationでパーミッションエラーが発生している
pipewireに切り替える(unicense)
Graphics
コンテナ上でwayland backend でwestonを動かすことを試す
11/6時点での経過。drm-backendでの表示OK、wayland-backendではhomescreen表示がNG。
＝＞QML Scene使って、IVI-shellの問題かWMの問題か切り分ける。直近はwayland-backendでの課題に注力する。
compositor on DRMが理想だが、現状はweston(guest) on weston(host)
小さなコンポジタが必要
libdrmをリンクできる人は一人しかいない
複数リンクできるようにするか
マスターを作る
AndroidはDRMの上に違うサブシステムが乗っている。
グラロクとsurface flinger
westonをhostに存在させると、シェルがなくなってしまう。
waylandはまだ枯れていないので、できればhostに残したくない
Ethernet
LXC
meta-verbalizationのレシピが古いので最新に切り替える。
Container Manager
今実装中
CANサポートがない
動的にvCANデバイスの割り当て
動的なドメインソケットの割り当て
設定ファイルで動的に動いてほしい。
製品にするには、CかC++
オープンソースで選択肢(e.g. LXD, LXC, docker etc) を用意する
製品側で選択して、改造
製品側でQMの認証
スペックを作るためのたたき台
LXCがEOLになってもAutomotive用に生き残らせたい
コンテナランタイムから分離したい
(Container) Managerではなく、違う名前を考えたほうがいいかも
Containerでできた仮想イメージをマネージしたい(vagrant, libvirtみたいな。現状あるLXD, Kubernetesはネットワーク向け)
コンテナランタイムの抽象化層
車載特化のものを作りたい
CES Integration
CESデモ反省会(実装してみてわかったこと)
ネットワークは?
dhcpで起こしている
LXC-netのbridgeは、つなぐ先(host)がいないと、ゲストからネットワークが繋げない
hostのbridgeを割り当てたほうがいいのでは?
hostのネットワークが起き上がってから、host - guestのbridgeをつなげる
次回打ち合わせ
1/22, 23 ＠大阪
AMMまでの課題
CESの課題
見つかった課題
機能ブロック上、足りていない機能
反省会、新年会、次回の定例
Init
systemdがでかい
systemdを削る
サービスが無い状態
代替案がない。。
busybox
sysv-init
AndroidはCのプログラム
起動はテキスト
シンプルのリファレンスがあればいい?
最低限のこと
電源周り
コンテナとワンセットで作るべき?
systemd-mslを作ると小さくなるのでは。
2段階のinit
clusterを起動するためのminimal QM init
こっちをinit
IVIを動かすためのホストシステムとして、systemdを起動するホスト用コンテナ
initrd → cluster(1)
initrd → systemd(2)
今後
AMM Hawaii でIC EGの活動を発表し、アップストリームをアピールしておく必要がある。
マイルストーン(Implement Goal)
2019.12 RFQ
2019.2 Start development
2019.6 Cluster Container
時期 |
| 備考 |
|---|---|---|
2020.3 |
| APIの決定 |
2020.6 |
|
|
2020.8 |
|
|