2391427_ja-JP

Yes

S32N55 HSE2 CRS セキュアデバッグ: SDC-600 TX FIFO が 20 バイト後に停止する

こんにちは、

CRSドメインのSecure Debug認証の問題についてのフォローアップ
前回の投稿(「S32N55 HSE2 CRSドメイン認証」で議論されています
「未完了」)、より具体的な新発見を報告したい
私はそれが根本原因を示していると信じています。これを別々に投稿します
提案した。

セットアップ:
- S32N55、HSE2、CRSドメイン(APP_CHALLENGE)、ラウターバッハTRACE32 / SDC-600
- 認証フロー:COMM_START -> AUTH_MODE_REQ -> APP_CHALLENGE(StartCmd)
-> チャレンジを受信 -> ProofProvCmd (debugSignalMap(4B) + を送信
appChallengeAuth(16B) via AES-CMAC)

調査結果：
debugSignalMap(4B) + appChallengeAuth(16B) = 20バイトを送信後
ProofProvCmdパケットを介した合計、ホストのSDC-600 TX FIFOステータス
レジスタ（MU ベース +0xD2C のビット [7:0]）は、二度と空き領域を報告しません。
言い換えれば、HSE2はSDC-600チャネルの排水を停止しているように見えます。
まさにこの20バイトの境界線です。ホストの低レベルのSend()ルーチン
このステータスレジスタはタイムアウトなしでビジーウェイトループでポーリングしますので、
この時点で無期限にブロックされています。

この動作は、16バイトの後に何が続くかに関わらず一貫しています。
appChallengeAuth:
- 追加のパディングバイトを追加するかどうか（
debugAuthProof を 32 バイトに結合して、またはそれ以上何も送信せずに
FLAG_ENDに直接到達すると、FIFOは同じ20バイトでドレインを停止します。
ポイント。これは問題がパケット長やフレーミングではないことを示唆しています
不一致ですが、そのHSE2はすぐにチャネルのサービスを停止します
16バイトのappChallengeAuthを受け取りました。

