2184884_ja-JP

是

ファイルシステムの暗号化に 'tk(cbc(aes))' を使用すると iMX8MM CAAM エラーが発生する

` tk(cbc(aes))` によるファイルシステム暗号化に CAAM を使用してファイルシステムに書き込むときに、次のエラーが発生します。

caam_jr 30902000.jr:4000141c: DECO: desc idx 20: DECOウォッチドッグタイマータイムアウトエラー

これはたまにしか発生しませんが、すべてのコアを有効にして実行している場合に発生しやすくなるようです。

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

返信が遅くなり申し訳ありません。

私たちは、Phytec の `linux-imx_5.15.71_2.2.2-phy5` とhttps://github.com/Freescale/linux-fslc/tree/5.15-2.2.x-imxからのパッチを 5.15.183 まで使用しています。残念ながら、この問題はたまにしか発生しません (複数のユニットにわたる CI テストの500時間ごとに1件未満)。また、簡単な再現ツールを作成できませんでした。

` CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG` を有効にするための最初の試みは、CAAM を使用してルートファイルシステムとさまざまなデータパーティションを暗号化しているため、デバイスの起動を妨げ、過剰なログが生成されます。

循環バッファにログ情報を追加し、エラーが発生したときにこれを出力する方法を検討しています。これにより、最後の約 1000 件のレコードのみが出力されることになるため、分析をサポートするために常にログに記録する必要があるセットアップメッセージがあるかどうかを知りたいと思います。

よろしくお願いします。

ダニエル

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

作業中の BSP のバージョンと、問題が発生したときの手順とログを共有していただけますか?

よろしくお願いします。

Harvey

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

残念ながら、他のツールでは再現できませんでした

障害発生時の過去2048件のCAAMログメッセージのログ記録を追加しました。現在、CIで障害が再発するのを待っています。ログが届き次第、お送りします。

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

ウォッチドッグタイムアウトエラーは DECO の停止によって発生しましたが、入力/出力バッファアドレス、長さなど、DECO を停止させるCASEは複数ありました。
CANこれを「dd」または「fio」ツールを使用したストレステストで再現できますか?

問題を安定して再現CAN場合、根本原因の特定に役立ちます。

よろしくお願いします。

Harvey

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

最終的にログ記録に失敗しました。これには、CAAM サブシステムからの最後の 2048 件のログレコードが含まれます。標準ログとの唯一の違いは、`src` および `dst` バッファデータが含まれていないことです。

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

省電力のためCPUとDDRを低速で動作させているため、この動作に影響する可能性があります。

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

ログを簡単に確認したところ、障害発生時点で、オフセットのシーケンスに対する 8 つのキューに入れられた要求のうち 8 番目が DECO ウォッチドッグタイムアウトエラーを生成しているようです。ログの前半部分では、他のオフセットのシーケンスを処理する場合でも、キューに入れられたリクエストはほとんどないようです (場合によっては 1 つあるかもしれません)。これは手がかりですか？

この前の 7 つのキューに入れられたリクエストは正常に完了しているようですので、次のいずれかが原因である可能性があります...

キューは実際には 7 つのエントリのみをサポートします。このCASE、キューに入れられるエントリの数を減らすと役立つ可能性があります (どこでこれを変更CANか?)
DECO ウォッチドッグタイムアウトは、エントリがキューに追加されたときに開始され、8 つのエントリを処理するのにかかる時間によって単純に期限切れになります。この場合、タイムアウト期間を延長すると役立つ可能性があります (再度、可能であれば、どこでこれを変更できますか)。
この特定のリクエストには実際に問題がありますが、私には前の7つのリクエストと同等に見えるSO、これはありそうにありません。

よろしくお願いします。

ダニエル

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

いいえ、dd または fio では再現できませんでした。前回のログをキャプチャしたシステムでは、この問題はごくまれにしか発生しません (これまでのところ 2 か月に 1 回)。

若干異なるコードを持つ別のシステムでは、少なくとも 1 日に 1 回は発生します。これは、起動時に大量の共有ライブラリをロードするときに発生すると考えられます (ログを取得したシステムでは使用されません)。残念ながら、このバージョンからログを簡単に収集することはできませんが、比較的迅速にパッチをテストして問題が解決されているかどうかを確認することはできます。

以前のログには調査に十分な情報が含まれていますか?そうでない場合、他に何が必要でしょうか?

Re: iMX8MM CAAM errors when using 'tk(cbc(aes))' for filesystem encryption

ログを入手したので、自分でさらに調査してみることにしました。システムのメモリ負荷が高くても、DDR が 400MT/s (この場合は 100MT/s になることもある) で動作している場合、CAAM がウォッチドッグエラーを生成することがあるようです。

eMMC ドライバは DDR を 3000MT/s に強制しますが、書き込みの場合、暗号化が実行されるまでは必ずしもこれが実行されるわけではありません。

私たちのユースケースでは、`caam_jr_enqueue()` で ` BUS_FREQ_HIGH` を要求し、`caam_jr_dequeue()` からのスケジュールされた作業を介してそれを再度解放することで、これを修正しました。

これはファイルシステムのアクセスを修正しますが、ネットワークスタックから呼び出される場合（たとえばxfrm経由）に問題が発生します。`request_bus_freq()`は最終的にアトミックコンテキストで（ネットワークスタックのずっと上から）呼び出され、`request_bus_freq()`と`clk_xxx()`の両方の呼び出しがミューテックスの

私たちは、ファイルシステム以外では CAAM の使用を無効にすることでこの問題を回避しましたが、アップストリームの場合はより良い解決策が必要になります。