Armadilloフォーラム

Linuxカーネルライブパッチの実行可否について

ibt_oyabe

2024年2月28日 13時19分

いつもお世話になっております。
Armadillo-X1(debian)でAWS IoT Greengrassサービスを利用したエッジコントローラの開発を行っております。
現在、アプリ、Greengrass、OS、ブートローダのアップデートの実行可否について検討を行っており、
以下の質問がございます。

質問 1) ブートローダやOSのOTAアップデートはできますか。

質問 2) OSのOTAアップデートは、Greengrassコントロール下で実行できますか。

質問 3) Linuxカーネルライブパッチは実行可能ですか。

質問 4) Armadillo-640(Armadillo Base OS使用)にて、Linuxカーネルライブパッチは実行できますか。

ご回答をお願いします。

コメント

at_dominique.m…

2024年2月28日 14時49分

ibt_oyabeさん、

お世話になっています、
マルティネです。

> 質問 1) ブートローダやOSのOTAアップデートはできますか。

Armadillo X1/debian でブートローダやOSのファイルを書き込めば更新は可能ですが、Armadillo Base OS と違って2面化されてませんので遠隔アップデートの場合にアップデートの途中に問題がある場合の対応は難しい状態です。
具体的に:
* ブートローダについてはブートパーティションを上書きするしかないのでアップデートの途中で切れた場合に起動できなくなる恐れもありますが、ブートローダ自体は小さいため書き込みの時間も短いはずのと、頻繁に更新されるような物ではないのでそこは修正内容をみて適用するかどうかを決めていただいた方がよろしいかと思います。
* debian ユーザランド自体は apt で更新すれば、dpkg がそれなりに安全に更新してくれてます(途中で再起動してもアプリケーションが動いてる状態になるはずです)が、途中からの再実行の自動対応はないため手動で修正する必要があります。
* カーネルの更新の仕組みを用意してませんが、ファイルを上書きのではなく dpkg のように別のファイルに書き込みを行って fsync() の後にリネームすればその更新自体は安全です。

> 質問 2) OSのOTAアップデートは、Greengrassコントロール下で実行できますか。

大変申し訳ないですが、用意しているものはありません。
自分で実装する必要があります。

> 質問 3) Linuxカーネルライブパッチは実行可能ですか。

ライブパッチをサポートしてません。
アップストリームカーネルに入ってるライブパッチのコードは x86/x86_64/s390/powerpc でしかサポートされてませんので、現在のサポートはできない状態です(できたとしても、ライブパッチはアップデートの仕組みではありませんので、更新の代わりになりません。特定のセキュリティの問題を一時的に修正しているです)

> 質問 4) Armadillo-640(Armadillo Base OS使用)にて、Linuxカーネルライブパッチは実行できますか。

同じ理由で Armadillo Base OS でも対応できません。

ただし:
- Armadillo Base OS の更新の場合はアプリケーションが起動している状態で B面を書き込みしてますので、ダウンタイムは再起動に必要な時間だけです。
- どうしても欲しい場合は、Armadillo Base OS では debug用のカーネルを用意していて、そのカーネルでは systemtap などで livepatch と似たような修正はできます(パッチは用意してません)。その修正をロードできるためのフックで数パーセント遅くなりますので、デフォルトのカーネルでは使用できません。

よろしくお願いします。

ibt_oyabe

2024年2月28日 16時41分

ご回答ありがとうございます。
いただいた回答についてコメントがございますので、ご確認をお願いします。

> > 質問 1) ブートローダやOSのOTAアップデートはできますか。
> Armadillo X1/debian でブートローダやOSのファイルを書き込めば更新は可能ですが、Armadillo Base OS と違って2面化されてませんので遠隔アップデートの場合にアップデートの途中に問題がある場合の対応は難しい状態です。

(ibt_oyabeコメント)Armadillo-X1をお客様の現場で使用されている場合、基本はOSやブートローダのアップデートは行わずに運用し、
致命的な問題がある場合のみリスクがある状態でアップデートするか、もしくは機器を回収してアップデートするということでしょうか。

たびたびの質問で申し訳ございませんが、回答をお願いします。

at_koseki

2024年2月28日 19時00分

古関です。

デバイス運用管理サービスのnode-eyeをご利用の場合は
Linux-KernelやDebianのリモートアップデートが可能です。
https://node-eye.com/

書き込み中の停電などでアップデートが失敗した場合には
自動的にリカバリブートに遷移して起動しますので、
もう一度リモートアップデートをやり直すことで復旧させることができます。