質問:
これはAPP_CHALLENGEフローに対して期待される挙動でしょうか(例:HSE2は
ホストの他の動きを待つためにここで一旦一旦止めてください
チャネルの排水を続けているのか、それとも
この時点で受信したパケット内容(debugSignalMapまたは
appChallengeAuth)がHSE2側で却下・誤った形で通知されたのでしょうか?

参考までに:
- FSSドメイン(FSS_CHALLENGE)認証と同等のフロー
同じSend()を用いて(AUTHSTATUS=0xBBB)正常に完了します。
ルーチンおよびSDC-600ベースで、4B信号マップ+32B応答を送信します。
子供はない。
- CRSドメイン（APP_CHALLENGE）ターゲット = HSE_DEBUG_DOMAIN_APP（0x1B）、
hse_srv_debug_auth_protocol.h に対して確認済み。

APP_CHALLENGEのこの段階でHSE2が何を期待しているかについてのガイダンスはありますか？
フローを教えていただけると大変ありがたいです。

ありがとう、

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、チェンインさん

ご指導と脚本の校閲、ありがとうございました。

スクリプトの問題に関する詳細なフィードバックをお待ちしています。
修正プログラムの準備が整い次第、適用してください。

二段階アプローチに関して、我々が現在どのような立場にあるのかを明確にするために
あなたが提案した: 我々が報告したハング (SDC-600 TX FIFO がもはや
debugSignalMap + appChallengeAuth の後にドレインが発生すると、
フェーズ1の終了時、具体的には送信直後
hseDebugAuthorizeProofProvCmd_t に進む前に
hseDebugCardCmd_t は全くありません。ですので、フェーズ1はまだ確認されていません
エンドツーエンドで成功裏に完了します。現在、この数列はで停止しています。
このまさにフェーズ2(CardCmd)に到達する前の段階です。

お客様からのフィードバックを受け取り次第、以下の対応をいたします。
1. スクリプトに修正を適用する。
2. 段階的アプローチに従って再テストし、応答を記録します。
hseDebugCommStartCmd_t から各コマンドまで
hseDebugAuthorizeProofProvCmd_t を個別に確認し、
次のステップに進む前に、各ステップにおける期待値を算出する。
3.フェーズ 1 が完了したら、hseDebugCardCmd_t の検証に進んでください。
正常に完了したことが確認されました。
4. 更新されたログを報告してください。

改めて、皆様のサポートに感謝します。

よろしくお願いします、
エディ

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、 @EddiePark

投稿ありがとうございます。

1. ご提供いただいた元のスクリプトを確認したところ、いくつか問題点が見つかりました。近日中にフィードバックをお送りいたします。

レビューの過程で、文書化された手順と一致しないと思われるいくつかの問題点が判明しました。したがって、実際のパケット交換とHSE FW インターフェースのコメントで説明されている要件を慎重に比較することをお勧めします。

2. スクリプトで見つかった問題を修正したら、テストを行い、ログを確認します。

3. それでも問題が解決しない場合は、デバッグ手順を2つのフェーズに分けて、問題を特定することをお勧めします。
まず最初に、hseDebugCommStartCmd_t から hseDebugAuthorizeProofProvCmd_t までの認証シーケンスが正常に完了することを確認してください。そして、各コマンドの応答をログに記録し、次の段階に進む前に、返された値が期待どおりであることを確認します。

第2段階では、hseDebugCardCmd_tに注目してください。HSE FW Interfaceドキュメントに記載されたコメントに基づき、このステップに関わるすべてのパケットを厳格に検証し、その内容と順序が文書化された要件に合致しているかを確認することをお勧めします。

BR

チェイン

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、 @EddiePark

先週、メッセージ機能を使って送信しました。以前あなたが共有してくれたスクリプトはプライベートメッセージ経由だったので。メッセージボックスで確認できます。

ご迷惑をおかけして申し訳ございません。

BR

チェイン

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、陳音さん、

CRS APPドメインスクリプトのレビューに関する以前のご回答、ありがとうございました。2段階デバッグ手法に関するご指導に心より感謝申し上げます。

ご指摘いただいた詳細なスクリプトに関するフィードバック（「近日中にフィードバックをお送りします」とのことでした）をまだ受け取っていないため、状況を確認するためにご連絡いたしました。

皆様からのフィードバックに備えるため、すでに以下の準備を進めております。

1. ご提案の2段階アプローチをサポートするためのcrs_auth.cmmスクリプトでの強化ログ機能:
- フェーズ1(CommStart → ProofProv):各コマンド(AUTH_MODE_REQ、APP_CHALLENGE、ProofProv)に対してPASS/FAIL検証付きの段階的な応答ログを追加
- フェーズ2(CardCmd):HSE FW Interfaceドキュメントに基づくパケット内容および順序の検証準備完了

2. 詳細な実行ログの作成:
- 各コマンドの応答バイト
- ライフサイクル状態復号(OEM_OPEN vs OEM_CLOSED)
- 認証モード確認
- チャレンジ受容の検証
- ProofProv応答状態(現在、HSE2はProofProv後に沈黙のままであり、FSSドメインは0x4A4A4A4Aを返すのとは対照的です)

お客様(42dot)の配送スケジュールが近づいている中で、以下の点についてアドバイスいただけますか:

1. 詳細な脚本フィードバックのおおよその所要時間は？
2. フィードバックをお待ちいただく間、パケット構造やコマンドシーケンスに関して、特に注意すべき点はありますか？

私たちはこの問題の解決に引き続き尽力しており、さらなるご助言をいただければ大変ありがたく存じます。

引き続きご支援いただきありがとうございます。

よろしくお願いします、

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、

プラットフォーム:S32N55(HSE2)、SDC600 / TRACE32 CMMによるセキュアデバッグ
ドメイン:APP(CRS)
認証モード:チャレンジ(認証モード=0)

私はデバッグカード認証フローを実装しています。チャレンジ -> ProofProv フェーズは正常に動作します: APP_CHALLENGE の後、32 バイトのチャレンジを受け取り、計算します

appChallengeAuth = AES256-CMAC(key, challenge) // 16バイト

そしてそれをhseDebugAuthorizeProofProvCmd_tで送信します。

私の質問は、CARD_REQUESTフェーズ（hseDebugCardCmd_t / hseDebugCardInfo_t）についてです。現在のスクリプトでは、AuthTagフィールドには上記のappChallengeAuthと同じ値（つまり、受信したチャレンジに基づいて計算されたCMAC）が入力されます。カード認証は拒否されました。

カードリクエスト内のAuthTagに実際に署名する必要があるのはどのようなものなのか確認したいです。

1. カードのAuthTagは、appChallengeAuth（受信したチャレンジに対するCMAC）と同じ値ですか？

または

2. AuthTagは、hseDebugCardInfo_t構造体（同じリクエストで送信されるカード情報）に基づいて計算された、別のCMACである必要がありますか？

もし(2)なら、確認していただけますか:
- CMACに入力される正確なバイト範囲(全体の構造体を含む)authKeyRef/reserved、または特定のサブセット)、
- numOfAllowedUids = 0の場合にuidListが含まれているかどうか
- AES-CMACで使用するauthSchemeの値と、それが署名データの一部であるかどうか、
- 直列化された構造体のパッキング/エンディアンの仮定。

参考までに、私がデータを書き込んでいる構造体は以下のとおりです。

typedef struct
ヤージュ
uint8_t authKeyRef;
uint8_t reserved0[3U];
hseOid_t ownerId; // 16バイト
hseDebugCardAuthScheme_t authScheme;
uint64_t enabledDebugDomainMap; // CRS = ビット 22～26 -> 0x0000000007C00000
組合 {
hseDebugSignal_t debugDomainSignalList[HSE_MAX_NUM_OF_DEBUG_DOMAINS];
uint8_t reserved1[64U];
} debugDomainSignalList;
uint8_t numOfAllowedUids;
uint8_t reserved2[3U];
uint8_t uidList[HSE_MAX_UID_LIST_SIZE][HSE_UID_SIZE];
} hseDebugCardInfo_t;

