DM-Verityの仕組みを理解できません。
次から読むここまたはこここれについていくつかの質問があります。
- dm-verityで保護されているブロック区画全体を考えてみましょう。データにアクセスするときは、ルートハッシュまでハッシュテーブルのデータを確認する必要があります。 dm-verityは関心のあるデータブロックのみをチェックしますか、それともパーティション全体をチェックしますか？最初のケースでは、一定時間が経過した後にdm-verity保護パーティションの他のブロックを確認する必要がある場合は、プロセス全体が再実行されますか？
- としてマウントされたdm-verity保護blckパーティションがあります
/dev/sda1。/dev/sda1Linuxでこれが表示されたら、パーティション全体が確認されたことを意味しますか？ /dev/dm*それが何であり、なぜ必要なのかを説明してください。
答え1
免責事項：私は専門家ではありませんが、RPiでdm-verityを設定しながら学習した内容を共有します。質問1と2についてお答えします。
- 私が見つけたdm-verityの説明が実際に以下を含むアルゴリズムを説明していることを考えるとこの回答、彼らは引用して実際のアルゴリズムを説明します。メルクルツリー。後者の参照には有用な例があります。
たとえば、図のツリーにすでにハッシュ0-0とハッシュ1が含まれている場合、データブロックをハッシュした後、その結果をハッシュ0-0、ハッシュ1、最終結果と比較すると、データブロックL2の整合性がすぐに確認できます。繰り返しの組み合わせ。結果を親ハッシュと比較します。同様に、ハッシュ１－１とハッシュ０が既にツリー内にある場合、データブロックＬ３の整合性を確認することができる。
dm-verityを設定すると、ハッシュツリーを作成して別のパーティションに保存します。その後、システムは読み取っているブロックを確認できます。
- 読み込んでいるブロックのハッシュを計算します。
- 計算されたハッシュは他のブロックに格納されているハッシュと結合され、親ハッシュを計算します。
- この上位階層ハッシュは、同じ階層に格納されたハッシュと結合され、次の上位階層ハッシュを計算する。
- ルートハッシュが計算されるまで繰り返し
- 計算されたルートハッシュを保存されたルートハッシュと比較する
ブロックが書き込まれるたびに変調を検出し続けるには、保存されたハッシュツリーを更新する必要があります。
- 私はそれが実装に依存していると思います。しかし、実装ではcryptsetup-bin Debianパッケージパート1で説明したようにこの参照起動時にハッシュ全体を確認してください。 （これウィキペディアリンク上記はまた、ブロックのハッシュから始まるハッシュツリーを計算することが、データセット全体のハッシュを計算するよりも、単一ブロックのハッシュツリーを計算するよりも効率的であることを説明している。この部分はまだ把握中です。私が理解したように、すべての読み取りでブロックを確認するように設定することもできます（参照この参照）。
答え2
どのように動作するかを示す図は次のとおりです。https://source.android.com/security/verifiedboot/dm-verity
おそらくそうです。
/dev/dm* デバイスはデバイスマッパーに属します。 dm-verityについて言えば、次のことが役に立ちます。https://en.wikipedia.org/wiki/Device_mapper https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html