[背景]
私は組み込みLinuxプラットフォームを開発しており、NANDフラッシュメモリにdm-verityを設定しようとしています。私はcryptsetup v2.3.0(socベンダーパッケージの一部)を使用しており、これが最初の試みです。ハッシュツリーを正常に作成し、それを確認しました。ここで、veritysetup
data_deviceはルートファイルシステムパーティション(/dev/mtdblock8など)を参照するmtdblockで、私のhash_deviceは別のパーティションのマウントパスにあるファイルパスを指します。しかし、このパーティションはまだマウントされておらず、ブートシーケンスの後半までファイルを使用できないため、ブート検証中にアクセスできるようにハッシュツリーデータをメモリブロックデバイスに直接保存する作業を行っています。
使ってみました。同じmtdblockはdata_deviceとして機能しますが、データブロックサイズを確認するためにデータブロック数を使用して計算されたハッシュオフセットを提供します。現在、他のパーティションのファイルに使用されているhash_deviceとしてmtdblockを使用してみました(オフセットを含めるか除く)。最後に、空のmtdblockをhash_deviceとして使ってみました。これは、何も接続されていない任意の「残りの」生のパーティションにすぎません。私はこの空のブロックを使用することを好みます。約2MBのスペースを無駄にし、この目的に使用できるからです。
[質問]
最も単純な形で、私のコマンドは次のようになります。veritysetup -v --debug format /dev/mtdblock8 /dev/mtdblockX
ここで、Xは数値です。毎回一般的なI / Oエラーが発生し、--debugログに「ハッシュデバイスにダイジェストを書き込めません」と表示されます。これは、verity_hash.c ファイルの失敗した fwrite に対応します。パスワード設定。テストプログラムを使用して/dev/mtdblockXに直接書き込むことはできませんが、/dev/mtdX(キャラクターデバイスmtdblockに関連付けられています)。しかし、、veritysetupに文字デバイスを提供するとエラーが発生します!このツールは、文字デバイスを許可せず、互換性のないデバイスエラーメッセージで失敗し、コードで許可される唯一のデバイスタイプはブロックデバイスと通常のファイルです。
if (fstat(devfd, &st) < 0)
r = -EINVAL;
else if (!S_ISBLK(st.st_mode))
r = S_ISREG(st.st_mode) ? -ENOTBLK : -EINVAL;
if (r == -EINVAL) {
log_err(cd, _("Device %s is not compatible."),
device_path(device));
close(devfd);
return r;
}
コードを修正し、私のプラットフォームに合わせて再コンパイルすることを検討しましたが、躊躇しました。 veritysetupが文字デバイスを受け入れない理由を理解できません。 Linuxはmtdblockデバイスへのあらゆる種類の書き込みを完全にブロックしているようですが、mtdデバイスへの書き込みは許可します。私をさらに混乱させることは、人々が/dev/mtdblockデバイスdata_devicesとhash_devicesを呼び出すのに成功した多くのケースをオンラインで見つけたということです。私も投稿しましたこの問題cryptsetup gitlab問題セクションで。