swapdateのreadback handler

背景

swupdateをOTAスキームとして使用すると、データがパーティションに書き込まれた後に再度チェックアウトを読み出す必要がある項目がある.

初歩的な実装:readout-verify attribute

初歩的な分析には2つの方法がある.

案1

各データが書き込まれると、すぐにチェックアウトが読み出されます.このとき元のデータはbufferにあり、読み出したデータは元のbufferと直接比較すればよい

案二

パーティションデータを完全に書き込み、チェックアウトを読み出します.
ストリームアップグレードの場合、ソースデータはスライス転送で書き込まれ、使い終わったら破棄されるため、パーティション全体を書き終わった後、元のデータは比較できません.
この場合、データソースから再取得(OTAパケットのダウンロードに相当)するか、OTAパケットに検証値を追加して構成し、読み出しデータ計算で得られた検証値を比較する必要がある.
単純な考慮から、スキーム1を選択して実装し、imageにreadout-verifyの属性を追加し、構成後、各データの書き込み後に検証を読み出し、検証の方式はソースbufferと直接比較する.
機能は簡単だが、ソースコードには考慮されていないため、検証に使用されるbufferは伝達されず、申請と釈放を繰り返すしかなく、問題は見ているだけで少し違和感があるだけではない.patchを出して、著者の意見を聞きたいと思っていたが、著者はreadback handlerがパーティションデータの読み出しをサポートするために検証されたと返事した.

コミュニティ実装:readback handler

このreabback handlerはscriptsの形式を採用しており、すべてのimageの書き込みが完了した後、imageに対して読み出し検査を行い、sha256の検査値はsw-descriptionに予め配置する必要がある.
例を挙げます.

scripts: (
{
    device = "/dev/mmcblk2p1";
    type = "readback";
    properties: {
        sha256 = "e7afc9bd98afd4eb7d8325196d21f1ecc0c8864d6342bfc6b6b6c84eac86eb42";
        size = "184728576";
        offset = "0";
    };
}
);

機能は、その名の通り、指定deviceの指定範囲のデータを読み出し、sha256の値を算出し、構成中のsha256の値と一致するか否かを検証するものである.
具体的な構成は以下の表に示す.
フィールド
を選択します.
説明
device
string
検証するパーティションノード
type
string
注記handler
sha256
string
パーティションのsha 256値
size
string
検証するデータサイズ(単位:バイト).0に設定または設定されていない場合は、パーティションサイズが自動的に取得されます.
offset
string
検証するデータオフセット(単位:バイト).設定されていない場合は、デフォルトは0です.

まとめ

次の2つの実装を少し比較する(以下の欠点は別のものであるため、利点は後述しない)readback handlerの欠点は

の実装は複雑で、使用も複雑であり、sha256(もちろんスクリプト自動化によって生成される)

を構成する必要がある.

は、問題が発生すると直ちに保留現場を誤ることなく、すべてのimageの書き込みが完了した後、検証

を行う.

は、エラー時にペンデータの書き込みを再試行する必要があるなど、いくつかのカスタマイズが容易ではない.readout-verify attributeの欠点は

は、場合によっては適用されない、例えば、ubi handler、rdiff handler

、

は、ペンデータの書き込みが正しいことを保証するだけで、完全なデータが改ざんされていないことを保証することはできません.例えばAのデータを書き込む読み出しチェックに成功し、さらにBを書き込むとAに影響する、

は検出できない.
以上、コミュニティのデフォルトのreadback handlerを優先的に選択し、本当に満足できないカスタマイズの需要がある場合は、独自に特殊な属性と行為を実現することを考慮する.
blog: https://www.cnblogs.com/zqb-all/p/12827506.html公衆番号:https://sourl.cn/T4Skam