ただし、ブートローダーのリモートアップデート機能は標準で提供していません。

技術的にはできるのですが、
ブートローダーで通常ブート、リカバリブートを判定をしていて、
かつブートローダー領域は1面しかないためリスクがある状態での更新となります。

ibt_oyabe

2024年2月29日 15時40分

ご回答ありがとうございます。
デバイス運用管理サービスnode-eyeを利用することでリスクが無いリモートアップデートが
できるようになること、承知しました。

別な方法として、ブートローダやOSの領域を二面化しアップデートする仕組みを
自作しても実現できると思いますが、実装に関してかなり敷居は高いでしょうか。
サンプルプログラムのご用意とかありますでしょうか。

ibt_oyabe

2024年3月5日 10時09分

> > 質問 3) Linuxカーネルライブパッチは実行可能ですか。
>
> ライブパッチをサポートしてません。
> アップストリームカーネルに入ってるライブパッチのコードは x86/x86_64/s390/powerpc でしかサポートされてませんので、現在のサポートはできない状態です(できたとしても、ライブパッチはアップデートの仕組みではありませんので、更新の代わりになりません。特定のセキュリティの問題を一時的に修正しているです)

Linuxカーネルライブパッチをサポートしていないとのことですが、何がネックでサポートしていないのでしょうか。
また、x86/x86_64/s390/powerpcではサポートされているとの事ですが、これらのプロセッサが搭載されたボードはすべてサポートされていてカーネルライブパッチが実行できるのでしょうか。
また、i.MXのサポート可否についもお聞きしたいです。

at_dominique.m…

2024年3月5日 11時37分

ibt_oyabeさん、

マルティネです。

> > アップストリームカーネルに入ってるライブパッチのコードは x86/x86_64/s390/powerpc でしかサポートされてませんので、現在のサポートはできない状態です(できたとしても、ライブパッチはアップデートの仕組みではありませんので、更新の代わりになりません。特定のセキュリティの問題を一時的に修正しているです)
>
> Linuxカーネルライブパッチをサポートしていないとのことですが、何がネックでサポートしていないのでしょうか。

単純に必要な機能はだれも実装してないだけです。
具体的に何が必要かまでは確認してませんが、最新の Linux カーネルのソースで「CONFIG_LIVEPATCH」のオプションを検索すると上記のプロセッサの対応コードでしか設定されてません。

> また、x86/x86_64/s390/powerpcではサポートされているとの事ですが、これらのプロセッサが搭載されたボードはすべてサポートされていてカーネルライブパッチが実行できるのでしょうか。
> また、i.MXのサポート可否についもお聞きしたいです。

プロセッサがサポートしているのではなく、Linux での実装は逆にプロセッサに依存しています。
Linux カーネルの arm (X1等)/arm64 (X2等)プロセッサ対応の実装の中に livepatch に必要な機能を実装すれば不可能なことはないと思いますが、簡単な話でしたらだれかがすでに対応してくれたはずですので技術的に難しいかと思われます(高い工数が必要という意味で)

また、その機能ができても、機能の使い方に関してもものすごく時間かかります。
livepatch はアップグレードの仕組みではなく、特定な問題の修正しかできませんのでカーネルに入る修正を一つ一つ細かく確認して対応する必要があります(例えば struct に変更が必要なパッチは livepatch で対応できませんので、調整や別のワークアラウンドの作成も必要です)
弊社は redhat や canonical (ubuntu) の規模ではないので、とてもサポートできません。
一つの特定なバージョンに一つの特定な修正を入れるのは簡単でも、徹底的に「livepatch によって再起動しなくてもセキュアーなシステムになります」とは言えません。

よろしくお願いします。

ibt_oyabe

2024年3月5日 16時07分

ご回答ありがとうございます。

> > > アップストリームカーネルに入ってるライブパッチのコードは x86/x86_64/s390/powerpc でしかサポートされてませんので、現在のサポートはできない状態です(できたとしても、ライブパッチはアップデートの仕組みではありませんので、更新の代わりになりません。特定のセキュリティの問題を一時的に修正しているです)
> >
> > Linuxカーネルライブパッチをサポートしていないとのことですが、何がネックでサポートしていないのでしょうか。
>
> 単純に必要な機能はだれも実装してないだけです。
> 具体的に何が必要かまでは確認してませんが、最新の Linux カーネルのソースで「CONFIG_LIVEPATCH」のオプションを検索すると上記のプロセッサの対応コードでしか設定されてません。