HSE FW API RMには、デバッグカードのAuthTagがどのデータから計算されるか明示されていないようなので、明確な回答をいただけると助かります。

よろしくお願いします。

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、

プラットフォーム:S32N55(HSE2)、SDC600(APBCOM @ DP:0x5BFF8000)によるSecure Debug、TRACE32 CMMから駆動。

FSSドメインではSecure Debug認証(AUTHSTATUS = 0xBBB)が動作しています。現在、まったく同じSDC600ベースアドレスとホスト側のSENDルーチンを使用してAPP（CRS）ドメインを起動していますが、送信時に問題が発生しました。

観察:
- FSSドメイン:32バイトのペイロードをSDC600経由でストールなく送信できます。
- APP (CRS) ドメイン: 送信がちょうど 16 バイト後に停止します。

私のSENDルーチンは、各バイトをTXデータレジスタ（ベース+0xD20）に書き込み、書き込みの前に、TXステータスレジスタ（ベース+0xD2C、下位バイト）でFIFOの空き領域を待機します。

WHILE (Data.Long(&base+0xD2C) & 0x000000FF) == 0x00000000
( ) ; TX FIFO スペースが空くのを待つ

APPドメインでは、16バイトを超えるとこのステータスは0（空き領域なし）のまま無期限に維持されます。つまり、HSE2側はTX FIFOを16バイトを超えて消費しないようです。FSSドメインでは、同じコードが停止することなく32バイトをストリーミングします。

ベースアドレスとSENDコードは両方のドメインで同じであるため、これはターゲットのデバッグドメインに応じて、HSE2がSDC600 RX（ホストTX）FIFOをドレインするタイミングやそのかどうかが異なることを示しているようです。

質問:
1.HSE2がAPP(CRS)ドメインのためにSDC600 TX FIFOの使用を開始するタイミングは何によって決まるのでしょうか？必須条件/握手はありますか（例：HSE2がAPP上で16バイト以上を消費する前に満たされなければならない条件（ProofProv応答の読み取り、ステータスビット、またはRX有効化）は何ですか？
2. SDC600のフロー制御／FIFO消費動作において、FSSとAPP間でドメインごとの違いはありますか？
3. このデバイスにおける実際のSDC600 TX FIFOの深さはどれくらいですか？また、0xD2C[7:0]は「TX FIFOの空き容量」をポーリングするための正しいフィールドですか？具体的にどの部分を使用すべきですか？
4. APPドメイン上のFIFO深度よりも大きいペイロードの場合、ホストの送信シーケンスはどのようになりますか？

関連するかもしれない追加の背景情報:
- NOBLOCKモードでProofProv(hseDebugAuthorizeProofProvCmd_t)を送信した後、HSE2は応答を返し、それを読み返すことができる(hseDebugAuthorizeProofProvResponse_t)。私が読み取った4バイトの結果は0x7A 0xB3 0x08 0x00です。これがAPPドメインのProofProvの成功を示しているかどうかについても確認していただけると幸いです。

よろしくお願いします。

Re: S32N55 HSE2 CRS Secure Debug: SDC-600 TX FIFO stalls after 20 bytes

こんにちは、 @EddiePark

ご返信ありがとうございます。

以前のご質問について：

1. ProofProvをAPPドメインに送信する必要があるかどうかを確認してください。

- APPに対してProofProvを一切送信しない（tx_response呼び出しを完全にスキップする）？
- または、ProofProvを送信するが、応答を待たない（現在試行中）？

[コメント]: フェーズ 1 のProofProvは APP ドメインに対して送信する必要があります。

2. ProofProv の後にスクリプトが停止する原因は何でしょうか？（もし必要であれば）

[コメント]: フェーズ 1 で ProofProv を送信した後、HSE FW からの応答を読み取って、デバッグプロセスが正常に動作したかどうかを確認する必要があります (hseDebugAuthorizeProofProvResponse_t)。その応答が想定どおりのものかどうか確認してください。

BR

チェイン