initramfs画像にファイルを添付する - 信頼できますか?

initramfs画像にファイルを添付する - 信頼できますか?

私はさまざまなLinuxディストリビューションの複数のアーカイブを変更しており、initramfs通常は1つのファイルのみを変更します。

initramfs画像内のすべてのファイルを抽出して再パッケージ化するためにrootユーザーに切り替えることなく、プロセスを自動化したいと思います。

まずファイルリストを作成しようとしています。gen_init_cpio いいえアーカイブのすべての内容を抽出します。つまり、すべての権限を8進数に変更し、出力を目的の形式にソートするスクリプトを介してinitramfs出力cpio -tvn initrd.img(出力など)を解析します。例:ls -lgen_init_cpio

dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
slink /bin/sh busybox 777 0 0
file /bin/busybox initramfs/busybox 755 0 0

これにはいくつかの置換が含まれており、スクリプトを書くのが難しいかもしれないので、より良い方法を見つけました。どれくらい安全で移植性があるか尋ねます。

一部のディストリビューションにはリンクさinitramfsれたセクションを含むファイルがあり、明らかにカーネルはファイル全体を解析して1バイトの境界で囲まれたすべてのセクションを抽出するため、各セクションを512バイトの倍数で埋める必要はありません。私はこの「機能」がアーカイブ内のファイルを変更するときにアーカイブを再生成するのを防ぐのに役立つと思います。実際には少なくともDebianand で動作しますCloneZilla

たとえば、Debian 8.2.0/initでファイルを変更した場合は、そのファイルを画像initrd.gzに追加できます。initrd.gz

$ echo ./init | cpio -H newc -o | gzip >> initrd.gz

したがって、initrd.gz元のアーカイブと変更されたアーカイブラには、2つのリンクされたアーカイブがあります。結果を見てみましょうbinwalk

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             gzip compressed data, maximum compression, has original file name: "initrd", from Unix, last modified: Tue Sep  1 09:33:08 2015
6299939       0x602123        gzip compressed data, from Unix, last modified: Tue Nov 17 16:06:13 2015

完璧に動作します。しかし、信じるべきですか?ファイルにデータを追加する際の制限は何ですかinitfamfs?元のアーカイブを512バイトの倍数で埋めずに追加しても安全ですか?この機能をサポートするカーネルバージョンは何ですか?

答え1

私が知っている限り、initrdをサポートするすべてのカーネルバージョンで非常に信頼性が高くサポートされています。これが cpioアーカイブを構成する要素の特徴です。入力を抽出し続ける...ファイルは順番に2つのcpioアーカイブラであることがわかりますが、cpioはそれを単一の入力ストリームとして扱います。initramfscpio

Debianでは、この方法(initramfsへの別のcpio接続)を使用して、インストーラinitramfsにバイナリblobファームウェアを追加することをお勧めします。たとえば、

Debianインストーラ/NetbootファームウェアDebian Wiki |

Initramfsは本質的にRAMディスクに抽出され、Linuxカーネルの初期ユーザースペースとして使用されるgzipで圧縮されたcpioアーカイブをリンクしました。 Debian インストーラの initrd.gz は、実際に起動時にインストーラに必要なすべてのファイルを含む gzip で圧縮された cpio アーカイブです。不足しているファームウェアファイルを含む別のgzipで圧縮されたcpioアーカイブを添付するだけです!

答え2

いいえ、既存のinitramfsです。圧縮アーカイブに添付されている任意のアーカイブを確実に解析し続けるには、パディングが必要です。

xz特に「レガシーフレームフォーマット」lz4圧縮はトリッキーで、4回のうち3回は失敗します。特に、以前のアーカイブのバイト数が4で割られていないときはいつでもそうです。 raw format = newc cpioを前に配置するときに個々の圧縮アーカイブについて心配する必要はないので、これはしばしば見落とされます。圧縮されていない形式は常にソートされます。

理論的には、initramfs形式はアーカイブの単純な接続(オプションで圧縮)以外には指定されていませんが、解凍ルーチン(場合によっては設計によって)が1つのアーカイブが終わる場所と、アーカイブが開始される次のアーカイブがわからない場合はまだ入力する必要があります。いくつかの極端なケースは次のとおりです。Linuxバージョン5.14の改善点、他のものは、カーネルで明示的に検出することはできません(不可能ではありませんが)、難しいようです。圧縮アーカイブの後に追加のデータがある場合、次のメッセージはそのデータが無視されたことを示します。

Initramfs unpacking failed: Decoding failed
Initramfs unpacking failed: invalid magic at start of compressed archive
Initramfs unpacking failed: broken padding

圧縮が最後のアーカイブにのみ適用される場合、これらのメッセージは無害です。解析されなくなりましたが、とにかく解析する項目はありません。

関連情報