Armadillo-X1では、Linuxカーネルライブパッチはサポートしているが有効にしていない(CONFIG_LIVEPATCH=yになっていない)と解釈しましたが、この認識で間違いないでしょうか。

ibt_oyabe

2024年3月5日 16時33分

上の書き込みに間違いがありましたので訂正します。

Armadillo-X1では、Linuxカーネルライブパッチ機能有効/無効(CONFIG_LIVEPATCH)の設定は存在するが、サポートはしていないため無効になっていると解釈しましたが、この認識で間違いないでしょうか。

at_dominique.m…

2024年3月5日 16時43分

> 上の書き込みに間違いがありましたので訂正します。
>
> Armadillo-X1では、Linuxカーネルライブパッチ機能有効/無効(CONFIG_LIVEPATCH)の設定は存在するが、サポートはしていないため無効になっていると解釈しましたが、この認識で間違いないでしょうか。

説明が下手ですみません。
CONFIG_LIVEPATCH の設定自体は存在しますが、arm のビルドの場合ではその設定を有効化できない状態です。
無理やりに有効にしても動作しません。

よろしくお願いします。

ibt_oyabe

2024年3月6日 11時37分

ご回答ありがとうございました。
Armadillo-X1ではサポートしていないこと、承知いたしました。

ibt_oyabe

2024年3月6日 13時14分

> > 質問 1) ブートローダやOSのOTAアップデートはできますか。
>
> Armadillo X1/debian でブートローダやOSのファイルを書き込めば更新は可能ですが、Armadillo Base OS と違って2面化されてませんので遠隔アップデートの場合にアップデートの途中に問題がある場合の対応は難しい状態です。
> * カーネルの更新の仕組みを用意してませんが、ファイルを上書きのではなく dpkg のように別のファイルに書き込みを行って fsync() の後にリネームすればその更新自体は安全です。

上記方法でもカーネルの領域を2面持っていなければ安全なアップデートをできないという認識で合っていますでしょうか。
(dpkg+fsyncでアップデートしている途中に電源断が発生した時)

at_dominique.m…

2024年3月6日 13時54分

マルティネです。

> > Armadillo X1/debian でブートローダやOSのファイルを書き込めば更新は可能ですが、Armadillo Base OS と違って2面化されてませんので遠隔アップデートの場合にアップデートの途中に問題がある場合の対応は難しい状態です。
> > * カーネルの更新の仕組みを用意してませんが、ファイルを上書きのではなく dpkg のように別のファイルに書き込みを行って fsync() の後にリネームすればその更新自体は安全です。
>
> 上記方法でもカーネルの領域を2面持っていなければ安全なアップデートをできないという認識で合っていますでしょうか。
> (dpkg+fsyncでアップデートしている途中に電源断が発生した時)

カーネルの更新に関しては2面化は不要です。
以下の順番でアップデートする場合に問題ありません:
* 新しいカーネルを別のパスで書き込む
* (f)sync等でファイルがディスクに保存されていることを確認する
* mv/rename等でカーネルをただし一致にリネームする

リネームの前は古いカーネルで起動しますし、リネームの後に新しいカーネルで起動します。途中はありません(mv コマンド実行中で電源が落ちた場合はどれで起動するかはタイミングによりますが、必ずどれかを起動できます)

ただ最終的なパスで直接に書き込みすると再起動できない時間ができてしまいますので、そこは書き込みの際に注意していただく必要があります。
(弊社が提供しているカーネルは debian パッケージとして提供してませんが、たとえ dpkg で更新する場合は dpkg もこの手順で書き込みを行っていますので安全です、というコメントでした)

at_dominique.m…

2024年3月6日 14時24分

連続ですみません、一つの注意点を追加させてください。

以下の手順において、リネームする前は新しいカーネルの書き込みも確認する必要があります。
書き込みが失敗したのに(例えばディスクフルなどのエラー)リネームしてしまうと起動できなくなりますので、チェックサムなどを確認してからリネームしてください。

> カーネルの更新に関しては2面化は不要です。
> 以下の順番でアップデートする場合に問題ありません:
> * 新しいカーネルを別のパスで書き込む
> * (f)sync等でファイルがディスクに保存されていることを確認する
> * mv/rename等でカーネルをただし一致にリネームする

また、古関さんが以前の返事で説明してくれた node-eye サービスでしたらその確認もちゃんとしていますので、自分で実装する自信がない場合はご利用ください。

よろしくお願いします。

ibt_oyabe

2024年3月7日 13時26分

マルティネ様、古関様
このたびは、度重なる質問にご丁寧にご回答くださり大変感謝いたしております。
ありがとうございました。