この資料は表記のバージョンの英語版を翻訳したもので、内 …...が hsm...

Bootgen ユーザーガイドUG1283 (v2018.3) 2018 年 12 月 21 日

この資料は表記のバージョンの英語版を翻訳したもので、内容に相違が生じる場合には原文を優先します。資料によっては英語版の更新に対応していないものがあります。日本語版は参考用としてご使用の上、最新情報につきましては、必ず最新英語版をご参照ください。

https://www.xilinx.com

目次改訂履歴..........................................................................................................................................................................5

第 1 章: はじめに...................................................................................................................................................... 6Bootgen のインストール............................................................................................................................................... 6ブート時のセキュリティ................................................................................................................................................ 9

第 2 章: ブートイメージレイアウト..................................................................................................... 10Zynq-7000 SoC のブートおよびコンフィギュレーション..........................................................................................10Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーション.........................................................................19

第 3 章: ブートイメージの作成................................................................................................................. 30ブートイメージフォーマット (BIF)............................................................................................................................30BIF 構文およびサポートされるファイルの種類..........................................................................................................31属性および説明............................................................................................................................................................. 32

第 4 章: Bootgen インターフェイスの使用.......................................................................................38Bootgen GUI のオプション......................................................................................................................................... 38コマンドラインで Bootgen を使用............................................................................................................................ 40コマンドおよび説明......................................................................................................................................................40

第 5 章: ブート時のセキュリティ............................................................................................................. 43暗号化の使用.................................................................................................................................................................44認証の使用.....................................................................................................................................................................51HSM モードの使用........................................................................................................................................................59

第 6 章: FPGA のサポート................................................................................................................................ 73暗号化および認証......................................................................................................................................................... 73HSM モード...................................................................................................................................................................74

付録 A: ユースケースおよび例.................................................................................................................... 77異なるコアでのシンプルアプリケーションブート................................................................................................... 77bootROM による PMUFW のロード............................................................................................................................77FSBL による PMUFW のロード.................................................................................................................................... 78Linux のブート..............................................................................................................................................................78暗号化フロー: BBRAM レッドキー............................................................................................................................. 78暗号化フロー: eFUSE に格納されたレッドキー.........................................................................................................79暗号化フロー: eFUSE に格納されたブラックキー..................................................................................................... 79暗号化フロー: ブートヘッダーに格納されたブラックキー......................................................................................80

UG1283 (v2018.3) 2018 年 12 月 21 日 japan.xilinx.comBootgen ユーザーガイド 2

https://japan.xilinx.com

https://japan.xilinx.com/about/feedback.html?docType=User_Guides&docId=UG1283&Title=Bootgen%20%26%2312518%3B%26%2312540%3B%26%2312470%3B%26%2312540%3B%20%26%2312460%3B%26%2312452%3B%26%2312489%3B&releaseVersion=2018.3&docPage=2

暗号化フロー: eFUSE に格納されたグレーキー.........................................................................................................80暗号化フロー: ブートヘッダーに格納されたグレーキー..........................................................................................81操作キー........................................................................................................................................................................ 81操作キーを使用して開発環境のデバイスキーを保護する......................................................................................... 81認証フロー.....................................................................................................................................................................84SHA-3 eFUSE RSA 認証と PPK0 を使用する BIF ファイル......................................................................................... 84XIP................................................................................................................................................................................. 84

付録 B: BIF 属性の参照.....................................................................................................................................85aeskeyfile...................................................................................................................................................................... 85alignment..................................................................................................................................................................... 87auth_params................................................................................................................................................................ 87authentication..............................................................................................................................................................89bh_keyfile......................................................................................................................................................................89bh_key_iv.......................................................................................................................................................................90bhsignature..................................................................................................................................................................90blocks............................................................................................................................................................................ 91boot_device.................................................................................................................................................................. 91bootimage.................................................................................................................................................................... 92bootloader....................................................................................................................................................................93bootvectors.................................................................................................................................................................. 94checksum......................................................................................................................................................................94destination_cpu........................................................................................................................................................... 95destination_device.......................................................................................................................................................95early_handoff............................................................................................................................................................... 96encryption.................................................................................................................................................................... 97exception_level.............................................................................................................................................................97familykey.......................................................................................................................................................................98fsbl_config.................................................................................................................................................................... 98headersignature.......................................................................................................................................................... 99hivec............................................................................................................................................................................ 100init................................................................................................................................................................................100keysrc_encryption......................................................................................................................................................101load............................................................................................................................................................................. 101offset........................................................................................................................................................................... 102partition_owner......................................................................................................................................................... 102pid................................................................................................................................................................................103pmufw_image............................................................................................................................................................ 103ppkfile......................................................................................................................................................................... 104presign........................................................................................................................................................................104pskfile..........................................................................................................................................................................105puf_file........................................................................................................................................................................ 106reserve........................................................................................................................................................................ 106split..............................................................................................................................................................................107spkfile..........................................................................................................................................................................108spksignature.............................................................................................................................................................. 108spk_select................................................................................................................................................................... 109




sskfile.......................................................................................................................................................................... 110startup........................................................................................................................................................................ 110TrustZone................................................................................................................................................................... 111udf_bh......................................................................................................................................................................... 111udf_data......................................................................................................................................................................112xip_mode.................................................................................................................................................................... 113

付録 C: コマンドリファレンス................................................................................................................ 114arch............................................................................................................................................................................. 114bif_help....................................................................................................................................................................... 114dual_qspi_mode.........................................................................................................................................................115efuseppkbits...............................................................................................................................................................115encrypt........................................................................................................................................................................116encryption_dump...................................................................................................................................................... 116fill................................................................................................................................................................................. 117generate_hashes....................................................................................................................................................... 117generate_keys............................................................................................................................................................ 118image.......................................................................................................................................................................... 119log................................................................................................................................................................................120nonbooting.................................................................................................................................................................120o...................................................................................................................................................................................121p...................................................................................................................................................................................121padimageheader....................................................................................................................................................... 122process_bitstream..................................................................................................................................................... 122spksignature.............................................................................................................................................................. 123split..............................................................................................................................................................................123w.................................................................................................................................................................................. 124zynqmpes1................................................................................................................................................................. 124初期化ペアおよび INIT ファイルの属性について..................................................................................................... 124

付録 D: Bootgen ユーティリティ............................................................................................................ 126

付録 E: その他のリソースおよび法的通知.........................................................................................128Documentation Navigator およびデザインハブ.................................................................................................... 128ザイリンクスリソース............................................................................................................................................... 128Bootgen リソース...................................................................................................................................................... 128お読みください: 重要な法的通知...............................................................................................................................129




改訂履歴次の表に、この文書の改訂履歴を示します。

セクション改訂内容2018 年 12 月 21 日 v2018.3

一般的なアップデート。編集上のわずかな変更。2018 年 9 月 24 日 v2018.2

初版 N/A




第 1 章

はじめにザイリンクスの FPGA およびシステムオンチップ (SoC) デバイスは、通常、複数のハードウェアおよびソフトウェアバイナリを備え、これらを使用して設計どおりに機能するよう起動します。バイナリには、FPGA ビットストリーム、ファームウェアイメージ、ブートローダー、オペレーティングシステム、および非セキュアな方法とセキュアな方法の両方でロード可能なユーザー指定のアプリケーションが含まれます。Bootgen は、バイナリファイルを統合してデバイスブートイメージを生成するザイリンクスツールです。このツールは、ザイリンクスデバイスで使用するブートイメージの作成時に入力される複数のプロパティ、属性、およびパラメーターを定義します。Zynq®-7000 デバイスのセキュアブートには、公開キーおよび秘密キーの暗号化アルゴリズムを使用します。Bootgen は各パーティションに対して特定のデスティネーションメモリアドレスを割り当て、アライメント要件を与えます。また、暗号化の使用および認証の使用で説明するように、暗号化と認証もサポートしています。より高度な認証フローとキー管理オプションについては、HSM モードの使用で説明しています。HSM モードでは、Bootgen は、秘密キーを使用してオフラインで署名可能な中間ハッシュファイルを出力し、ブートイメージに含まれる認証証明に署名することができます。このプログラムがパーティションリストにヘッダーブロックを加えることでブートイメージを構築します。各パーティションは、Bootgen によってオプションで暗号化したり、認証したりできます。出力は、システムのブートフラッシュメモリへ直接プログラムできるシングルファイルです。認証や暗号化をサポートするさまざまな入力ファイルも、このツールで生成できます。詳細は、BIF 構文およびサポートされるファイルの種類を参照してください。Bootgen には GUI インターフェイスとコマンドラインオプションの両方があります。Bootgen はソフトウェア開発ツールキット (SDK) に統合されており、基本的なブートイメージの生成には GUI を使用しますが、オプションの大部分はコマンドライン駆動型です。コマンドラインオプションはスクリプトで記述できます。Bootgen ツールは、ブートイメージフォーマット (BIF) のコンフィギュレーションファイル (*.bif) で駆動されます。Bootgen には、Zynq-7000 SoC に加えて、ザイリンクス 7 シリーズ以降の FPGA のパーティションを暗号化して認証する機能が備わっています (FPGA のサポート参照)。ブートイメージのビヘイビアーを定義するコマンドおよび属性がサポートされているだけでなく、Bootgen での作業に役立つユーティリティもあります。

Bootgen のインストールBootgen は、ザイリンクスソフトウェア開発キット (SDK) およびザイリンクスソフトウェアコマンドラインツール(XSCT) のブートイメージ作成ツールです。ブートイメージを簡単に作成するには Bootgen を GUI モードで使用し、より複雑なブートイメージを作成する場合はコマンドラインモードで使用します。コマンドラインモードのコマンドもスクリプトで記述できます。Bootgen は、SDK または Vivado Design Suite インストーラーからインストールするか、スタンドアロンでインストールできます。SDK は Vivado® Design Suite をインストールすると使用できるようになります。または、個別にダウンロードしてインストールします。可能なすべてのインストールオプションの詳細は、『Vivado Design Suite ユーザーガイド: リリースノート、インストールおよびライセンス』 (UG973) を参照してください。Vivado から Bootgen をインストールするには、ザイリンクスダウンロードサイトに移動し、次の図に示すようなVivado 自己解凍型インストーラーを選択します。

第 1 章: はじめに


https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;t=vivado+install+guide

https://japan.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools.html



図 1: Vivado 自己解凍型インストーラー

Vivado をインストールする際に SDK をインストールするオプションを選択します。Bootgen は SDK と共に含まれます。また、SDK インストーラーから Bootgen をインストールすることもできます。次の図に、ザイリンクスダウンロードサイトにある SDK 自己解凍型インストーラーを示します。

図 2: SDK インストーラー

次に、SDK インストーラーで XSCT またはスタンドアロンバージョンの Bootgen をダウンロードするオプションを示します。



https://japan.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools.html

https://japan.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-design-tools.html



図 3: SDK インストーラー

SDK インストーラーで [Download Full Image] を選択してオフラインでインストールすることもできます。このオフラインインストールは、HSM モードを使用する設計者にとって重要な機能です。詳細は、HSM モードの使用を参照してください。SDK と Bootgen をインストールしたら、SDK GUI または XSCT からこのツールを呼び出して使用できます。SDKGUI オプションには、短時間での開発および試行を可能にする最も一般的なアクションが含まれています。コマンドラインオプションには、ブートイメージを実装するためのさらに多くのオプションが用意されています。GUI およびコマンドラインオプションの詳細は、第 4 章: Bootgen インターフェイスの使用を参照してください。• SDK GUI からの起動および使用は、Bootgen の GUI オプションを参照してください。• XSCT オプションを使用するコマンドラインからの起動および使用は、コマンドラインで Bootgen オプションを使用するを参照してください。

SDK に関するさらに詳しい情報は、SDK ヘルプ (UG782) を参照してください。



https://japan.xilinx.com/html_docs/xilinx2018_3/SDK_Doc/index.html



ブート時のセキュリティ最新の認証方法によるセキュアブートは、ザイリンクスデバイス上で認証されていないコードまたは変更されたコードが実行されないようにし、さまざまな暗号化テクニックがロードされるためイメージにアクセスできるのは承認されたプログラムのみとなります。デバイス固有のハードウェアセキュリティ機能の詳細は、次の資料を参照してください。• 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版)

• 『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

Bootgen を使用する場合のコンテンツの暗号化および認証の詳細は、暗号化の使用および認証の使用を参照してください。Bootgen ハードウェアセキュリティモニター (HSM) モードでは、BIF 属性は RSA 秘密キーではなく公開キーを使用するため、キー処理のセキュリティが向上します。HSM はセキュアキー/署名生成デバイスであり、秘密キーを生成し、秘密キーを使用してパーティションの暗号化を実行し、RSA キーの公開部分を Bootgen に提供します。秘密キーが HSM の外部に出ることはありません。Bootgen HSM モードでの場合は、BIF は HSM によって生成された公開キーと署名を使用します。詳細は、HSM モードの使用を参照してください。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1085-zynq-ultrascale-trm.pdf



第 2 章

ブートイメージレイアウトこの章では、各アーキテクチャのブートイメージのフォーマットについて説明します。• Zynq-7000 デバイスでの Bootgen の使用に関しては、Zynq-7000 SoC のブートおよびコンフィギュレーションを参照してください。

• Zynq® UltraScale+™ MPSoC デバイスでの Bootgen の使用に関しては、Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーションを参照してください。

• ザイリンクスデバイスでの Bootgen の使用方法に関しては、第 6 章: FPGA のサポートを参照してください。ブートイメージをビルドするには、次の手順を実行します。1. BIF ファイルを作成します。2. Bootgen 実行ファイルを実行してバイナリファイルを作成します。注記: Quick Emulator (QEMU) では、バイナリファイルをブートデバイスに対応するイメージフォーマットに変換する必要があります。各デバイスには、それぞれのブートイメージを生成する特定フォーマットのファイルが必要です。次のトピックでは、各デバイスに必要なブートヘッダー、イメージヘッダー、パーティションヘッダー、初期化、および認証証明ヘッダーのフォーマットについて説明します。

Zynq-7000 SoC のブートおよびコンフィギュレーションこのセクションでは、Zynq®-7000 SoC のブートおよびコンフィギュレーションシーケンスについて説明します。使用可能な FSBL (第 1 段階ブートローダー) 構造の詳細は、『Zynq-7000 SoC テクニカルリファレンスマニュアル』(UG585) を参照してください。

Zynq-7000 SoC の bootROM

bootROM は、アプリケーションプロセッシングユニット (APU) で実行する最初のソフトウェアです。bootROM は最初の Cortex™ プロセッサ A9-0 で実行され、同時に 2 番目のプロセッサである Cortex A9-1 によって WFE (Wait forEvent) 命令が実行されます。bootROM の主なタスクは、システムをコンフィギュレーションし、FSBL をブートデバイスからオンチップメモリ (OCM) へコピーした後、OCM へコードの実行を分岐します。

第 2 章: ブートイメージレイアウト


https://japan.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf



オプションとして、非セキュアな環境では、FSBL を Quad-SPI または NOR デバイスから直接実行できます。マスターブートデバイスは、1 つまたは複数のブートイメージを保持します。1 つのブートイメージは、ブートヘッダーと FSBL (第 1 段階ブートローダー) で構成されます。ブートイメージにはさらに、プログラマブルロジック (PL)、SSBL (第 2 段階ブートローダー)、およびエンベデッドオペレーティングシステムとアプリケーションが含まれます。ただし、bootROM はこれらにアクセスできません。bootROM の実行フローは、ブートモードのピンストラップの設定、ブートヘッダー、およびシステムによって影響を受けます。bootROM は、暗号化された FSBL を使用するセキュアな環境または非セキュアな環境のいずれでも実行できます。サポートされるブートモードは次のとおりです。• 開発およびデバッグのプライマリモードは JTAG です。• デバイスのブートには、NAND、パラレル NOR、シリアル NOR (Quad-SPI)、およびセキュアデジタル (SD) フラッシュメモリが使用されます。これらのブートモードの詳細は、『Zynq SoC テクニカルリファレンスマニュアル』 (UG585) を参照してください。一般的なブートおよびコンフィギュレーションに関する質問および回答は、Zynq-7000 - ブートおよびコンフィギュレーション (AR#52538) を参照してください。

Zynq-7000 SoC のブートイメージレイアウト次の図は、Zynq®-7000 SoC ブートイメージに含まれるコンポーネントを示しています。



https://japan.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/support/answers/52538.html



図 4: ブートヘッダー

Boot Header

Register Initialization Table

Image Header Table

.

.

.

Header Authentication Certificate (Optional)

Partition 1 (FSBL)

Image Header 1

_ _ _

AC(Optional)

Image Header 2

Image Header n

Partition Header 1

_ _ _Partition Header 2

Partition Header n

Partition 2AC

(Optional)

Partition nAC

(Optional)

Zynq-7000 SoC のブートヘッダーBootgen は、ブートイメージの先頭にブートヘッダーを付加します。ブートヘッダーテーブルは、FSBL などのプライマリブートローダーのブートに関連する情報を含む構造となっています。ブートイメージ全体にこのような構造が 1 つだけあります。bootROM はこのテーブルを解析して、FSBL がフラッシュのどこに格納されていて、OCM のどこにロードする必要があるかを判断します。一部の暗号化および認証に関連するパラメーターもここに格納されます。その他のブートヘッダーコンポーネントは次のとおりです。• Zynq-7000 SoC のレジスタ初期化テーブル• Zynq-7000 SoC のイメージヘッダーテーブル• Zynq-7000 SoC のパーティションヘッダーさらに、ブートヘッダーには Zynq-7000 SoC のレジスタ初期化テーブルが含まれます。bootROM は、ブートヘッダーを使用して、FSBL の位置と長さ、および FSBL に制御を渡す前にシステムを初期化するために必要なその他の情報を検索します。次の表に、Zynq®-7000 SoC ブートヘッダーのアドレスオフセット、パラメーター、および説明を示します。





表 1: Zynq-7000 SoC ブートヘッダーアドレスオフセットパラメーター説明

0x00-0x1F Arm® ベクターテーブル Bootgen によってダミーベクターテーブルで埋められます (Armオペコード 0xEAFFFFFE、初期化されていないベクターの検出を目的とした分岐-セルフ間の無限ループ)。0x20 幅検出ワードこれは、QSPI フラッシュがシングル/デュアルスタックモードであるか、デュアルパラレルモードであるかを識別するために必要です。これは、リトルエンディアンフォーマットの 0xAA995566 です。0x24 ヘッダー署名バイトオーダーで 4 バイトの「X」、「N」、「L」、「X」を含みます。これは、リトルエンディアンフォーマットの 0x584c4e58 です。0x28 キーソースデバイス内の暗号化キーの場所:

0x3A5C3C5A: BBRAM に格納されている暗号化キー。0xA5C3C5A3: eFUSE に格納されている暗号化キー。0x00000000: 暗号化なし。

0x2C ヘッダーバージョン 0x01010000

0x30 ソースオフセットこのイメージファイル内の FSBL (ブートローダー) の場所。0x34 FSBL イメージの長さ復号化後の FSBL の長さ。0x38 FSBL ロードアドレス (RAM) デスティネーション RAM アドレス。このアドレスに FSBL をコピーします。0x3C FSBL 実行アドレス (RAM) FSBL 実行のエントリベクター。0x40 FSBL イメージ全体の長さ暗号化後の FSBL の合計サイズ、認証証明 (ある場合) およびパディングを含みます。0x44 QSPI コンフィギュレーションワード 0x00000001 にハードコードされます。0x48 ブートヘッダーチェックサムオフセット 0x20 ～ 0x44 のワードの合計。ワードはリトルエンディアンと見なされます。

0x4c - 0x97 ユーザー定義フィールド 76 バイト0x98 イメージヘッダーテーブルオフセットイメージヘッダーテーブルを指すポインター (ワードオフセット)。0x9C パーティションヘッダーテーブルオフセットパーティションヘッダーテーブルを指すポインター (ワードオフセット)。

Zynq-7000 SoC のレジスタ初期化テーブルBootgen のレジスタ初期化テーブルの構造は、MIO マルチプレクサーおよびフラッシュクロックの PS レジスタを初期化するために使用する 256 のアドレスと値のペアです。詳細は、レジスタ初期化ペアおよび INT ファイルの属性についてを参照してください。表 2: Zynq-7000 SoC のレジスタ初期化テーブル

アドレスオフセットパラメーター説明0xA0 ～ 0x89C レジスタ初期化ペア: <address>:<value>: アドレス = 0xFFFFFFFF の場合、そのレジスタはスキップされ、値は無視されます。

未使用のレジスタフィールドはすべて、 Address=0xFFFFFFFF およびvalue = 0x0 に設定する必要があります。





Zynq-7000 SoC のイメージヘッダーテーブルBootgen は、ELF ファイル、ビットストリーム、データファイルなどからデータを抽出してブートイメージを作成します。データが抽出されるこれらのファイルは、イメージと呼ばれます。各イメージには、1 つまたは複数のパーティションを含めることができます。イメージヘッダーテーブルは、これらすべてのイメージに共通する情報と、イメージの数、ブートイメージに含まれるパーティション、およびほかのヘッダーテーブルへのポインターといった情報を含む構造です。次の表に、Zynq®-7000 SoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 3: Zynq-7000 SoC のイメージヘッダーテーブルアドレスオフセットパラメーター説明

0x00 バージョン 0x01010000: 使用可能なフィールドは 0x0、0x4、0x8、0xC、およびパディングです。0x01020000: 0x10 フィールドが追加されます。

0x04 イメージヘッダー数イメージ内のパーティション数。0x08 第一パーティションヘッダーオフセット第一パーティションヘッダーを指すポインター (ワードオフセット)。

0x0C 第一イメージヘッダーオフセット第一イメージヘッダーを指すポインター (ワードオフセット)。

0x10 ヘッダー認証証明オフセット認証証明ヘッダーを指すポインター(ワードオフセット)。

0x14 予約デフォルトは 0xFFFFFFFF です。

Zynq-7000 SoC のイメージヘッダーイメージヘッダーは、ELF ファイル、ビットストリーム、データファイルなど、各イメージに関連する情報を含む構造の配列です。1 つのイメージに複数のパーティションを含めることができます。たとえば、ELF には複数のロード可能なセクションを含めることができ、それぞれがブートイメージ内にパーティションを形成します。テーブルには、イメージに関連するパーティション数の情報も含まれます。次の表に、Zynq®-7000 SoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 4: Zynq-7000 SoC のイメージヘッダー

アドレスオフセットパラメーター説明0x00 次のイメージヘッダー次のイメージヘッダーにリンクします。最後のイメージヘッダーの場合は 0 となります (ワードオフセット)。0x04 対応するパーティションヘッダー最初に関連付けられたパーティションヘッダーにリンクします (ワードオフセット)。0x08 予約常に 0。0x0C パーティション数このイメージに関連付けられたパーティションの数。





表 4: Zynq-7000 SoC のイメージヘッダー (続き)

アドレスオフセットパラメーター説明0x10 ～ N イメージの名前ビッグエンディアン順に圧縮されます。文字列を再構築するため、一度に 4 バイトを解凍し、順序を逆にして連結します。たとえば、文字列「FSBL10.ELF」は次のように圧縮されます。0x10: ‘L’,’B’,’

S’,’F’, 0x14: ’E’,’.’,’0’,’1’,0x18: ’\0’,’\0’,’F’,’L’ 。圧縮されたイメージ名は 4 の倍数バイトです。

N ストリングターミネーター (終端名) 0x00000000

N+4 予約デフォルトで、64 バイト境界まで0xFFFFFFFF でパディングされます。

Zynq-7000 SoC のパーティションヘッダーパーティションヘッダーは、各パーティションに関連する情報を含む構造の配列です。各パーティションヘッダーテーブルは、ブートローダーによって解析されます。このテーブルには、パーティションサイズ、フラッシュ内のアドレス、RAM 内のロードアドレス、暗号化/署名などの情報が含まれます。FSBL を含め、各パーティションにこのような構造が 1 つあります。テーブル内の最後の構造は、すべて NULL 値となります (チェックサムを除く)。次の表に、Zynq®-7000 SoC パーティションヘッダーのオフセット、名前、および説明を示しています。注記: ロード可能なセクションが 3 つある ELF ファイルには、1 つのイメージヘッダーと 3 つのパーティションヘッダーテーブルが含まれます。表 5: Zynq-7000 SoC のパーティションヘッダー

オフセット名前説明0x00 暗号化されたパーティションの長さ暗号化されたパーティションデータの長さ。0x04 暗号化されていないパーティションの長さ暗号化されていないデータの長さ。

0x08 合計パーティションワード長 (認証証明を含む)。Zynq-7000 SoC の認証証明を参照してください。合計パーティションワード長は、パディング付きの暗号化された情報、拡張、および認証の各長さの合計です。

0x0C デスティネーションロードアドレスこのパーティションがロードされる RAM アドレス。0x10 デスティネーション実行アドレス実行時のこのパーティションのエントリポイント。0x14 イメージのデータワードオフセットブートイメージの開始に対するパーティションデータの位置。0x18 属性ビット Zynq-7000 SoC のパーティション属性ビットを参照してください。0x1C セクション数シングルパーティション内のセクション数。0x20 チェックサムワードオフセットブートイメージ内のチェックサムワードの位置。0x24 イメージヘッダーのワードオフセットブートイメージ内のイメージヘッダーの位置。

0x28 認証証明ワードオフセットブートイメージ内の認証証明の位置。0x2C - 0x38 予約予約

0x3C ヘッダーチェックサムパーティションヘッダーの以前のワードの合計値。





Zynq-7000 SoC のパーティション属性ビット次の表に、Zynq®-7000 SoC デバイスのパーティションヘッダーテーブルのパーティション属性ビットを示します。表 6: Zynq-7000 SoC のパーティション属性ビット

ビットフィールドフィールド名説明31:18 データ属性インプリメントされていません。17:16 パーティションオーナー

0: FSBL1: UBOOT2、3: 予約

15 RSA 署名の有無0: RSA 認証証明なし1: RSA 認証証明あり

14:12 チェックサムタイプ0: なし1: MD52-7: 予約

11:8 デスティネーションインスタンスインプリメントされていません。7:4 デスティネーションデバイス

0: なし1: PS2: PL3: INT4-15: 予約

3:2 ヘッドアライメントインプリメントされていません。1:0 テールアライメントインプリメントされていません。

Zynq-7000 SoC の認証証明認証証明は、パーティションの認証に関連するすべての情報を含む構造です。この構造には、公開キーと、bootROM/FSBL による検証が必要なすべての署名が含まれます。各認証証明には認証ヘッダーがあります。このヘッダーは、キーサイズ、署名に使用するアルゴリズムなどの情報を提供します。認証証明は、認証が有効になっている実際のパーティションに追加されます。認証が有効になっているすべてのパーティションに対して、ヘッダーテーブルも認証する必要があります。ヘッダーテーブル認証証明は、ヘッダーテーブルのコンテンツの最後に追加されます。Zynq®-7000 SoC は SHA-256 ハッシュアルゴリズムによる RSA-2048 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは 2048 ビットとなります。SHA-256 はセキュアハッシュアルゴリズムとして使用されるため、FSBL、パーティション、および認証証明は 512 ビット境界にパディングする必要があります。次の表に、Zynq®-7000 SoC の認証証明のフォーマットを示します。表 7: Zynq-7000 SoC の認証証明

認証証明ビット説明0x00 認証ヘッダー = 0x0101000。Zynq-7000 SoC の認証証明ヘッダーを参照してください。0x04 証明のサイズ





表 7: Zynq-7000 SoC の認証証明 (続き)

認証証明ビット説明0x08 UDF (56 バイト)

0x40 PPK Mod (256 バイト)

0x140 Mod Ext (256 バイト)

0x240 Exponent

0x244 Pad (60 バイト)

0x280 SPK Mod (256 バイト)


0x480 Exponent (4 バイト)

0x484 Pad (60 バイト)

0x4C0 SPK 署名 = RSA-2048 (PSK、パディング || SHA-256(SPK))

0x5C0 FSBL パーティション署名 = RSA-2048 (SSK、SHA-256 (ブートヘッダー || FSBL パーティション)

0x5C0 その他パーティション署名 = RSA-2048 (SSK、SHA-256 (パーティション || パディング || 認証ヘッダー || PPK || SPK || SPK 署名)

Zynq-7000 SoC の認証証明ヘッダー次の表に、Zynq®-7000 SoC の認証証明ヘッダーを説明します。表 8: Zynq-7000 SoC の認証証明ヘッダー

ビットオフセットフィールド名説明31:16 予約 0

15:14 認証証明フォーマット 00: PKCS #1 v1.5

13:12 認証証明バージョン 00: 現在の AC

11 PPK キータイプ 0: ハッシュキー10:9 PPK キーソース 0: eFUSE

8 SPK イネーブル 1: SPK イネーブル7:4 公開キー強度 0:2048

3:2 ハッシュアルゴリズム 0: SHA256

Zynq-7000 SoC のブートイメージブロック図次の図は、Zynq®-7000 SoC ブートイメージに含まれるコンポーネントを示しています。





図 5: Zynq-7000 SoC のブートイメージブロック図

X21320-081718





Zynq UltraScale+ MPSoC のブートおよびコンフィギュレーション概要Zynq® UltraScale+™ MPSoC は、QSPI フラッシュ、SD カード、USB デバイスファームウェアアップグレード (DFU)ホスト、NAND フラッシュドライブなどからのブートをサポートしています。この章では、セキュアモードと非セキュアモードの両方において各種デバイスからのブートプロセスについて説明します。ブート処理はプラットフォーム管理ユニット (PMU) とコンフィギュレーションセキュリティユニット (CSU) によって管理および実行されます。初期ブート時に、次の手順が実行されます。• PMU はパワーオンリセット (POR) によってリセット状態から復帰します。• PMU は ROM で実行されます。• PMU は SYSMON と、ブートに必要な PLL を初期化し、低電力ドメインとフル電力ドメインをクリアして CSU のリセットを開放します。

CSU は、PMU によって開放されると次を実行します。• FSBL またはユーザーアプリケーションによって認証が要求されているかを確認します。• 認証チェックを実行し、このチェックにパスした場合のみ次へ進みます。そして、イメージに暗号化されたパーティションがあるかどうかをチェックします。

• 暗号化されたパーティションを検出した場合、CSU は復号化を実行し、FSBL を OCM にロードします。CSU が暗号化されたパーティションを検出した場合、復号化を実行して OCM を初期化し、ブートモードの設定を決定し、FSBL のロードとオプションの PMU ファームウェアのロードを実行します。

• CSU ROM コードの実行後、FSBL に制御を渡します。FSBL は、PCAP インターフェイス経由でビットストリームで PL をプログラムします。

ここからは、FSBL がシステムを管理します。CSU および PMU の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) で説明します。CSU の詳細は、このリンクから『Zynq UltraScale+ MPSoC: ソフトウェア開発者向けガイド』 (UG1137) の「コンフィギュレーションセキュリティユニット」を参照してください。

Zynq UltraScale+ MPSoC のブートイメージ次の図は、Zynq® UltraScale+™ MPSoC のブートイメージを示しています。





https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf;xDeviceSecureBoot

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf



図 6: Zynq UltraScale+ MPSoC のブートイメージ

Boot Header

Register Initialization Table

Image Header Table

.

.

.

Header Authentication Certificate (Optional)

Image Header 1

_ _ _Image Header

2Image Header

n

Partition Header 1

_ _ _Partition Header 2

Partition Header n

Partition nAC

(Optional)

Partition 2AC

(Optional)

Partition 1 (FSBL)AC

(Optional)

PUF Helper Data (Optional)

PMU FW(Optional)

Zynq UltraScale+ MPSoC のブートヘッダーブートヘッダーについてBootgen は、ブートイメージの先頭にブートヘッダーを付加します。ブートヘッダーテーブルは、FSBL などのプライマリブートローダーのブートに関連する情報を含む構造となっています。ブートイメージ全体にこのような構造が 1 つだけあります。bootROM はこのテーブルを解析して、FSBL がフラッシュのどこに格納されていて、OCM のどこにロードする必要があるかを判断します。一部の暗号化および認証に関連するパラメーターもここに格納されます。ブートヘッダーコンポーネントは次のとおりです。• Zynq UltraScale+ MPSoC のブートヘッダー、ここには Zynq UltraScale+ MPSoC のブートヘッダー属性ビットも含まれる

• Zynq UltraScale+ MPSoC のレジスタ初期化テーブル• Zynq UltraScale+ MPSoC の PUF ヘルパーデータ





• Zynq UltraScale+ MPSoC のイメージヘッダーテーブル• Zynq UltraScale+ MPSoC のイメージヘッダー• Zynq UltraScale+ MPSoC の認証証明bootROM は、ブートヘッダーを使用して、FSBL の位置と長さ、および FSBL に制御を渡す前にシステムを初期化するために必要なその他の情報を検索します。次の表に、Zynq® UltraScale+™ MPSoC デバイスのアドレスオフセット、パラメーター、および説明を示します。表 9: Zynq UltraScale+ MPSoC デバイスのブートヘッダーアドレスオフセットパラメーター説明

0x00-0x1F Arm® ベクターテーブル XIP ELF ベクターテーブル:

0xEAFFFFFE: Cortex™ R5 および Cortex A53 (32 ビット) の場合0x14000000: Cortex A53 (64 ビット) の場合

0x20 幅検出ワードこのフィールドは、QSPI の幅検出に使用されます。これは、リトルエンディアンフォーマットの 0xAA995566 です。0x24 ヘッダー署名バイトオーダーで 4 バイトの ‘X’,’N’,’L’,’X’ を含みます。これは、リトルエンディアンフォーマットの 0x584c4e58 です。0x28 キーソース (FSBLのみ) 0x00000000 (暗号化なし)

0xA5C3C5A5 (eFUSE に格納されているブラックキー)0xA5C3C5A7 (eFUSE に格納されている難読化キー)0x3A5C3C5A (BBRAM に格納されているレッドキー)0xA5C3C5A3 (eFUSE に格納されているレッドキー)0xA35C7CA5 (ブートヘッダーに格納されている難読化キー)0xA3A5C3C5 (ブートヘッダーに格納されているユーザーキー)0xA35C7C53 (ブートヘッダーに格納されているブラックキー)

0x2C FSBL 実行アドレス(RAM)

0x30 ソースオフセット PMUFW がない場合は、FSBL の開始オフセットです。PMUFW がある場合は、OCM 内の PMUFW.FSBL 実行アドレスまたは XIP ベースアドレスの開始です。

0x34 PMU イメージの長さ元の PMU FW イメージの長さ (バイト) (0～128KB)。サイズ > 0 の場合、PMUFW は FSBL の前に付きます。サイズ = 0 の場合、PMUFW イメージはなしです。

0x38 PMU FW 全体の長さ OCM 内の FSBL 実行アドレスまたは XIP ベースの PMUFW イメージ全体の長さ (バイト) です。(PMUFW の長さ + 暗号化オーバーヘッド)

0x3C FSBL イメージの長さ元の FSBL イメージの長さ (バイト) (0～250KB)。0 の場合、XIP ブートイメージと見なされます。0x40 FSBL イメージ全体の長さ FSBL イメージの長さ + FSBL イメージの暗号化オーバーヘッド + 認証証明 + 64バイトアライメント + ハッシュサイズ (インテグリティチェック)。0x44 FSBL イメージ属性属性ビットを参照してください。0x48 ブートヘッダーチェックサムオフセット 0x20 ～ 0x44 のワードの合計。ワードはリトルエンディアンと見なされます。

0x4C-0x68 難読化/ブラックキーの格納難読化キーまたはブラックキーを格納します。

0x6C シャッター値 32 ビットの PUF_SHUT レジスタの値で、シャッターオフセット時間およびシャッターオープン時間を PUF に設定します。





表 9: Zynq UltraScale+ MPSoC デバイスのブートヘッダー (続き)

アドレスオフセットパラメーター説明0x70-0x94 ユーザー定義フィールド (UDF)

40 バイト。

0x98 イメージヘッダーテーブルオフセットイメージヘッダーテーブルを指すポインター (ワードオフセット)。

0x9C パーティションヘッダーテーブルオフセットパーティションヘッダーを指すポインター (ワードオフセット)。

0xA0-0xA8 セキュアヘッダーIV

ブートローダーパーティションのセキュアヘッダー用 IV。

0x0AC-0xB4 難読化/ブラックキー IV難読化キーまたはブラックキーの IV。

Zynq UltraScale+ MPSoC のブートヘッダー属性ビット表 10: Zynq UltraScale+ MPSoC のブートヘッダー属性ビットフィールド名ビットオフセット幅デフォルト説明

予約 31:16 16 0x0 予約。必ず 0。BHDR RSA 15:14 2 0x0

0x3: PPK ハッシュと SPK IDの検証を除き、ブートイメージの RSA 認証が実行されます。その他すべて: RSA 認証はeFUSE RSA ビットに基づいて決定されます。

SHA2 選択 13:12 2 0x00x3: SHA2 (廃止予定)。その他すべて: SHA3

CPU 選択 11:10 2 0x00x0: R5 シングル。0x1: A53 シングル。0x2: R5 デュアル。0x3: 予約

ハッシュ処理選択 9:8 2 0x00x0、0x1: インテグリティチェックなし。0x3: BI インテグリティチェック用の SHA3。

PUF-HD 7:6 2 0x00x3: PUF HD はブートヘッダーに格納されています。その他すべて: PUF HD はeFUSE に格納されています。

予約 5:0 6 0x0 将来使用するために予約。必ず0。





Zynq UltraScale+ MPSoC のレジスタ初期化テーブルBootgen のレジスタ初期化テーブルの構造は、MIO マルチプレクサーおよびフラッシュクロックの PS レジスタを初期化するために使用する 256 のアドレスと値のペアです。詳細は、レジスタ初期化ペアおよび INT ファイルの属性についてを参照してください。表 11: Zynq UltraScale+ MPSoC のレジスタ初期化テーブル

アドレスオフセットパラメーター説明0xB8 ～ 0x8B4 レジスタ初期化ペア: <address>:<value>:

(2048 バイト)アドレスが 0xFFFFFFFF に設定されている場合、そのレジスタはスキップされ、値は無視されます。未使用のレジスタフィールドはすべて、アドレス = 0xFFFFFFFF および値=0x0 に設定する必要があります。

Zynq UltraScale+ MPSoC の PUF ヘルパーデータPUF はヘルパーデータを使用して、デバイスの有効期間中、保証された動作温度および電圧範囲において元の KEK値を再度作成できます。ヘルパーデータは、<syndrome_value>、<aux_value>、および <chash_value> で構成されます。ヘルパーデータは、eFUSE またはブートイメージのいずれかに格納できます。詳細は、puf_fileを参照してください。このリンクから『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) の「PUF ヘルパーデータ」もあわせて参照してください。表 12: Zynq UltraScale+ MPSoC の PUF ヘルパーデータ

アドレスオフセットパラメーター説明0x8B8 ～ 0xEC0 PUF ヘルパーデータ (1544 バイト)

ブートヘッダーオフセット 0x44 (ビット 7:6) == 0x3 の場合にのみ有効です。PUF HD が挿入されていない場合、ブートヘッダーのサイズは 2048 バイトです。PUF ヘッダーデータが挿入されている場合、ブートヘッダーのサイズは 3584 バイトです。PUF HD サイズ = 合計サイズ =1536 バイトの PUFHD + 4 バイトの CHASH + 2 バイトのAUX + 1 バイトアライメント = 1544 バイト。

Zynq UltraScale+ MPSoC のイメージヘッダーテーブルBootgen は、ELF ファイル、ビットストリーム、データファイルなどからデータを抽出してブートイメージを作成します。データが抽出されるこれらのファイルは、イメージと呼ばれます。各イメージには、1 つまたは複数のパーティションを含めることができます。イメージヘッダーテーブルは、これらすべてのイメージに共通する情報と、イメージの数、ブートイメージに含まれるパーティション、およびほかのヘッダーテーブルへのポインターといった情報を含む構造です。表 13: Zynq UltraScale+ MPSoC デバイスのイメージヘッダーテーブル

アドレスオフセットパラメーター説明0x00 バージョン

0x010100000x01020000 - 0x10 フィールドが追加されます。

0x04 イメージヘッダー数イメージヘッダーの数を指定します。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;xPUFHelperData






表 13: Zynq UltraScale+ MPSoC デバイスのイメージヘッダーテーブル (続き)

アドレスオフセットパラメーター説明0x08 第一パーティションヘッダーオフセット第一パーティションヘッダーを指すポインター (ワードオフセット)。0x0C 第一イメージヘッダーオフセットヘッダー第一イメージヘッダーを指すポインター (ワードオフセット)。0x10 ヘッダー認証証明ヘッダー認証照明を指すポインター (ワードオフセット)。0x14 FSBL のブートデバイスオプションは次のとおりです。

0 - 同じブートデバイス1 – QSPI-322 – QSPI-243 – NAND4 – SD04 – SD15 – SDLS6 – MMC7 – USB8 – ETHERNET9 - PCIE10 – SATA

0x18- 0x38 パディング予約 (0x0)

0x3C チェックサムイメージヘッダーの以前のワードの合計値。

Zynq UltraScale+ MPSoC のイメージヘッダーイメージヘッダーについてイメージヘッダーは、ELF ファイル、ビットストリーム、データファイルなど、各イメージに関連する情報を含む構造の配列です。1 つのイメージに複数のパーティションを含めることができます。たとえば、ELF には複数のロード可能なセクションを含めることができ、それぞれがブートイメージ内にパーティションを形成します。テーブルには、イメージに関連するパーティション数の情報も含まれます。次の表に、Zynq® UltraScale+™ MPSoC のアドレスオフセット、パラメーター、および説明を示します。表 14: Zynq UltraScale+ MPSoC デバイスのイメージヘッダー

アドレスオフセットパラメーター説明0x00 次のイメージヘッダーオフセット次のイメージヘッダーにリンクします。最後のイメージヘッダーの場合は 0 となります (ワードオフセット)。0x04 対応するパーティションヘッダー最初に関連付けられたパーティションヘッダーへのリンク (ワードオフセット)。0x08 予約常に 0。0x0C パーティション数実際のパーティション数の値。

0x10 - N イメージ名ビッグエンディアン順に圧縮されます。文字列を再構築するため、一度に 4 バイトを解凍し、順序を逆にして連結されます。たとえば、文字列 FSBL10.ELF は 0x10:‘L’,’B’,’S’,’F’, 0x14: ’E’,’.’,’0’,’1’,0x18: ’\0’,’\0’,’F’,’L’ として圧縮されます。圧縮されたイメージ名は 4 の倍数バイトです。





表 14: Zynq UltraScale+ MPSoC デバイスのイメージヘッダー (続き)

アドレスオフセットパラメーター説明不定ストリングターミネーター (終端名)

0x00000

不定パディングデフォルトで、64 バイト境界まで 0xFFFFFFF でパディングされます。

Zynq UltraScale+ MPSoC のパーティションヘッダーパーティションヘッダーについてパーティションヘッダーは、各パーティションに関連する情報を含む構造の配列です。各パーティションヘッダーテーブルは、ブートローダーによって解析されます。このテーブルには、パーティションサイズ、フラッシュ内のアドレス、RAM 内のロードアドレス、暗号化/署名などの情報が含まれます。FSBL を含め、各パーティションにこのような構造が 1 つあります。テーブル内の最後の構造は、すべて NULL 値となります (チェックサムを除く)。次の表に、Zynq® UltraScale+™ MPSoC のオフセット、名前、および説明を示しています。表 15: Zynq UltraScale+ MPSoC デバイスのパーティションヘッダー

オフセット名前説明0x0 暗号化されたパーティションデータワード長暗号化されたパーティションデータの長さ。

0x04 復号化されていないデータワード長暗号化されていないデータの長さ。

0x08 合計パーティションワード長 (認証証明を含む)。認証証明を参照。暗号化、パディング、拡張、認証をすべて合計した長さ。

0x0C 次のパーティションヘッダーオフセット次のパーティションヘッダーの位置 (ワードオフセット)。

0x10 デスティネーション実行アドレスロード後のこのパーティションの実行可能アドレス。0x14 デスティネーション実行アドレス

HIロード後のこのパーティションの実行可能アドレス。

0x18 デスティネーションロードアドレス LOこのパーティションがロードされる RAM アドレス。

0x1C デスティネーションロードアドレス HIこのパーティションがロードされる RAM アドレス。

0x20 実パーティションワードオフセットブートイメージの開始に対するパーティションデータの位置 (ワードオフセット)。0x24 属性ブートイメージの開始に対するパーティションデータの位置 (ワードオフセット)。Zynq UltraScale+ MPSoC のパーティション属性ビットを参照してください。0x28 セクション数シングルパーティション内のセクション数。0x2C チェックサムワードオフセットブートイメージ内の認証証明の位置 (ワードオフセット)。0x30 イメージヘッダーのワードオフセットブートイメージ内の認証証明の位置 (ワードオフセット)。

0x34 パーティション番号/ID パーティション ID。0x3C ヘッダーチェックサムパーティションヘッダーの以前のワードの合計値。





Zynq UltraScale+ MPSoC のパーティション属性ビット次の表に、Zynq® UltraScale+™ MPSoC のパーティションヘッダーテーブルのパーティション属性ビットを示します。表 16: Zynq® UltraScale+™ MPSoC デバイスのパーティション属性ビット

ビットオフセットフィールド名説明31:24 データ属性インプリメントされていません。

23 ベクターの位置例外ベクターの位置。0: LOVEC (デフォルト)1: HIVEC

22:20 予約19 早期ハンドオフロード直後のハンドオフ:

0: 早期ハンドオフなし1: 早期ハンドオフが有効

18 エンディアン0: リトルエンディアン1: ビッグエンディアン

17:16 パーティションオーナー0: FSBL1: U-Boot2、3: 予約

15 RSA 認証証明フォーマット0: RSA 認証証明なし1: RSA 認証証明あり

14:12 チェックサムタイプ0: なし1-2: 予約3: SHA34-7: 予約

11:8 デスティネーション CPU0: なし1: A53-02: A53-13: A53-24: A53-35: R5-06: R5-17: R5-ロックステップ8: PMU9-15: 予約

7 暗号化の有無0: 暗号化なし1: 暗号化あり





表 16: Zynq® UltraScale+™ MPSoC デバイスのパーティション属性ビット (続き)

ビットオフセットフィールド名説明6:4 デスティネーションデバイス

0: なし1: PS2: PL3-15: 予約

3 A5X 実行ステート0: AARCH64 (デフォルト)1: AARCH32

2:1 例外レベル0: EL01: EL12: EL23: EL3

0 TrustZone0: 非セキュア1: セキュア

Zynq UltraScale+ MPSoC の認証証明認証証明は、パーティションの認証に関連するすべての情報を含む構造です。この構造には、公開キーと、bootROM/FSBL による検証が必要な署名が含まれます。各認証証明には認証ヘッダーがあります。このヘッダーは、キーサイズ、署名に使用するアルゴリズムなどの情報を提供します。認証証明は、認証が有効になっている実際のパーティションに追加されます。認証が有効になっているすべてのパーティションに対して、ヘッダーテーブルも認証する必要があります。ヘッダーテーブル認証証明は、ヘッダーテーブルのコンテンツの最後に追加されます。Zynq® UltraScale+™ MPSoC は RSA-4096 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは4096 ビットとなります。次の表に、Zynq UltraScale+ MPSoC デバイスの認証証明のフォーマットを示します。表 17: Zynq UltraScale+ MPSoC デバイスの認証証明

認証証明0x00 認証ヘッダー = 0x0101000。Zynq UltraScale+ MPSoC の認証証明ヘッダーを参照してください。0x04 SPK ID

0x08 UDF (56 バイト)

0x40 PPK Mod (512)

0x240 Mod Ext (512)


0x444 Pad (60 バイト)

0x480 SPK Mod (512 バイト)



0x884 Pad (60 バイト)

0x8C0 SPK 署名 = RSA-4096 (PSK、パディング || SHA-384 (SPK + 認証ヘッダー + SPK-ID)





表 17: Zynq UltraScale+ MPSoC デバイスの認証証明 (続き)

認証証明0xAC0 ブートヘッダー署名 = RSA-4096 (SSK、パディング || SHA-384 (ブートヘッダー)

0xCC0 パーティション署名 = RSA-4096 (SSK、パディング || SHA-384 (パーティション || パディング || 認証ヘッダー || UDF || PPK || SPK || SPK 署名))

0xCC0 FSBL 署名 = RSA-4096 (SSK、パディング || SHA-384 (PMUFW || FSBL || パディング|| 認証ヘッダー || UDF || PPK || SPK || SPK 署名)

Zynq UltraScale+ MPSoC の認証証明ヘッダー次の表に、Zynq® UltraScale+™ MPSoC デバイスの認証証明ビットフィールドを示します。

ビットフィールドフィールド名説明31:20 予約 0

19:18 SPK/ユーザー eFUSE 選択01: SPK eFuse10: ユーザー eFUSE

17:16 PPK キー選択0: PPK01: PPK1

15:14 認証証明フォーマット 00: PKCS #1 v1.5

13:12 認証証明バージョン 00: 現在の AC

11 PPK キータイプ 0: ハッシュキー10:9 PPK キーソース 0: eFUSE

8 SPK イネーブル 1: SPK イネーブル7:4 公開キー強度

0: 2048b1: 40962-3: 予約

3:2 ハッシュアルゴリズム1: SHA3/3842-3: 予約

1:0 公開キーアルゴリズム0: 予約1: RSA2: ECC3: 予約

Zynq UltraScale+ MPSoC のブートイメージブロック図次の図は、Zynq® UltraScale+™ MPSoC ブートイメージに含まれるコンポーネントを示しています。





図 7: Zynq UltraScale+ MPSoC デバイスのブートイメージブロック図

Boot Header 0x000-0xEC0

Image Header Table

Image Headers (IH1-Ihn)

Partition Header 1

Partition Header n

Header AC

BootLoader(FSBL and PMUFW (opt))

BootLoader AC

Partition 1

Partition 1 AC

Partition(n)

Partition(n) AC

BootLoader AC

Partition 1 AC

Partition n AC

AC Header

SPK IDHeader

SPKHeader

SPK Signature

BH Signature

Partition Signature

Header AC

User Defined Field

PPK

AC Header

SPK IDBootLoader

SPKBootLoader

SPK Signature

BH Signature

Partition Signature

User Defined Field

PPK

AC Header

SPK IDPartition1

SPKPartition1

SPK Signature

BH Signature

Partition Signature

User Defined Field

PPK

AC Header

SPK IDPartition(n)

SPKPartition(n)

SPK Signature

BH Signature

Partition Signature

User Defined Field

PPK

X#####-122118X18916-081518





第 3 章

ブートイメージの作成ブートイメージフォーマット (BIF)ザイリンクスのブートイメージレイアウトには、ファイル、ファイルの種類、およびサポートするヘッダーが複数あり、これらのファイルはブートローダーによって解析されます。Bootgen は、ブートイメージを生成するための属性を定義し、ファイルで渡された値に基づいて解釈してブートイメージを生成します。使用可能なコマンドと属性は複数あるため、Bootgen はそれらの入力を含むブートイメージフォーマット (BIF) を定義します。BIF は次のもので構成されています。• セキュア/非セキュアブートイメージを作成するためのコンフィギュレーション属性• FSBL イメージ (1 つ)

• 1 つまたは複数のパーティションイメージBootgen は、プロパティおよび属性に加えて、複数のコマンドを使用してビヘイビアーを定義し、ブートイメージを作成します。たとえば、認定されている FPGA デバイス、Zynq®-7000 SoC デバイス、または Zynq® UltraScale+™MPSoC デバイスのブートイメージを作成するには、適切な arch コマンドオプションを Bootgen に与える必要があります。次の付録で、Bootgen ビヘイビアーを指示する際に使用可能なオプションをリストして説明しています。• 付録 B: BIF 属性の参照• 付録 C: コマンドリファレンスBIF は、ハードウェア要件とソフトウェア要件の両方に対応します。ブートイメージヘッダーは、シングルパーティション (通常は FSBL (第 1 段階ブートローダー)) をロードする bootROM ローダーで必要です。その他のブートイメージは、FSBL によってロードされて処理されます。Bootgen は一連のパーティションを組み合わせてブートイメージを生成します。次のパーティションが考えられます。• FSBL (第 1 段階ブートローダー)

• U-Boot といった SSBL (第 2 段階ブートローダー)

• ビットストリーム• Linux

• プロセッサ上で実行するソフトウェアアプリケーション• データブロブ

第 3 章: ブートイメージの作成




BIF 構文およびサポートされるファイルの種類BIF ファイルは、ブートイメージの各コンポーネントをブート順に指定し、オプションで各イメージコンポーネントに属性を適用できるようにします。イメージコンポーネントがメモリ内で連続していない場合、コンポーネントは複数のパーティションにマップできます。BIF ファイルの構文は次の形式となります。<image_name>: { // common attributes [attribute1] <argument1> // partition attributes [attribute2, attribute3=<argument> <elf> [attribute2, attribute3=<argument>, attibute4=<argument] <bit> [attribute3] <elf> <bin> }

• <image_name> と {...} (グループ化) を使用し、ROM 内のパーティションに分類するファイルをまとめます。• {...} には 1 つまたは複数のデータファイルがリストされます。• サポートされるファイルの種類は、ELF、BIT、RBT、INT、または BIN ファイルです。• 各パーティションのデータファイルは、ファイル名の前に構文 [attribute, attribute=<argument>] を使用することで、オプションで属性を持つことができます。

• 属性によって、データファイルに何らかの特性が適用されます。• 複数の属性がある場合は、カンマ (,) で区切って並べることができます。その場合の順序は重要ではありません。属性は、1 つのキーワードまたはクォーテーションで囲んだ複数のキーワードとなります。

• 現在のディレクトリにファイルがない場合は、ファイル名を含むファイルパスを追加できます。ファイルのリスト方法は自由形式で、1 行にすべてをリスト (スペースで区切る、最低 1 スペースは必要) しても、1 つずつと改行してもかまいません。

• スペースは無視されるため、読みやすいように追加しても問題ありません。• C 形式のブロックコメント /*...*/、または C++ 形式の行コメント // を使用できます。次に、読みやすいように空白と改行を追加した BIF の例を示します。<image_name>: { /* common attributes */ [attribute1] <argument1> /* bootloader */ [attribute2, attribute3, attribute4=<argument> ] <elf> /* pl bitstream */ [ attribute2, attribute3, attribute4=<argument>, attibute=<argument> ] <bit>





/* another elf partition */ [ attribute3 ] <elf> /* bin partition */ <bin> }

Bootgen でサポートされるファイル次の表に、Bootgen でサポートされるファイルを示します。表 18: Bootgen でサポートされるファイル

拡張子名前説明.bin バイナリ未処理のバイナリファイル.bit/.rbt ビットストリーム BIT ファイルヘッダーを除く.dtb バイナリ未処理のバイナリファイルimage.gz バイナリ未処理のバイナリファイル.elf 実行可能なリンクファイル (ELF) シンボルとヘッダーを除く.int レジスタ初期化ファイル.nky AES キー.pk1/.pub/.pem RSA キー.sig 署名ファイル Bootgen または HSM によって生成される署名ファイル

属性および説明次の表に、Bootgen の属性を示します。各属性は、一番左の列にあるリンクから詳細を参照できます。その右側の列には簡単な説明を記載しています。アーキテクチャ名は、属性を使用するザイリンクスデバイスを示します。• zynq: Zynq-7000 SoC デバイス• zynqmp: Zynq® UltraScale+™ MPSoC デバイス• fpga: すべての 7 シリーズ以降のデバイス表 19: Bootgen の属性と説明

オプション/属性説明属性を使用するデバイスaeskeyfile <aes_key_filepath> AES キーファイルへのパスです。キーファイルには、パーティションの暗号化に使用される AES キーが含まれます。ファイルの内容は eFUSE または

BBRAM に書き込む必要があります。キーファイルが指定されたパスに存在しない場合、Bootgen が暗号化に使用される新しいキーを生成します。たとえば BIF ファイルのビットストリームに暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

すべて





表 19: Bootgen の属性と説明 (続き)

オプション/属性説明属性を使用するデバイスalignment <byte> バイトアライメントを設定します。パーティションは、この値の倍数値に揃えられるまでパディングされます。この属性はオフセットと共に使用することはできません。

zynq、zynqmp

checksum <args> パーティションのチェックサムが必要であることを示します。チェックサムアルゴリズムは次のとおりです。None

md5

zynq、zynqmp

auth_params <options> 認証の追加オプションは次のとおりです。ppk_select: 0 = 2 つの PPK のうち 1 つをサポート、1 = 2 つの PPK のうち 1 つをサポート。spk_id: SPK を識別するための 32 ビット ID。spk_select: SPK とユーザー eFUSE を識別。デフォルトは spk-efuse。header_auth: パーティションが認証されていない場合のヘッダーを認証。

zynqmp

authentication <option> 認証されるパーティションを指定します。zynq の認証は、RSA-2048 を使用して実行されます。zynqmp の認証は、RSA-4096 を使用して実行されます。引数は次のとおりです。none: パーティションは暗号化されない。rsa: パーティションは RSA アルゴリズムを使用して暗号化される。

すべて

bh_keyfile <filename> ブートヘッダーに格納される 256 ビットの難読化キーまたはブラックキー。これは、[keysrc_encryption]=bh_gry_key または[keysrc_encryption]=bh_blk_key の場合にのみ有効です。

zynqmp

bh_key_iv <filename> 難読化キーまたはブラックキーを復号化する際に使用する初期化ベクター。 zynqmp

bhsignature <filename> ブートヘッダーの署名を認証証明にインポートします。これは、秘密キーPSK を共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。ファイルフォーマットは bootheader.sha384.sigです。

zynqmp

blocks <block sizes> 暗号化におけるキーローリング機能のブロックサイズを指定します。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各ブロックのキーは直前のモジュール内で暗号化 (ラップ) されます。

zynqmp

boot_device <options> セカンダリブートデバイスを指定します。パーティションが存在するデバイスを示します。オプションは次のとおりです。qspi32qspi24nandsd0sd1sd-lsmmcusbethernetpciesata

zynqmp

bootimage <filename.bin> リストされた入力ファイルが Bootgen によって作成されたブートイメージであることを示します。 zynq、zynqmp






オプション/属性説明属性を使用するデバイスbootloader <partition> パーティションがブートローダー (FSBL) であることを指定します。この属性は、ほかのパーティションの BIF 属性と共に指定されます。 zynq、zynqmp

bootvector <vector_values> XIP (eXecute In Place) のベクターテーブルを指定します。 zynqmp

checksum <arg> パーティションのチェックサムが必要であることを指定します。このオプションを認証や暗号化などのよりセキュアな機能と共に使用することはできません。チェックサムアルゴリズムは次のとおりです。md5: Zynq®-7000 SoC デバイスの場合。Zynq® UltraScale+™ MPSoC の場合、オプションは none: チェックサムなしです。sha3: sha3 チェックサム。zynq デバイスはブートローダーのチェックサムをサポートしていません。zynqmp デバイスはブートローダーのチェックサムをサポートしています。

zynq、zynqmp

destination_cpu <device_core> パーティションを実行する必要があるコアを指定します。このオプションを認証や暗号化などのよりセキュアな機能と共に使用することはできません。a53-0a53-1a53-2a53-3r5-0r5-1r5-locksteppmu

zynqmp

destination_device<device_type>

パーティションのターゲットを PS または PL のいずれかに指定します。オプションは次のとおりです。ps: パーティションのターゲットは PS (デフォルト)。pl: パーティションのターゲットは PL (ビットストリームの場合)。

zynqmp

early_handoff このフラグは、パーティションのロード直後に重要なアプリケーションへのハンドオフが確実に実行されるようにします。このオプションを使用しない場合は、最初にすべてのパーティションが順にロードされ、続いてハンドオフが順に実行されます。

zynqmp

encryption <partition_option> 暗号化するパーティションを指定します。暗号化アルゴリズムは次のとおりです。zynq は AES-CBC を使用し、zynqmp は AES-GCM を使用します。パーティションのオプションは次のとおりです。

none: パーティションは暗号化されない。aes: パーティションは AES アルゴリズムを使用して暗号化される。

すべて

exception_level コアに設定する例外レベルを指定します。オプションは次のとおりです。

el-0el-1el-2el-3

zynqmp

familykey ファミリキーを指定します。 zynqmp






オプション/属性説明属性を使用するデバイスfsbl_config ブートイメージのコンフィギュレーションに使用するサブ属性を指定します。サブ属性は次のとおりです。

bh_auth_enable: PPK ハッシュと SPK ID の検証を除き、ブートイメージの RSA 認証が完了しました。auth_only: ブートイメージは RSA 署名のみです。FSBL の復号化は実行しません。opt_key: block-0 の復号化に操作キーを使用します。操作キーはセキュアヘッダーにあります。pufhd_bh: PUF ヘルパーデータはブートヘッダーに格納されます(デフォルトは efuse)。PUF ヘルパーデータファイルは、[puf_file] オプションを使用してBootgen に渡されます。puf4kmode: PUF は 4k ビットコンフィギュレーションでの使用に合わせて調整されています(デフォルトは 12k ビット)。shutter = <value> 32 ビットの PUF_SHUT レジスタの値で、シャッターオフセット時間およびシャッターオープン時間を PUF に設定します。

zynqmp

headersignature<signature_file> ヘッダーの署名を認証証明にインポートします。これは、秘密キーを共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。zynq、zynqmp

hivec 例外ベクターテーブルの場所を hivec (Hi-Vector) として指定します。デフォルトは lovec (Low-Vector) です。これは、A53 (32 ビット) および R5 コアにのみ適用されます。hivec: 0xFFFF0000 の例外ベクターテーブル。lovec: 0x00000000 の例外ベクターテーブル。

zynqmp

init<filename> ブートローダーの最後にあるレジスタ初期化ブロックであり、init (.int) ファイルの仕様を解析して構築されます。最大 256 のアドレスと値の初期化ペアが許可されます。init ファイルには特定のフォーマットがあります。zynq、zynqmp

keysrc_encryption 暗号化に使用するキーソースを指定します。キーは次のとおりです。efuse_gry_key: eFUSE に格納されているグレー (難読化) キー。グレー/難読化キーを参照してください。bh_gry_key: ブートヘッダーに格納されているグレー (難読化) キー。bh_blk_key: ブートヘッダーに格納されているブラックキー。ブラックキー/PUF キーを参照してください。efuse_blk_key: eFUSE に格納されているブラックキー。kup_key: ユーザーキー。efuse_red_key: eFUSE に格納されているレッドキー。キーの差し替えを参照してください。bbram_red_key: BBRAM に格納されているレッドキー。

zynq、zynqmp

load <partition_address> メモリ内のパーティションのロードアドレスを設定します。 zynq、zynqmp

offset <offset_address> ブートイメージ内のパーティションの絶対オフセットを設定します。 zynq、zynqmp

partition_owner<option><partition>

パーティションをロードするパーティションオーナーを設定します。オプションは次のとおりです。fsbl: パーティションは FSBL によってロードされます。uboot: パーティションは U-Boot によってロードされます。

zynq、zynqmp

pid <ID> パーティション ID を指定します。PID は 32 ビット値 (0～0xFFFFFFFF) に設定できます。 zynqmp






オプション/属性説明属性を使用するデバイスpmufw_image <image_name> FSBL をロードする前に bootROM によってロードされる PMU ファームウェアイメージです。 zynqmp

ppkfile <key filename> プライマリ公開キー (PPK)。ブートイメージ内のパーティションの認証に使用します。詳細は、認証の使用を参照してください。

zynq、zynqmp

presign <sig_filename> パーティション署名 (.sig) ファイル。すべてpskfile <key filename> プライマリ秘密キー (PSK)。ブートイメージ内のパーティションの認証に使用します。

詳細は、認証の使用を参照してください。zynq、zynqmp

puf_file <filename> PUF ヘルパーデータファイル。PUF は、暗号化キーソースとしてブラックキーと共に使用されます。PUF ヘルパーデータは 1544 バイトです。1536バイトの PUF HD + 4 バイトの HASH + 3 バイトの AUX + 1 バイトアライメント。

zynqmp

reserve パーティションのメモリサイズを維持します。このサイズになるまでパーティションにパディングが追加されます。 zynq、zynqmp

spkkfile<filename> ブートイメージ内のパーティションの認証に使用するキーです。詳細は、認証の使用を参照してください。SPK - セカンダリ公開キー。すべて

split モードに基づいてイメージを分割します。split オプションは次のとおりです。slaveboot: zynqmp でのみサポートされています。次のように分割します。ブートヘッダー + ブートローダーイメージヘッダーおよびパーティションヘッダー残りのパーティションnormal: zynq および zynqmp の両方でサポートされています。次のように分割します。ブートヘッダー + イメージヘッダー + パーティションヘッダー + ブートローダーパーティション 1パーティション 2、以下同様

分割 (split) モードのほかに、出力フォーマットも bin または mcs に設定できます。注記: オプションの split の normal モードは、コマンドラインオプションのsplit と同じです。このコマンドラインオプションは推奨されていません。

zynq、zynqmp

spksignature <SPK_ID> ユーザー eFUSE の SPK ID を指定します。 zynqmp

spksignature <signature_file> SPK の署名を認証証明にインポートします。認証の使用を参照してください。これは、秘密キー (PSK) を共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。zynq zynqmp

sskfile <key filename> セカンダリ秘密キー (SSK) は、ブートイメージ内のパーティションを認証するために使用されます。プライマリキーはセカンダリキーを認証し、セカンダリキーはパーティションを認証します。すべて

startup ロード後のパーティションのエントリアドレスを設定します。この識別子は、実行しないパーティションでは無視されます。 zynq、zynqmp

TrustZone <option> TrustZone オプションは次のとおりです。securenonsecure

zynqmp






オプション/属性説明属性を使用するデバイスudf_bh <data_file> ブートヘッダーのユーザー定義フィールドにコピーされるデータのファイルをインポートします。UDF は、16 進数文字列フォーマットのテキストファイルで提供されます。UDF の総バイト数は、zynq = 76 バイトで、zynqmp

= 40 バイトです。

zynq、zynqmp

udf_data<data_file> 最大 56 バイトのデータを含むファイルを認証証明のユーザー定義フィールド (UDF) にインポートします。 zynq、zynqmp

xip_mode FSBL が QSPI フラッシュから直接実行されるよう XIP (eXecute-In-Place)を示します。 zynq、zynqmp





第 4 章

Bootgen インターフェイスの使用Bootgen には GUI とコマンドラインの 2 つのオプションがあります。GUI オプションは、ザイリンクスソフトウェア開発キット (SDK) でウィザードとして利用できます。GUI の機能は、ブートイメージを作成する際の最も標準的な機能に限定されています。一方、Bootgen コマンドラインは、システムに対する複雑なブートイメージの作成を可能にする完全なコマンドセットです。

Bootgen GUI のオプションCreate Boot Image ウィザードでは、ブートイメージ生成に使用できる Bootgen オプションに制限があります。GUI を使用してブートイメージを作成するには、次の手順に従います。1. Project Navigator または [C/C++ Projects] ビューでアプリケーションプロジェクトを選択し、[Create Boot

Image] を右クリックします。別の方法として、[Xilinx Tools] → [Create boot image] をクリックします。図 8: [Create Boot Image] オプション

次の図のように、[Create Boot Image] ダイアログボックスが開き、選択した C プロジェクトのコンテキストからあらかじめ選択されているデフォルト値が取り込まれて表示されます。

第 4 章: Bootgen インターフェイスの使用




図 9: [Create Boot Image] ダイアログボックス

次に注意事項を示します。• アプリケーションに対して [Create Boot Image] を初めて実行する場合、FSBL ELF ファイルへのパス、選択したハードウェアのビットストリーム (ハードウェアプロジェクトにある場合)、および選択したアプリケーションの ELF ファイルがダイアログボックスにあらかじめ入力されます。

• 以前にアプリケーションのブートイメージが実行済で、BIF ファイルが存在する場合、ダイアログボックスには /bif フォルダーの値があらかじめ入力されます。

• Zynq®-7000 SoC または Zynq® UltraScale+™ MPSoC アーキテクチャ用のブートイメージの作成が可能になりました。

重要: ブートイメージ用に入力するデータは、オフセットが 0x4c の最大 76 バイト (Zynq-7000 SoC の場合)、およびオフセットが 0x70 の最大 40 バイト (Zynq UltraScale+ MPSoC の場合) である必要があります。これは Zynq アーキテクチャに基づく厳格な制限です。2. [Create Boot Image] ダイアログボックスに次の情報を入力します。

a. [Architecture] ドロップダウンから、必要なアーキテクチャを選択します。b. [Create new BIF file] または [Import from existing BIF file] のいずれかをオンにします。c. [Basic] タブの [Output BIF file path] で、出力 BIF ファイルのパスを指定します。d. 該当する場合は、[UDF data] を指定します。このオプションの詳細は、udf_data を参照してください。e. [Output path] で出力パスを指定します。





3. [Boot image partitions] で、[Add] をクリックしてその他のパーティションイメージを追加します。4. 必要に応じて、ブートイメージ内のパーティションのオフセット値、アラインメント値、および割り当て値を作

成します。出力ファイルのパスは、選択したアプリケーションプロジェクト下の /bif フォルダーにデフォルトで設定されます。

5. [Security] タブで、セキュアイメージを作成するための属性を指定できます。このセキュリティは、必要に応じて個々のパーティションに適用できます。a. パーティションの認証を有効にするには、[Use Authentication] をオンにし、[PPK]、[SPK]、[PSK]、および

[SSK] の値を指定します。詳細は、認証を参照してください。b. パーティションの暗号化を有効にするには、[Encryption] タブを選択し、[Use Encryption] をオンにします。詳細は、暗号化の使用を参照してください。

6. ブートローダーから開始して、BIF ファイルのブートイメージを 1 つずつ作成またはインポートします。パーティションリストには、BIF ファイル内のパーティションの概要が表示されます。ファイルパス、暗号化設定、および認証設定が表示されます。この領域を使用して、パーティションの追加、削除、変更、並べ替えを実行します。また、暗号化、認証、チェックサムを有効にするための値を設定し、[Load]、[Alignment]、[Offset] など、一部のその他のパーティションに関連する値を指定することもできます。

コマンドラインで Bootgen を使用コマンドラインで Bootgen オプションを指定すると、GUI で提供されるオプションよりも多くのオプションを利用できます。ザイリンクス SDK の標準インストールで、XSCT (ザイリンクスソフトウェアコマンドラインツール) が対話型のコマンドライン環境として入手可能で、これをスクリプト作成に使用することもできます。XSCT では、Bootgen コマンドを実行できます。XSCT は別のツールである Bootgen 実行ファイルにアクセスします。このBootgen 実行ファイルは、Bootgen のインストールで説明したとおり、スタンドアロンでインストールできます。これは XSCT から呼び出されたツールと同じものなので、ここで開発されたスクリプトまたは XSCT で作成されたスクリプトはいずれももう一方のツールで動作します。『ザイリンクスソフトウェアコマンドラインツール (XSCT) リファレンスガイド』 (UG1208) に、このツールの詳細を説明しています。XSCT で Bootgen コマンドを使用する例は、「XSCT ユースケース」の章を参照してください。

コマンドおよび説明次の表に、Bootgen コマンドオプションを示します。各オプションは、一番左の列にあるリンクから詳細な説明を参照できます。その右側の列には簡単な説明を記載しています。アーキテクチャ名は、コマンドを使用するザイリンクスデバイスを示します。• zynq: Zynq®-7000 SoC デバイス• zynqmp: Zynq® UltraScale+™ MPSoC デバイス• fpga: すべての 7 シリーズ以降のデバイス



https://japan.xilinx.com/cgi-bin/docs/ctdoc?cid=;d=ug1208-xsct-reference-guide.pdf



表 20: Bootgen コマンドおよび説明コマンド説明およびオプションコマンドを使用するデバイス

arch <type> ザイリンクスデバイスアーキテクチャ: オプションは次のとおりです。zynq (デフォルト)zynqmpfpga

すべて

bif_help BIF ヘルプサマリをプリントアウトします。すべてdual_qspi_mode<configuration> Dual QSPI コンフィギュレーションの場合は 2 つの出力ファイルを生成します。

parallelstacked <size>

zynq、zynqmp

efuseppkbits <PPK_filename> eFUSE 用の PPK ハッシュを生成します。 zynq、zynqmp

encrypt <options> デバイス内での AES キーの格納場所。オプションは次のとおりです。bbram (デフォルト)eFuse

zynq、fpga

encryption_dump 暗号ログファイル aes_log.txt を生成します。 zynqmp

fill <hex_byte> パディング用に使用するバイトを指定します。 zynq、zynqmp

generate_hashes PKCS#1v1.5 フォーマットのパディング付き SHA2/SHA3 ハッシュファイルを出力します。 zynq、zynqmp

generate_keys <key_type> 認証キーを生成します。オプションは次のとおりです。pemrsaobfuscatedkey

zynq、zynqmp

h、help ヘルプサマリをプリントアウトします。すべてimage <filename(.bif)> ブートイメージフォーマット (BIF) ファイル名を提供します。すべて

log<level_type> 現在の作業ディレクトリに次のメッセージタイプのログファイルを生成します。errorwarning (デフォルト)infodebugtrace

すべて

nonbooting 中間のブートイメージを作成します。 zynq、zynqmp

o <filename> 出力ファイルを指定します。ファイルフォーマットは、ファイル名の拡張子によって決まります。有効な拡張子は次のとおりです。.bin (デフォルト).mcs

すべて

p <partname> 暗号化キーの生成に使用するパーツ名を指定します。すべて





表 20: Bootgen コマンドおよび説明 (続き)

コマンド説明およびオプションコマンドを使用するデバイスpadimageheader<option> イメージヘッダーをパディングして、続くパーティションを強制的に揃えます。オプションは次のとおりです。

01 (デフォルト)

zynq、zynqmp

process_bitstream<option> ビットストリームを .bin と .mcs ファイルのいずれかで処理および出力するかを指定します。たとえば BIF ファイルのビットストリームに暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

zynq、zynqmp

split <options> ブートイメージをパーティションに分割し、ファイルを .bin または .mcs として出力します。 zynq、zynqmp

spksignature <filename> SPK 署名ファイルを生成します。 zynq、zynqmp

w <option> 出力ファイルを上書きするかどうかを指定します。on (デフォルト)off

注記: オプションのない -w は、–w on として解釈されます。

すべて

zynqmpes1 ES1 (1.0) 用のブートイメージを生成します。デフォルトのパディング方式は ES2 (2.0) です。 zynqmp





第 5 章

ブート時のセキュリティザイリンクスでは、最新の認証方法を使用して、すべてのデバイスのセキュアなブートをサポートし、ザイリンクスデバイス上で認証されていないコードまたは変更されたコードが実行されないようにしています。ザイリンクスでは、認証されたプログラムのみがイメージにアクセスするよう、さまざまな暗号化技術をサポートしています。デバイスごとのハードウェアセキュリティ機能の詳細は、次の各セクションを参照してください。

Zynq-7000 SoC デバイスのセキュアモードおよび非セキュアモードセキュリティ上の理由により、PS の全マスターモジュールの中で CPU 0 が最初にリセット状態を終了します。CPU1 は WFE ステートを維持します。bootROM が実行されている間は、安全性を確保するためにリセットの種類に関係なく JTAG は常に無効となります。bootROM の実行が完了した後、ブートモードが非セキュアな場合は JTAG が有効になります。bootROM コードには、FSBL/ユーザーコードをロードする役目もあります。bootROM がステージ 1 へ制御をリリースすると、ユーザーソフトウェアがシステム全体を完全に制御します。bootROM を再度実行するには、システムリセットのいずれかを実行する以外に方法はありません。FSBL/ユーザーコードのサイズは、暗号化/非暗号化ともに192KB までに制限されています。この制限は、非セキュアの XIP (eXecute-In-Place) オプションを使用する場合は適用されません。PS ブートソースは BOOT_MODE ストラップピンに弱いプルアップまたはプルダウン抵抗を接続して選択します。このピンは、パワーオンリセット (POR) 時に 1 回だけサンプルされます。サンプルした値は slcr.BOOT_MODE レジスタに格納されます。bootROM は暗号化/認証されたイメージ (セキュアブート) と暗号化していないイメージ (非セキュアブート) をサポートしています。また、非セキュアブートイメージのみを対象とした場合、XIP (eXecute-In-Place、xip_mode) オプションを使用してステージ 1 イメージを NOR または Quad-SPI から直接実行できます。XIP (eXecute-In-Place) は、NOR および Quad-SPI ブートモードでのみ利用できます。• セキュアブートの場合、bootROM コードを実行している CPU は、ブートデバイス上のユーザー PS イメージを復号化/認証して OCM に格納した後、このイメージに分岐します。

• 非セキュアブートの場合、bootROM を実行している CPU は、PL 内の AES ユニットなどすべてのセキュアブート機能を無効にした後、OCM メモリまたはフラッシュデバイス (XIP (eXecute-In-Place) を使用した場合) 内のユーザーイメージに分岐します。

これ以降の PS または PL に対するブートステージは開発者であるユーザーの責任で、ユーザー制御下で実行する必要があります。bootROM コードにはユーザーからはアクセスできません。ステージ 1 ブートがセキュアブートの場合、その後のブートステージはセキュアまたは非セキュアのどちらも可能です。ステージ 1 ブートが非セキュアブートの場合、その後のブートステージは非セキュアブートしか実行できません。

Zynq UltraScale+ MPSoC デバイスのセキュリティZynq® UltraScale+™ MPSoC デバイスでは、ハードウェアルートオブトラストのブートメカニズムを使用してセキュアブートが実行されます。これにより、すべてのブートファイルまたはコンフィギュレーションファイルも暗号化されます。このアーキテクチャは、アプリケーションの安全性を最大限に確保するために必要な機密性、完全性、および認証を提供します。




詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版) のこのセクションを参照してください。

暗号化の使用セキュアブートは、デバイス上のイメージの実行が許可される前にこれらを検証するため、フィールドで展開されているほとんどの電子デバイスにとって不可欠な機能となっています。暗号化については、ザイリンクスでは AES(Advanced Encryption Standard) アルゴリズムによる AES 暗号化をサポートしています。AES では、対称型キー暗号 (暗号化と復号化の両方に対応する 1 つのキー定義) が提供されます。暗号化と復号化の両方を逆の順序で完了する場合も、同じステップが実行されます。AES は反復式の対称型ブロック暗号であり、次のように動作します。• 同じ定義されたステップを複数回繰り返して動作する。• 秘密キーの暗号化アルゴリズムを使用する。• 固定バイト数で動作する。

暗号化プロセスBootgen は、BIF ファイルでユーザーが提供する暗号化コマンドおよび属性に基づいてブートイメージパーティションを暗号化できます。AES は対称キー暗号化手法であり、暗号化および復号化に同じキーを使用します。ブートイメージの暗号化に使用するキーは、デバイスがそのブートイメージでブート中、復号化プロセス用にデバイスで使用可能であることが求められます。一般に、キーは eFUSE または BBRAM のいずれかに格納され、キーソースはブートイメージの作成時に BIF 属性を介して選択できます (次の図参照)。

図 10: 暗号化プロセスの図

Key

AES Encryption

eFUSE

BBRAM

Partition Encrypted Partition

OR

X21274-080918

第 5 章: ブート時のセキュリティ




https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurity

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1085-zynq-ultrascale-trm.pdf;a=xSecurity



復号化プロセスSoC デバイスの場合、ブートサイクル中に bootROM および FSBL によってパーティションが復号化されます。bootROM は、フラッシュから FSBL を読み出し、復号化し、ロードし、制御を FSBL に渡します。FSBL の実行が開始されると、残りのパーティションが読み込まれ、復号化され、ロードされます。パーティションの復号化に必要なAES キーは、eFUSE または BBRAM のいずれかから取得できます。暗号化キーのソースを把握するために、ブートイメージ内のブートヘッダーテーブルのキーソースフィールドが読み出されます。暗号化されたパーティションはそれぞれ、AES ハードウェアエンジンを使用して復号化されます。

図 11: 復号化プロセスの図

Key

AES Decryption

eFUSE

BBRAM

Partition Decrypted Partition

OR

X21274-081518

Zynq-7000 デバイスのパーティションの暗号化Zynq®-7000 SoC デバイスは、内蔵型でプログラマブルロジック (PL) ベースの HMAC (Hash-based MessageAuthentication Code)、および Cipher Block Chaining (CBC) モードの Advanced Encryption Standard (AES) モジュールを使用します。

BIF ファイルの例暗号化されたパーティションを持つブートイメージを作成するには、aeskeyfile 属性を使用して BIF で AES キーファイルを指定します。暗号化する BIF ファイルにリストされている各イメージファイルに対して encryption=aes属性を指定します。BIF ファイル (secure.bif) の例を次に示します。image: { [aeskeyfile] secretkey.nky [keysrc_encryption] efuse [bootloader, encryption=aes] fsbl.elf [encryption=aes] uboot.elf }





コマンドラインから、次のコマンドを使用して、暗号化された fsbl.elf および uboot.elf を含むブートイメージを生成します。bootgen -arch zynq -image secure.bif -w -o BOOT.bin

キーの生成Bootgen は AES-CBC キーを生成できます。Bootgen は、BIF で指定された AES キーファイルを使用し、パーティションを暗号化します。キーファイルが空または存在しない場合、Bootgen は BIF ファイルで指定されたファイルにキーを生成します。キーファイルが BIF で指定されておらず、いずれかのパーティションに対して暗号化が要求されている場合、Bootgen は BIF と同じディレクトリに拡張子 .nky の BIF ファイル名を用いたキーファイルを生成します。次に、キーファイルの例を示します。

図 12: キーファイルの例

Zynq MPSoC デバイスのパーティションの暗号化Zynq® UltraScale+™ MPSoC デバイスは、AES-GCM コアを使用します。このコアは 32 ビットワードベースのデータインターフェイスを備えており、256 ビットキーをサポートします。AES-GCM モードは、暗号化と復号化、複数のキーソース、内蔵のメッセージインテグリティチェックをサポートします。

操作キー優れたキー管理の方法の 1 つは、秘密キーの使用を最小限に抑えることです。このためには、Bootgen で有効になっている操作キーオプションを使用します。Bootgen は、暗号化された安全なヘッダーを作成します。このヘッダーには、ユーザー指定の操作キー (opt_key)と、Bootgen が有効のときにコンフィギュレーションファイルの最初のブロックに必要な初期化ベクトル (IV) が含まれます。このため、BBRAM または eFUSE のいずれかに格納された AES キーは 384 ビットのみで使用され、サイドチャネル攻撃にさらされる可能性が大幅に制限されます。opt_key 属性は、操作キーの使用方法を指定するものです。fsbl_config 属性に対する引数である opt_key 値の詳細は、fsbl_configを参照してください。次に、opt_key属性の使用例を示します。image: { [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky ] fsbl.elf [ destination_cpu = a53-3,





encryption = aes, aeskeyfile = aes_p2.nky, ] hello.elf }

操作キーは、次に示すように、AES キー (.nky) ファイルで Key Opt 名を用いて与えられます。図 13: 操作キー

Bootgen は暗号化キーファイルを生成します。前の例に示すように、BIF ファイルで opt_key が有効になっている場合、操作キー opt_key が .nkyファイルで生成されます。操作キーを使用するその他の例は、操作キーを使用して開発環境のデバイスキーを保護するを参照してください。この機能の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)の「セキュリティ」章のキー管理を参照してください。

キーの差し替えAES-GCM は、暗号化されたイメージ全体をより小規模な AES 暗号化ブロック/モジュール単位で表すキー差し替え機能もサポートしています。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。キー差し替えをサポートするブートイメージは、Bootgen を使用して生成できます。BIF の属性 (blocks) を使用して、暗号化用に複数の小さなブロックを作成するためのパターンを指定します。image: { [keysrc_encryption] bbram_red_key [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky, blocks = 1024(2);2048;4096(2);8192(2);4096;2048;1024, ] fsbl.elf [ destination_cpu = a53-3, encryption = aes, aeskeyfile = aes_p2.nky, blocks = 4096(1);1024, ] hello.elf }

注記:







• キーファイル内のキーの数は、暗号化されるブロックの数と常に一致する必要があります。○ キーの数が暗号化されるブロック数より少ない場合、Bootgen はエラーを返します。○ キーの数が暗号化されるブロック数より多い場合、Bootgen は余分なキーを無視します。

• 複数のキー/IV ペアを指定する場合は、no. of blocks + 1 ペアを指定する必要があります。○ 余ったキー/IV ペアは、セキュアヘッダーの暗号化に使用されます。

グレー/難読化キーユーザーキーは、ファミリキーで暗号化されており、デバイスの金属層に埋め込まれています。このファミリキーは、Zynq® UltraScale+™ MPSoC のすべてのデバイスで同じであり、結果、難読化キーとして使用されます。難読化キーは、認証されたブートヘッダーまたは eFUSE のいずれかに配置できます。image: { [keysrc_encryption] efuse_gry_key [bh_key_iv] bhiv.txt [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky fsbl.elf ] [ destination_cpu = r5-0, encryption = aes, aeskeyfile = aes_p2.nky hello.elf [ }

Bootgen は、イメージの作成中に次を実行します。1. ブートヘッダーの BH IV フィールドに bhiv.txt の IV を置きます。2. ブートヘッダーのセキュアヘッダー IV フィールドに aes.nky の IV 0 を置きます。3. aes.nky の Key0 および IV0 を使用して、パーティションを暗号化します。グレー/ファミリキーを使用する別の例については、付録 A: ユースケースおよび例を参照してください。この機能の詳細は、『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)を参照してください。

キーの生成Bootgen には、AES-GCM キーを生成する機能があります。Bootgen は、NIST が認定する Counter Mode KDF を使用し、CMAC を疑似ランダム関数として使用します。ユーザーがキーローリングのためにシードから複数のキーを派生させる場合、Bootgen はシードを入力として受け取ります。シードが指定されている場合、これを使用してキーが生成されます。シードが指定されていない場合、Key0 に基づいてキーが生成されます。空のキーファイルが指定されている場合、Bootgen は時間ベースのランダム化 (KDF ではない) でシードを生成します。これは KDF がほかのキー/IV ペアを生成するための入力となります。注記:







• 1 つの暗号化ファイルが指定され、ほかの暗号化ファイルが生成される場合、Bootgen は最初のパーティションの暗号化ファイルにある Key0/IV0 ペアと同じものを生成されたキーに使用できます。

• 最初のパーティションに暗号化ファイルが生成され、それ以降のパーティションには Key0/IV0 を含むほかの暗号化ファイルが指定されると、Bootgen は終了し、誤った Key0/IV0 ペアが使用されたというエラーを返します。

キーの生成キーファイルのサンプルを次に示します。

図 14: キーファイルの例

難読化キーの生成Bootgen は、ファミリキーと、ユーザー提供の IV を用いてレッドキーを暗号化することで難読化キーを生成できます。ファミリキーは、ザイリンクスセキュリティグループが提供します。詳細は、familykeyを参照してください。難読化キーを生成するために、Bootgen は BIF ファイルから次の入力を取得します。obf_key: { [aeskeyfile] aes.nky [familykey] familyKey.cfg [bh_key_iv] bhiv.txt }

難読化キーを生成する構文は、次のとおりです。bootgen -arch zynqmp -image all.bif -generate_keys obfuscatedkey

ブラックキー/PUF キーブラックキーのストレージソリューションは、PUF から生成された暗号強度の高い KEK (key encryption key) を使用し、ユーザーキーを暗号化します。生成されたブラックキーは、eFUSE に格納するか、認証されたブートヘッダーの一部として格納できます。image: { [puf_file] pufdata.txt [bh_key_iv]black_iv.txt [bh_keyfile]black_key.txt [fsbl_config] puf4kmode, shutter=0x0100005E, pufhd_bh [keysrc_encryption]bh_blk_key } [ bootloader,





destination_cpu = a53-0, encryption = aes, aeskeyfile = aes_p1.nky ] fsbl.elf [ destination_cpu = r5-0, encryption = aes, aeskeyfile = aes_p2.nky ] hello.elf }

ブラックキーを使用するその他の例は、付録 A: ユースケースおよび例を参照してください。

複数の暗号化キーファイル以前のバージョンの Bootgen では、1 つの暗号化キーで複数のパーティションを暗号化してブートイメージを作成できました。この場合、各パーティションで同じキーが繰り返し使用されます。これはセキュリティの脆弱性の要因となるため、推奨されていません。各キーの使用は、フローで一度だけとする必要があります。Bootgen は、パーティションごとに個別の暗号化キーをサポートしています。キーファイルが複数ある場合、各暗号化キーファイルで同じ Key0 (デバイスキー)、IV0、および操作キーが使用されるようにしてください。各暗号化キーファイルでブートイメージが異なると、Bootgen でブートイメージを作成できません。ユーザーは、複数の暗号化キーファイル (イメージ内の各パーティションに 1 つずつ) を指定する必要があります。パーティションは、各パーティションに指定されたキーを使用して暗号化されます。注記: ファイル名に ".1", ".2"...".n" を付けたキーファイルを該当パーティションのキーファイルの同じディレクトリに置くことで、ロード可能なセクションが複数あるために作成された各パーティションに対して一意のキーファイルを使用できます。all: { [keysrc_encryption] bbram_red_key // FSBL (Partition-0) [ bootloader, destination_cpu = a53-0, encryption = aes, aeskeyfile = key_p0.nky, fsbla53.elf [ // application (Partition-1) [ destination_cpu = a53-0, encryption = aes, aeskeyfile = key_p1.nky, hello.elf ] }

• fsbla53.elf パーティションは、key_p0.nky ファイルのキーで暗号化されます。• hello.elf にロード可能なセクションが 3 つあるため 3 つのパーティションが存在するとした場合、

hello.elf.0 パーティションは test2.nky ファイルのキーで暗号化されます。• 続いて hello.elf.1 パーティションが test2.1.nky のキーで暗号化されます。





• hello.elf.2 パーティションは test2.2.nky のキーで暗号化されます。

認証の使用AES 暗号化は対称キーを用いた自己認証アルゴリズムで、暗号化と復号化に同じキーを使用します。したがって、このキーは非公開キーとして保護する必要があり、キーを格納するための領域が内部に必要になります。RSA (RivestShamir Adleman) による認証手段もあります。RSA は非対称アルゴリズムで、署名に使用するキーと検証に使用するキーが異なります。認証には一対のキーが必要です。• 署名には、秘密キーを使用します。• 検証には、公開キーを使用します。この公開キーは保護の必要がないため、セキュアな格納領域は不要です。この認証方式と暗号化を組み合わせることにより、真正性と機密性の両方を確保できます。RSA は、暗号化されているパーティションと暗号化されていないパーティションのいずれにも使用可能です。RSA のメリットは、公開キーを使用することだけではなく、復号化する前に認証を実行できることが挙げられます。RSA 公開キーのハッシュ値は eFUSE に格納する必要があります。ザイリンクス SoC デバイスでは、パーティションデータは AES 復号化エンジンに送信される前に認証されます。この方法では、パーティションデータの真正性を確認してから復号化を実行することになるため、復号化エンジンへの攻撃を防ぐことができます。ザイリンクス SoC では、公開キーと秘密キーの 2 つのペアが使用されます (プライマリおよびセカンダリ)。プライマリ公開/秘密キーは、セカンダリ公開/秘密キーペアを認証します。セカンダリキーは、パーティションを署名/検証します。キーを示す頭文字の最初のアルファベットは、プライマリの場合 P、セカンダリの場合 S となります。キーを示す頭文字の 2 番目のアルファベットは、公開の場合 P、秘密の場合 S となります。キーの種類は次の 4 つです。• PPK = プライマリ公開キー• PSK = プライマリ秘密キー• SPK = セカンダリ公開キー• SSK = セカンダリ秘密キーBootgen は、次の 2 つの方法で認証証明を作成できます。• PSK と SSK を与えます。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。• PPK と SSK、そして SPK 署名を入力として与えます。この方法は、PSK がわからない場合に使用されます。プライマリキーはハッシュ化されて eFUSE 内に格納されます。このハッシュ値は、FSBL によってブートイメージに格納されたプライマリキーのハッシュ値と比較されます。このハッシュは、SDK に付属するスタンドアロンドライバーを使用して PS の eFUSE メモリに書き込むことができます。BIF ファイルの例を次に示します。image: { [pskfile]primarykey.pem [sskfile]secondarykey.pem [bootloader,authentication=rsa] fsbl.elf [authentication=rsa]uboot.elf }





デバイス固有の認証の詳細は、次の資料を参照してください。• Zynq-7000 SoC デバイスの認証証明• Zynq UltraScale+ MPSoC デバイスの認証証明

署名次の図に、パーティションに対する RSA 署名を示します。Bootgen は、セキュアな施設から秘密キーを使用してパーティションに署名を与えます。ここでは、署名プロセスについて次の手順で解説します。1. PPK および SPK は、認証証明 (AC) に格納されます。2. SPK は、PSK で署名されて SPK 署名を取得します。また、AC の一部としても格納されます。3. パーティションは、SSK で署名されてパーティション署名を取得し、AC に格納されます。4. AC は、認証が選択されている各パーティションに追加されます。5. PPK はハッシュ化されて eFUSE 内に格納されます。

図 15: パーティションに対する RSA 署名

Hash

eFUSE

Hash + RSA

Hash + RSA

Prim

ary

Keys PPK

PSK

Seco

ndar

y Ke

ys SPK

SSK

Partition

Authentication Header

PPK

SPK

SPKSignature

PartitionSignature

PartitionAuthentication

Certificate

Partition

AuthenticationCertificate

Partition Headers

Boot Header

Secret Key

Secret Key

X21278-080618

次の表に、認証のオプションを示します。





表 21: 認証キーに対してサポートされているファイルフォーマット

キー名称説明サポートされているファイルフォーマットPPK プライマリ公開キーパーティションを認証するために使用するキーです。

パーティションの認証時に必ず指定する必要があります。

*.txt*.pem*.pub*.pk1

PSK プライマリ秘密キーパーティションを認証するために使用するキーです。パーティションの認証時に必ず指定する必要があります。

*.txt*.pem*.pk1

SPK セカンダリ公開キーこのキーを指定した場合、パーティションの認証に使用されます。 *.txt*.pem*.pub*.pk1

SSK セカンダリ秘密キーこのキーを指定した場合、パーティションの認証に使用されます。 *.txt*.pem*.pk1

検証デバイス内では、公開キーを使用して、bootROM が FSBL を検証し、FSBL または U-Boot のいずれかが続くパーティションを検証します。1. PPK の検証 - この手順では、プライマリキーの認証が確立されます。プライマリキーは、セカンダリキーの認証に使用します。a. ブートイメージの AC から PPK が読み出されます。b. PPK ハッシュ値を生成します。c. ハッシュ化された PPK と、eFUSE から取得された PPK ハッシュ値を比較します。d. 同じ場合はプライマリキーが信頼されます。そうでない場合はセキュアブートエラーとなります。

2. セカンダリキーの検証 - この手順では、セカンダリキーの認証が確立されます。セカンダリキーはパーティションの認証に使用します。a. ブートイメージの AC から SPK が読み出されます。b. SPK ハッシュ値を生成します。c. PSK を使用して AC に格納されている SPK 署名を検証し、SPK ハッシュ値を取得します。d. ステップ (b) およびステップ (c) からのハッシュ値を比較します。e. 同じ場合はセカンダリキーが信頼されます。そうでない場合はセキュアブートエラーとなります。

3. パーティションの検証 - この手順では、ブートされているパーティションの信頼性を確立します。a. ブートイメージからパーティションが読み出されます。b. パーティションのハッシュ値を生成します。c. SSK を使用して AC に格納されているパーティション署名を検証し、パーティションハッシュ値を取得します。

d. ステップ (b) およびステップ (c) からのハッシュ値を比較します。





e. 同じ場合はパーティションが信頼されます。そうでない場合はセキュアブートエラーとなります。図 16: 検証のフロー図

Hash

eFUSE

Hash + RSA

Hash + RSA

Prim

ary

Keys PPK

PSK

Seco

ndar

y Ke

ys SPK

SSK

Partition

Authentication Header

PPK

SPK

SPKSignature

PartitionSignature

PartitionAuthentication

Certificate

Partition

AuthenticationCertificate

Partition Headers

Boot Header

Secret Key

Secret Key

X21278-080618

Bootgen は、次の 2 つの方法で認証証明を作成できます。• PSK と SSK を与えます。これらの 2 つの入力を使用し、SPK 署名がオンザフライで計算されます。• PPK と SSK、そして SPK 署名を入力として与えます。この方法は、PSK がわからない場合に使用されます。

Zynq UltraScale+ MPSoC の認証サポートZynq® UltraScale+™ MPSoC デバイスは RSA-4096 認証を使用するため、プライマリキーおよびセカンダリキーのサイズは 4096 ビットとなります。

NIST SHA-3 のサポート注記: SHA-3 認証では、ブートヘッダー、PPK、およびブートイメージのハッシュ値の計算に Keccak SHA-3 が常に使用されます。ROM によってロードされないその他すべてのパーティションには、NIST-SHA3 が使用されます。生成された署名は、次の表に基づいて Keccak-SHA3 または NIST-SHA3 を使用します。





表 22: 認証署名

認証証明 (AC) の種類署名 SHA アルゴリズムおよび SPKeFUSE

署名の生成に使用される秘密キーヘッダー AC (FSBL/FW によってロードされる)

SPK 署名 SPKID eFUSE の場合 Keecak、ユーザー eFUSE の場合はNIST

PSK

BH 署名常に Keecak SSKheader

ヘッダー署名常に NIST SSKheader

ブートローダー AC (ROM によってロードされる)SPK 署名常に Keecak、常に SPK 用の

SPKID eFUSEPSK

BH 署名常に Keecak SSKBootloader

ヘッダー署名常に Keecak SSKBootloader

パーティション AC (FSBL FWによってロードされる)SPK 署名 SPKID eFUSE の場合 Keecak、ユーザー eFUSE の場合は

NIST

PSK

BH 署名常に Keecak SSKPartition

ヘッダー署名常に NIST SSKPartition

例例 1: 1 つのキーファイルセットでパーティションを認証するための BIF ファイルimage: { [fsbl_config] bh_auth_enable [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem [pmufw_image] pmufw.elf [bootloader, authentication=rsa, destination_cpu=a53-0] fsbl.elf [authenication=rsa, destination_cpu=r5-0] hello.elf }

例 2: パーティションごとに個別のセカンダリキーを使用してパーティションを認証するための BIF ファイルimage: { [auth_params] ppk_select=1 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem // FSBL (Partition-0) [bootloader, destination_cpu = a53-0, authentication = rsa, spk_id = 0x01, sskfile = secondary_p1.pem ] fsbla53.elf // ATF (Partition-1) [ destination_cpu = a53-0, authentication = rsa, exception_level = el-3, trustzone = secure, spk_id = 0x01, sskfile = secondary_p2.pem





] bl31.elf // UBOOT (Partition-2) [ destination_cpu = a53-0, authentication = rsa, exception_level = el-2, spk_id = 0x01, sskfile = secondary_p3.pem ] u-boot.elf }

外部メモリを使用したビットストリーム認証ビットストリームの認証は、その他のパーティションとは異なります。FSBL は、OCM 内にすべて含めることが可能であるため、デバイス内部で認証して復号化できます。ビットストリームの場合は、ファイルサイズが非常に大きいためデバイス内にすべてを含めることができず、外部メモリを使用する必要があります。外部メモリを使用すると、攻撃者がこの外部メモリに侵入する可能性があるため、セキュリティ管理という課題が生じます。ビットストリームの認証が要求されると、Bootgen はビットストリーム全体を 8MB ブロックに分割し、各ブロックに認証証明が与えられます。ビットストリームが 8MB の倍数でない場合は、最後のブロックに残りのビットストリームデータが含まれます。認証と暗号化の両方が有効の場合は、最初にビットストリームの暗号化が実行されます。その後、Bootgenは暗号化されたデータをブロックに分割して、各ブロックに認証証明を提供します。

図 17: 外部メモリを使用したビットストリーム認証

ユーザー eFUSE サポートおよび RSA キー取り消しの改善RSA キー取り消しサポートの改善RSA キーは、すべてのパーティションのセカンダリキーを取り消すことなく、1 つのパーティションのセカンダリキーを取り消すことができます。注記: プライマリキーは、すべてのパーティションで同じものである必要があります。これには、USER_FUSE0 ～ USER_FUSE7 の eFUSE と、BIF パラメーターの spk_select を使用します。注記: すべてのキーを使用する必要がない場合は、最大で 256 個のキーを取り消すことができます。





次の BIF ファイルの例は、改善されたユーザー eFUSE 取り消しを示しています。イメージヘッダーおよび FSBL は、下記の例を BIF へ追加することで、認証に異なる SSK を使用します (それぞれ ssk1.pem および ssk2.pem)。the_ROM_image: { [auth_params]ppk_select = 0 [pskfile]psk.pem [sskfile]ssk1.pem [ bootloader, authentication = rsa, spk_select = spk-efuse, spk_id = 0x8, sskfile = ssk2.pem ] zynqmp_fsbl.elf [ destination_cpu = a53-0, authentication = rsa, spk_select = user-efuse, spk_id = 0x200, sskfile = ssk3.pem ] application.elf [ destination_cpu = a53-0, authentication = rsa, spk_select = spk-efuse, spk_id = 0x8, sskfile = ssk4.pem ] application2.elf }

• spk_select = spk-efuse の場合、そのパーティションに spk_id eFUSE が使用されることを意味します。• spk_select = user-efuse の場合、そのパーティションにユーザー eFUSE が使用されることを意味します。CSU ROM によってロードされるパーティションは、常に spk_efuse を使用します。注記: spk_id eFUSE は、どのキーが有効であるかを指定します。したがって、ROM は spk_id eFUSE のフィールド全体を SPK ID と照合してビットが一致することを確認します。ユーザー eFUSE は、どのキー ID が有効でない (取り消された) かを指定します。したがって、ファームウェア (ROM以外) は、SPK ID を表すそのユーザー eFUSE がプログラムされているかどうかをチェックします。

キーの生成Bootgen には RSA キーを生成する機能があります。または、OpenSSL などの外部ツールを使用してキーを作成することもできます。Bootgen は BIF ファイルで指定したパスにキーを作成します。次の図は、RSA 秘密キーファイルの例です。





図 18: RSA 秘密キーファイルの例

BIF の例BIF ファイルの例 generate_pem.bif を次に示します。generate_pem: { [pskfile] psk0.pem [sskfile] ssk0.pem }





コマンドキーを生成する構文は、次のとおりです。bootgen -generate_keys pem -arch zynqmp -image generate_pem.bif

eFUSE 用の PPK ハッシュBootgen は、PPK が信頼されることを確実にすることを目的とした、eFUSE に格納するための PPK ハッシュを生成します。次に示す手順は、eFUSE モードの RSA 認証でのみ実行する必要があり、Zynq® UltraScale+™ MPSoC デバイスの RSA ブートヘッダー認証ではスキップできます。efuseppksha.txt からの値は、eFUSE にプログラムして、eFUSE モードの RSA 認証に使用できます。BBRAM および eFUSE プログラミングの詳細は、『BBRAM および eFUSE のプログラミング』 (XAPP1319: 英語版、日本語版) を参照してください。

BIF ファイルの例BIF ファイルの例 (generate_hash_ppk.bif) を次に示します。generate_hash_ppk: { [pskfile] psk0.pem [sskfile] ssk0.pem [bootloader, destination_cpu=a53-0, authentication=rsa] fsbl_a53.elf }

コマンドeFUSE プログラミング用の PPK ハッシュを生成するコマンドは次のとおりです。bootgen –image generate_hash_ppk.bif –arch zynqmp –w –o /test.bin –efuseppkbits efuseppksha.txt

HSM モードの使用現在の暗号技術では、すべてのアルゴリズムが公開されているため、秘密キーの保護が重要です。ハードウェアセキュリティモジュール (HSM) は、暗号化キーのライフサイクルを保護するために特別に設計された専用の暗号処理デバイスであり、公開キーのみが Bootgen に渡され、秘密キーは渡されないことからキー処理セキュリティが向上します。標準モードも利用可能です。このモードではキーを渡す必要はありません。一部の組織では、情報セキュリティ担当者がセキュアエンベデッド製品のプロダクションリリースを担当します。情報セキュリティスタッフは、デジタル署名に HSM を使用し、暗号化には別のセキュアサーバーを使用することがあります。HSM とセキュアサーバーは、通常はセキュアエリア内に配置されます。HSM はセキュアキー/署名生成デバイスであり、秘密キーを生成し、秘密キーを使用してパーティションの暗号化を実行し、RSA キーの公開部分をBootgen に提供します。秘密キーは、HSM にのみ配置されます。HSM モードの Bootgen は、RSA 公開キーと、ブートイメージを生成するために HSM によって作成された署名のみを使用します。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受け入れ、ハッシュ値と RSA秘密キーに基づいて署名ブロックを返します。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=xapp1319-zynq-usp-prog-nvm.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=application_notes;d=j_xapp1319-zynq-usp-prog-nvm.pdf



HSM モードとは対照的に、標準モードの Bootgen は、イメージ内のパーティションの暗号化および認証に AES 暗号化キーと BIF ファイルで提供される RSA 秘密キーそれぞれ使用します。出力は 1 つのブートイメージであり、暗号化されて認証されています。認証用に、ユーザーは公開キーと秘密キーの両方のセットを提供する必要があります。Bootgen は秘密キーを使用してパーティションに署名を入れ、署名を作成します。これらの署名は公開キーと共に最終的なブートイメージに埋め込まれます。FPGA の HSM モードの詳細は、FPGA の HSM モードを参照してください。

高度なキー管理オプションの使用秘密キーに関連付けられた公開キーは、ppkZynq.pem および spk.pem です。HSM は、Bootgen によって生成されたパーティションのハッシュ値を受け入れ、ハッシュ値と秘密キーに基づいて署名ブロックを返します。

HSM モードを使用したブートイメージの作成: PSK の共有はなし次の図に、HSM モードを使用するステージ 0 ～ステージ 2 のブートスタックを示します。SSK を配布することでステップ数が削減されています。この図では、Zynq® UltraScale+™ MPSoC デバイスを使用して各ステージを説明しています。

図 19: 一般的な 3 ステージブートイメージ

HSM Mode

Stag

e-1 PSK hash

Generate SPKsignature

SPK hashSPK signature

BOOTGEN

Stag

e-0

Generate SPKHash

SPK SPK hash

BOOTGEN

Stag

e-2

Generate Boot Image

PPK and SSKFinal Boot

Image

PSK

FSBLpartitions

NKY Key

SPK signature

X21359-082818

ブートプロセスHSM モードを使用してブートイメージを作成した場合、次の BIF ファイルを用いて標準フローで作成したブートイメージと類似したものになります。all: { [auth_params] ppk_select=1;spk_id=0x12345678 [keysrc_encryption]bbram_red_key [pskfile]primary.pem





[sskfile]secondary.pem [bootloader,encryption=aes,aeskeyfile=aes.nky,authentication=rsa]fsbl.elf [destination_cpu=a53-0,authentication=rsa]hello_a53_0_64.elf }

ステージ 0: HSM モードを使用してブートイメージを作成する信頼を受けた個人は、プライマリ秘密キーを使用して SPK 署名を作成します。SPK 署名は、認証証明ヘッダー、SPK、および SPKID にあります。SPK のハッシュを生成します。BIF ファイルのスニペットを次に示します。stage 0: { [auth_params] ppk_select=1;spk_id=0x12345678 [spkfile]keys/secondary.pub }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage0.bif -generate_hashes

このコマンドの出力は secondary.pub.sha384 です。

ステージ 1: SPK 署名を配布する信頼を受けた個人は SPK 署名を開発チームに配布します。openssl rsautl -raw -sign -inkey keys/primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig

このコマンドの出力は secondary.pub.sha384.sig

ステージ 2: FSBL で AES を使用して暗号化する開発チームは Bootgen を使用して、必要な数のブートイメージを作成します。開発チームは次を使用します。• 信頼を受けた個人からの SPK 署名。• セカンダリ秘密キー (SSK)、SPK、および SPKID

Stage2: { [keysrc_encryption]bbram_red_key [auth_params] ppk_select=1;spk_id=0x12345678 [ppkfile]keys/primary.pub [sskfile]keys/secondary0.pem [spksignature]secondary.pub.sha384.sig [bootloader,destination_cpu=a53-0, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa] fsbl.elf [destination_cpu=a53-0, authentication=rsa] hello_a53_0_64.elf }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2.bif -o final.bin





HSM モードを使用した Zynq-7000 SoC デバイスブートイメージの作成次の図に、HSM モードの Zynq®-7000 SoC デバイスのブートイメージの図を示します。この図の後にブートイメージを作成する手順を示しています。

図 20: ステージ 0 ～ 8 のブートプロセス

Stage-2b

BOOTGEN

Stag

e-7a

PPK & SPKFSBL with auth certificateencrypted

FSBL

SPK sign

BOOTGEN

Stag

e-7a

PPK & SPKFSBL with auth certificateencrypted

FSBL

SPK sign

HSM

Stag

e-1 PSK hash

Generate SPKsignature

SPK hashSPK signature

nky key

HSM

Stag

e-4a

Generate FSBL Signature

FSBL hash FSBL Signature

BOOTGEN

Stag

e-5a

PPK & SPK

FSBL Signatureencrypted FSBL

SPK signature

BOOTGEN

Stag

e-0

Generate SPKHash

SPK SPK hash

BOOTGEN

Stag

e-6

Generate header Table

hash

Header Table hash

HSM

Stag

e-7

Generate Header Table

signatureHeader

Table hash

Header Table Signature

Stag

e-8 Generate

bootmage

final bootimage


PSK

Generate FSBL hashe

PPK & SPKFSBL hashencrypted

FSBL

SPK signature

Stage-3b

Generate FSBLHash

Stage-4b

Stage-5b

Partions with Authenticated

Certificates

Stag

e-3a

BOOTGEN

Stag

e-2a

Encrypt FSBLFSBL

nky Key

encrypted FSBL

BOOTGEN

Stage- 3a

SSK

FSBL signature

InsertFSBL Signature

SSK

BOOTGEN

Stag

e-8 Generate Boot

ImageFinal Boot Image

Partions with Authenticated

Certificates


X21416-090518





Zynq®-7000 SoC デバイスに対して HSM モードを使用してブートイメージを作成した場合、次の BIF ファイルを用いて標準フローで作成したブートイメージと類似したものになります。これらの例は、必要に応じてハッシュファイルを生成するために OpenSSL プログラムを使用します。all: { [aeskeyfile]my_efuse.nky [pskfile]primary.pem [sskfile]secondary.pem [bootloader,encryption=aes,authentication=rsa] zynq_fsbl_0.elf [authentication=rsa]system.bit }

ステージ 0: SPK のハッシュを生成するBIF ファイルのスニペットを次に示します。BIF ファイルのスニペットを次に示します。stage0: { [ppkfile]primary.pub [spkfile]secondary.pub }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage0.bif –w on -generate_hashes

ステージ 1: SPK ハッシュに署名するパーティションを暗号化します。xil_rsa_sign.exe -gensig -sk primary.pem /-data secondary.pub.sha256 /-out secondary.pub.sha256.sig

このコマンドの出力は、 secondary.pub.sha256.sig

ステージ 2: AES を使用して暗号化するBIF ファイルの次のスニペットを使用して暗号化します。Stage 2: { [aeskeyfile]my_efuse.nky [bootloader,encryption=aes]zynq_fsbl_0.elf }

Bootgen コマンドは次のとおりです。bootgen -image stage2a.bif -w -o fsbl_e.bin -encrypt efuse

出力は、暗号化されたファイル fsbl_e.bin です。





ステージ 3: パーティションハッシュを生成するステージ 3a: 次の BIF ファイルを使用してブートヘッダーハッシュを生成します。stage3a: { [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa]fsbl_e.bin }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage3a.bif -w -o -generate_hashes

出力は、ハッシュファイル zynq_fsbl_0.elf.0.sha256

ステージ 3b: 次の BIF ファイルを使用してブートヘッダーハッシュを生成します。stage3b: { [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa]system.bit }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage3b.bif -w -o -generate_hashes

出力は、ハッシュファイル system.bit.0.sha256 です。

ステージ 4: ハッシュに署名するステージ 4a: 次の BIF ファイルを使用して FSBL パーティションハッシュに署名します。xil_rsa_sign.exe -gensig -sk secondary.pem -data system.bit.0.sha256 -out system.bit.0.sha256.sig

出力は、ハッシュファイル system.bit.0.sha256.sig

ステージ 4b: 次の BIF ファイルを使用してビットストリームハッシュに署名します。xil_rsa_sign.exe -gensig -sk secondary.pem -data system.bit.0.sha256 -out system.bit.0.sha256.sig

出力は、署名ファイル system.bit.0.sha256.sig です。





ステージ 5: パーティション署名を認証証明に挿入するステージ 5a: 次の BIF ファイルを使用して FSBL ハッシュを挿入します。stage5a: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa,presign=zynq_fsbl_0.elf.0.sha256.sig] fsbl_e.bin }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage5a.bif -w -o fsbl_e_ac.bin -efuseppkbitsefuseppkbits.txt -nonbooting

認証された出力ファイルは fsbl_e_ac.bin および efuseppkbits.txt です。ステージ 5b: 次の BIF ファイルを使用してビットストリームを挿入します。stage5b: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa,presign=zynq_fsbl_0.elf.0.sha256.sig] system.bit }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage5b.bif -o system_e_ac.bin –nonbooting

認証された出力ファイルは system_e_ac.bin です。

ステージ 6: ヘッダーテーブルハッシュを生成するBIF ファイルおよび Bootgen コマンドは次のようになります。bootgen.exe -image stage6.bif -generate_hashes

出力ハッシュファイルは ImageHeaderTable.sha256 です。

ステージ 7: ヘッダーテーブル署名を生成する次のコマンドを使用してヘッダーテーブル署名を生成します。xil_rsa_sign.exe -gensig -sk secondary.pem -dataImageHeaderTable.sha256 -out ImageHeaderTable.sha256.sig

出力ハッシュファイルは ImageHeaderTable.sha256.sig です。





ステージ 8: パーティションを結合し、ヘッダーテーブル署名を挿入するBIF ファイルに次を追加します。stage8: { [headersignature]ImageHeaderTable.sha256.sig [bootimage]fsbl_e_ac.bin [bootimage]system_e_ac.bin }

Bootgen コマンドは次のとおりです。bootgen.exe -image stage8.bif -w -o final.bin

出力ファイルは、最終的なブートイメージ final.bin です。

HSM モードを使用した Zynq UltraScale+ MPSoC デバイスブートイメージの作成次の図に、HSM モードのブートイメージの図を示します。





図 21: 0 ～ 10 ステージのブートプロセス

X21547-091318

BH hash

BOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK FSBL with

auth certificate

encrypted FSBL

SPK signBOOTGEN

Stag

e-7a

Encrypt FSBL

PPK & SPK

encrypted FSBL

SPK sign

BOOTGEN

Generate SPKHash

FSBLnky key

BOOTGEN

Stage-2b

Generate SPKHash

FSBLnky key

HSM

Stag

e-1

Generate SPK

signatureSPK hash SPK

signature

BOOTGEN

Stag

e-2a

Encrypt FSBL

FSBLencrypted FSBLnky key

BOOTGEN

Stag

e-3 Generate

BHhash

PPK & SPK BH hash

Encrypted FSBL

HSM

Stag

e-4

Generate BH

signature

BH hashBH signature

BOOTGEN

Stag

e-5 Generate

partition hashes

PPK & SPKpartition hashesencrypted

partitions

SPK signature BH signature

HSM

Stag

e-6

Generate partition

signaturespartition hashes

partition signatures

BOOTGEN

Stag

e-7a

PPK & SPK

FSBL with authentication certificate

encrypted FSBL

SPK signature BH signature*BOOTGEN

Stag

e-0

Generate SPKHash

PPK & SPK SPK hash

BOOTGEN

Stag

e-8

Generate Header

Table hash

Partitions with Authenticated

Certificate

Header Table hash

HSM

Stag

e-9

Generate headerTable

signature

Header Table hash

Header Table signature

BOOTGEN

Stag

e-10

Generate bootmage

Partitions with Authenticated

Certificate

final bootimage

header Table signatureSPK Signature

Insert FSBLSignature

Stage-7bStage-7c

Stage-2c

SSK

SSK

SSK

Zynq® UltraScale+™ MPSoC デバイスに対して HSM モードを使用してブートイメージを作成した場合、次の BIF ファイルを用いて標準フローで作成したブートイメージと類似したものになります。これらの例は、必要に応じてハッシュファイルを生成するために OpenSSL プログラムを使用します。all: { [fsbl_config] bh_auth_enable [keysrc_encryption] bbram_red_key [pskfile] primary0.pem





[sskfile] secondary0.pem [bootloader,destination_cpu=a53-0,encryption=aes,aeskeyfile=aes0.nky,authentication=rsa]fsbl.elf [destination_device=pl,encryption=aes,aeskeyfile=aes1.nky,authentication=rsa] system.bit [destination_cpu=a53-0,authentication=rsa,exception_level=el-3,trustzone=secure]bl31.elf [destination_cpu=a53-0,authentication=rsa,exception_level=el-2]u-boot.elf }

ステージ 0: SPK のハッシュを生成するBIF ファイルのスニペットを次に示します。stage0: { [ppkfile]primary.pub [spkfile]secondary.pub }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage0.bif -generate_hashes -w on -log error

ステージ 1: SPK ハッシュに署名する (パーティションを暗号化する)

OpenSSL を使用して SPK ハッシュを生成するコードスニペットを次に示します。openssl rsautl -raw -sign -inkey primary0.pem -in secondary.pub.sha384 > secondary.pub.sha384.sig

このコマンドの出力は secondary.pub.sha384.sig です。

ステージ 2a: FSBL を暗号化するBIF ファイルの次のスニペットを使用して FSBL を暗号化します。Stage 2a: { [keysrc_encryption] bbram_red_key [bootloader,destination_cpu=a53-0,encryption=aes,aeskeyfile=aes0.nky]fsbl.elf }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2a.bif -o fsbl_e.bin -w on -log error





ステージ 2b: ビットストリームを暗号化する次の BIF ファイルエントリを生成します。stage2b: { [encryption=aes,aeskeyfile=aes1.nky,destination_device=pl,pid=1]system.bit }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage2b.bif -o system_e.bin -w on -log error

ステージ 3: ブートヘッダーハッシュを生成する次の BIF ファイルを使用してブートヘッダーハッシュを生成します。stage3: { [fsbl_config] bh_auth_enable [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bootimage,authentication=rsa]fsbl_e.bin }


ステージ 4: ブートヘッダーハッシュを署名する次の OpenSSL コマンドを使用して、ブートヘッダーハッシュを生成します。openssl rsautl -raw -sign -inkey secondary0.pem -in bootheader.sha384 > bootheader.sha384.sig

ステージ 5: パーティションハッシュを取得するBIF ファイルの次のコマンドを使用して、パーティションハッシュを取得します。stage5: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [bootimage,authentication=rsa]fsbl_e.bin [bootimage,authentication=rsa]system_e.bin [destination_cpu=a53-0,authentication=rsa,exception_level=el-3,trustzone=secure]bl31.elf [destination_cpu=a53-0,authentication=rsa,exception_level=el-2]u-boot.elf }






ビットストリームパーティション用に複数のハッシュが生成されます。詳細は、外部メモリを使用したビットストリーム認証を参照してください。ブートヘッダーハッシュもこのステージ 5 で生成されます。このハッシュは、bh_auth_enable がステージ 5 では使用されていないため、ステージ 3 で生成されたものとは異なります。必要に応じてステージ 5 に追加できますが、大きな影響はありません。それは、ステージ 3 で生成されたブートヘッダーハッシュはステージ 4 で署名され、この署名が HSM モードフローでしか使用されないためです。

ステージ 6: パーティションハッシュに署名するOpenSSL を使用して次のファイルを作成します。openssl rsautl -raw -sign -inkey secondary0.pem -in fsbl.elf.0.sha384 > fsbl.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.0.sha384 > system.bit.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.1.sha384 > system.bit.1.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.2.sha384 > system.bit.2.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in system.bit.3.sha384 > system.bit.3.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in u-boot.elf.0.sha384 > u-boot.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.0.sha384 > bl31.elf.0.sha384.sigopenssl rsautl -raw -sign -inkey secondary0.pem -in bl31.elf.1.sha384 > bl31.elf.1.sha384.sig

ステージ 7: パーティション署名を認証証明に挿入するステージ 7a: 次のコードを BIF ファイルに追加して FSBL 署名を挿入するStage7a: { [fsbl_config] bh_auth_enable [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [bootimage,authentication=rsa,presign=fsbl.elf.0.sha384.sig]fsbl_e.bin }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7a.bif -o fsbl_e_ac.bin -efuseppkbits efuseppkbits.txt -nonbooting -w on -log error





ステージ 7b: BIF ファイルに次を追加してビットストリーム署名を挿入するstage7b: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [bootimage,authentication=rsa,presign=system.bit.0.sha384.sig]system_e.bin }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7b.bif -o system_e_ac.bin -nonbooting -w on -log error

ステージ 7c: BIF ファイルに次を追加して U-Boot 署名を挿入するstage7c: { [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [destination_cpu=a53-0,authentication=rsa,exception_level=el-2,presign=u-boot.elf.0.sha384.sig]u-boot.elf }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7c.bif -o u-boot_ac.bin -nonbooting -w on -log error

ステージ 7d: BIF ファイルに次を追加して ATF 署名を挿入するstage7d: { [ppkfile] primary.pub [spkfile] secondary.pub [spksignature]secondary.pub.sha384.sig [bhsignature]bootheader.sha384.sig [destination_cpu=a53-0,authentication=rsa,exception_level=el-3,trustzone=secure,presign=bl31.elf.0.sha384.sig]bl31.elf }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage7d.bif -o bl31_ac.bin -nonbooting -w on -log error





ステージ 8: パーティションを結合し、ヘッダーテーブルハッシュを取得するBIF ファイルに次を追加します。stage8: { [bootimage]fsbl_e_ac.bin [bootimage]system_e_ac.bin [bootimage]bl31_ac.bin [bootimage]u-boot_ac.bin }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage8.bif -generate_hashes -o stage8.bin -w on -log error

ステージ 9: ヘッダーテーブルハッシュに署名するOpenSSL を使用して次のファイルを生成します。openssl rsautl -raw -sign -inkey secondary0.pem -in ImageHeaderTable.sha384 > ImageHeaderTable.sha384.sig

ステージ 10: パーティションを結合し、ヘッダーテーブル署名を挿入するBIF ファイルに次を追加します。stage10: { [headersignature]ImageHeaderTable.sha384.sig [bootimage]fsbl_e_ac.bin [bootimage]system_e_ac.bin [bootimage]bl31_ac.bin [bootimage]u-boot_ac.bin }

Bootgen コマンドは次のとおりです。bootgen -arch zynqmp -image stage10.bif -o final.bin -w on -log error





第 6 章

FPGA のサポート第 5 章: ブート時のセキュリティで説明したように、FPGA のみで構成されるデバイスもセキュリティを維持しながらフィールド展開する必要があります。ザイリンクスツールは、暗号化および認証を実現するためのエンベデッド IPモジュールをプログラミングロジックの一部として提供します。Bootgen は、7 シリーズ以降の FPGA ファミリデバイスに幅広く対応するセキュアイメージの作成 (暗号化および/または認証) をサポートしています。この章では、Bootgen を使用してビットストリームを暗号化して認証する方法について例を挙げて説明します。FPGA をサポートする Bootgen は、スタンドアロンの Bootgen インストールで入手できます。注記: 7 シリーズデバイス以降のビットストリームのみがサポートされています。

暗号化および認証ザイリンクス FPGA は、内蔵型で PL ベースの HMAC (Hash-based Message Authentication Code)、および CipherBlock Chaining (CBC) モードの Advanced Encryption Standard (AES) モジュールを使用します。

暗号化の例暗号化されたビットストリームを作成するには、aeskeyfile 属性を使用して BIF で AES キーファイルを指定します。encryption=aes 属性は、BIF ファイルにリストされている暗号化の必要なビットストリームに対して指定する必要があります。bootgen -arch fpga -image secure.bif -w -o securetop.bit

BIF ファイルは次のようになります。all.bifthe_ROM_image: { [aeskeyfile] encrypt.nky [encryption=aes] top.bit }

認証の例次に、FPGA ビットストリームを認証するための Bootgen コマンドを示します。bootgen -arch fpga -image all.bif -o rsa.bit -w on -log error




BIF ファイルは次のとおりです。all.bifthe_ROM_image: { [sskfile] rsaPrivKeyInfo.pem [authentication=rsa] plain.bit }

ファミリキー/難読化キー難読化キーの暗号化を使用するには、ザイリンクスサポートに登録し、ターゲットデバイスファミリのファミリキーファイルをリクエストする必要があります。このファイルが格納されている場所へのパスは、難読化キーの暗号化を実行する前に BIF オプションとして渡しておく必要があります。ファミリキーを入手するには、[email protected] までお問い合わせください。image: { [aeskeyfile] key_file.nky [familykey] familyKey.cfg [encryption=aes] top.bit }

次の図に、サンプルファミリキーを示します。図 22: ファミリキーのサンプル

HSM モードプロダクションの FPGA では HSM モードを使用しますが、標準モードでも選択できます。

標準モード標準モードは、認証署名が埋め込まれたビットストリームを生成します。このモードで、ユーザーは認証されたビットストリームの生成に秘密キーを利用できます。次のように Bootgen を実行します。bootgen -arch fpga -image all.bif -o rsa_ref.bit -w on -log error

以降の手順に、HSM モードで認証されたビットストリームを生成する方法を説明します。この場合、セキュアチームが秘密キーを管理し、ユーザーはこれを利用できません。次の図は、HSM モードのフローを示しています。

第 6 章: FPGA のサポート




図 23: HSM モードフロー

Stage-2

HSMGenerateSignature

Bitstream Hash& SSK

Stage-0

BootgenAuthenticate with

dummy keydummy.bit

Dummy Key and Bitstream

Bitstream Signature

Stage-3

BootgenUpdate

SignatureAuthenticated Bitstream

Bitstream& SPK

Stage-1

Bootgen

Generate Hashesdummy.bit Hash

X21279-081618

ステージ 0: ダミーキーで認証するこれは、1 つのビットストリームに対するワンタイムタスクです。ステージ 0 の場合、Bootgen は stage0.bif ファイルを生成します。the_ROM_image: { [sskfile] dummykey.pem [authentication=rsa] plain.bit }

注記: 認証されたビットストリームには、ヘッダー、実際のビットストリーム、署名およびフッターが含まれます。この dummy.bit は、認証されたビットストリームのフォーマットでビットストリームを得るために作成され、ダミーの署名を含みます。ダミービットファイルが Bootgen に渡されると、署名が計算されてオフセットに挿入され、認証されたビットストリームが得られます。ステージ 1: ハッシュ値を生成するbootgen -arch fpga -image stage1.bif -generate_hashes -log error

Stage1.bif は次のとおりです。the_ROM_image: { [authentication=rsa] dummy.bit }





ステージ 2: Hash HSM に署名する。ここでは OpenSSL がデモに使用されています。openssl rsautl -sign -inkey rsaPrivKeyInfo.pem -in dummy.sha384 > dummy.sha384.sig

ステージ 3: RSA 証明を実際の署名で更新するStage3.bif は次のとおりです。bootgen -arch fpga -image stage3.bif -w -o rsa_rel.bit -log error

the_ROM_image: { [spkfile] rsaPubKeyInfo.pem [authentication=rsa, presign=dummy.sha384.sig] dummy.bit }

注記: eFUSE に書き込む必要のある公開キーダイジェストは、HSM モードのステージ 3 で生成されたrsaPubKeyInfo.pem.nky ファイルにあります。





付録 A

ユースケースおよび例この章では、Bootgen の代表的なユースケースおよび例について説明します。一部のユースケースはより複雑なため、明示的な命令が必要となります。これらのユースケースおよび例で使用している属性の定義の詳細は、属性および説明を参照してください。

異なるコアでのシンプルアプリケーションブート次の例は、異なるコアで動作するアプリケーションでブートイメージを作成する方法を示しています。pmu_fw.elfは bootROM によってロードされます。fsbl_a53.elf はブートローダーであり、A53-0 コアにロードされます。app_a53.elf は A53-1 コアで、app_r5.elf は r5-0 コアで実行されます。the_ROM_image: { [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=a53-1] app_a53.elf [destination_cpu=r5-0] app_r5.elf }

bootROM による PMUFW のロード次の例は、bootROM によってロードされた pmu_fw.elf でブートイメージを作成する方法を示しています。the_ROM_image: { [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=r5-0] app_r5.elf }




FSBL による PMUFW のロード次の例は、FSBL によってロードされた pmu_fw.elf でブートイメージを作成する方法を示しています。{ [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=pmu] pmu_fw.elf [destination_cpu=r5-0] app_r5.elf}

注記: Bootgen は [pmufw_image] の [bootloader] で指定されたオプションも使用します。[pmufw_image] では追加のパラメーターを使用しません。

Linux のブート次の例は、Zynq® UltraScale+™ MPSoC デバイス (arch=zynqmp) で Linux をブートする方法を示しています。• fsbl_a53.elf はブートローダーであり、a53-0 上で動作します。• pmu_fw.elf は FSBL によってロードされます。• bl31.elf は Arm® Trusted Firmware (ATF) であり、el-3 で動作します。• U-Boot プログラムの uboot は a53-0 上で el-2 で動作します。• Linux イメージの image.ub はオフセット 0x1E40000 に配置され、0x10000000 にロードされます。the_ROM_image: { [bootloader, destination_cpu = a53-0]fsbl_a53.elf [destination_cpu=pmu]pmu_fw.elf [destination_cpu=a53-0, exception_level=el-3, trustzone]bl31.elf [destination_cpu=a53-0, exception_level=el-2] u-boot.elf [offset=0x1E40000, load=0X10000000, destination_cpu=a53-0]image.ub }

暗号化フロー: BBRAM レッドキー

付録 A: ユースケースおよび例




次の例は、BBRAM に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] bbram_red_key [bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0]ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky]App_A53_0.elf }

暗号化フロー: eFUSE に格納されたレッドキー次の例は、eFUSE に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] efuse_red_key [bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0] ZynqMP_Fsbl.elf [destination_cpu = a53-0, encryption=aes, aeskeyfile=aes1.nky] App_A53_0.elf }

暗号化フロー: eFUSE に格納されたブラックキー次の例は、eFUSE に格納されている efuse_blk_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。FSBL に対しては認証も有効です。the_ROM_image: { [fsbl_config] puf4kmode, shutter=0x01000010 [auth_params] ppk_select=0; spk_id=0x584C4E58 [pskfile] primary_4096.pem [sskfile] secondary_4096.pem [keysrc_encryption] efuse_blk_key [bh_key_iv] bhkeyiv.txt [bootloader, encryption=aes, aeskeyfile=aes0.nky, authentication=rsa] fsbl.elf }

注記: ブラックキーの暗号化を使用する場合は、ブートイメージの認証が必須です。





暗号化フロー: ブートヘッダーに格納されたブラックキー次の例は、ブートヘッダーに格納されている bh_blk_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。FSBL に対しては認証も有効です。the_ROM_image: { [pskfile] PSK.pem [sskfile] SSK.pem [fsbl_config] shutter=0x0100005E [auth_params] ppk_select=0 [bh_keyfile] blackkey.txt [bh_key_iv] black_key_iv.txt [puf_file]helperdata4k.txt [keysrc_encryption] bh_blk_key [bootloader, encryption=aes,aeskeyfile=aes0.nky,authentication=rsa, destination_cpu=a53-0]ZynqMP_Fsbl.elf [destination_cpu = a53-0, encryption=aes, aeskeyfile=aes1.nky] App_A53_0.elf }

注記: ブラックキーの暗号化を使用する場合は、ブートイメージの認証が必要です。

暗号化フロー: eFUSE に格納されたグレーキー次の例は、eFUSE に格納されている efuse_gry_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] efuse_gry_key [bh_key_iv] bh_key_iv.txt [bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0] ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky] App_A53_0.elf }





暗号化フロー: ブートヘッダーに格納されたグレーキー次の例は、ブートヘッダーに格納されている bh_gry_key を使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。the_ROM_image: { [keysrc_encryption] bh_gry_key [bh_keyfile] bhkey.txt [bh_key_iv] bh_key_iv.txt [bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0]ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky] App_A53_0.elf }

操作キー次の例は、ブートヘッダーに格納されているグレーキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。次の例は、eFUSE に格納されているレッドキーを使用して FSBL およびアプリケーションに対して暗号化を有効にし、ブートイメージを作成する方法を示しています。{ [fsbl_config] opt_key [keysrc_encryption] efuse_red_key [bootloader, encryption=aes, aeskeyfile=aes0.nky, destination_cpu=a53-0]ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes, aeskeyfile=aes1.nky]App_A53_0.elf }

操作キーを使用して開発環境のデバイスキーを保護するここでは、秘密のレッドキーを管理するチーム A (セキュアチーム) およびチーム B (非セキュアチーム) の 2 つの開発チームが共同で取り組み、秘密のレッドキーを共有せずに暗号化されたイメージを構築するステップを説明します。チーム A は秘密のレッドキーを管理します。チーム B は、開発およびテスト用に暗号化されたイメージを構築しますが、秘密のレッドキーへはアクセスできません。チーム A はデバイスキー (Op_key (操作キー) オプションを使用) でブートローダーを暗号化し、それをチーム B に渡します。チーム B は Op_key を使用してその他のパーティションをすべて暗号化します。チーム B は、Bootgen を使用し、暗号化したパーティションとチーム A から受け取った暗号化されたブートローダーを 1 つの boot.bin にまとめます。





次に、イメージを作成する手順を説明します。手順 - 1

先のステップでは、チーム A は opt_key を使用してデバイスキーでブートローダーを暗号化し、それをチーム B に渡します。これで、チーム B は操作キーをデバイスキーとして使用し、すべてのパーティションと暗号化されたブートローダーをまとめて完全なイメージを作成できます。1. ブートローダーをデバイスキーで暗号化する

bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error

stage1.bif の例:

{ [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [bootloader,destination_cpu=a53-0,encryption=aes,aeskeyfile=aes.nky]fsbl.elf}

stage1 の aes.nky の例:

Device xc7z020clg484;Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;IV 0 F7F8FDE08674A28DC6ED8E37;Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;

2. 操作キーをデバイスキーとして使用し、暗号化されたブートローダーと残りのパーティションをまとめて完全なイメージを作成するbootgen -arch zynqmp -image stage2a.bif -o final.bin -w on -log error

stage2.bif の例:

stage2:{ [bootimage]fsbl_e.bin [destination_cpu=a53-0,encryption=aes,aeskeyfile=aes-opt.nky]hello.elf [destination_cpu=a53-1,encryption=aes,aeskeyfile=aes-opt1.nky]hello1.elf}

stage2 の aes-opt.nky の例:

Device xc7z020clg484;Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;IV 0 F7F8FDE08674A28DC6ED8E37;

手順 - 2: 先のステップでは、チーム A は opt_key オプションを使用してデバイスキーでブートローダーを暗号化し、それをチーム B に渡します。これで、チーム B は、操作キーをデバイスキーとして使用し、パーティションごとに個別に暗号化されたイメージを作成できます。最後に、チーム B は Bootgen を使用し、暗号化されたパーティションすべてと暗号化されたブートローダーをまとめて完全なイメージを作成できます。1. ブートローダーをデバイスキーで暗号化する

bootgen -arch zynqmp -image stage1.bif -o fsbl_e.bin -w on -log error





stage1.bif の例:

stage1:{ [fsbl_config] opt_key [keysrc_encryption] bbram_red_key [bootloader,destination_cpu=a53-0,encryption=aes,aeskeyfile=aes.nky]fsbl.elf}

stage1 の aes.nky の例:

Device xc7z020clg484;Key 0 AD00C023E238AC9039EA984D49AA8C819456A98C124AE890ACEF002100128932;IV 0 F7F8FDE08674A28DC6ED8E37;Key Opt 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F

2. 操作キーをデバイスキーとして使用し、残りのパーティションを暗号化するbootgen -arch zynqmp -image stage2a.bif -o hello_e.bin -w on -log error

stage2a.bif の例:

stage2a:{ [destination_cpu=a53-0,encryption=aes,aeskeyfile=aes-opt.nky]hello.elf}bootgen -arch zynqmp -image stage2b.bif -o hello1_e.bin -w on -log error

stage2b.bif の例:

stage2b:{ [aeskeyfile] aes-opt.nky [destination_cpu=a53-1,encryption=aes,aeskeyfile=aes-opt.nky]hello1.elf}

stage2a および stage2b の aes-opt.nky の例:

Device xc7z020clg484;Key 0 229C993D1310DD27B6713749B6D07FCF8D3DCA01EC9C64778CBAF457D613508F;IV 0 F7F8FDE08674A28DC6ED8E37;

3. Bootgen を使用して上記の例をまとめて完全なイメージを作成するUse bootgen to stitch the above, to form a complete image.

stage3.bif の例:

stage3:{ [bootimage]fsbl_e.bin [bootimage]hello_e.bin [bootimage]hello1_e.bin}

注記: aes.nky の opt_key は aes-opt.nky のキー 0 と同じで、IV 0 は両方の nky ファイルで同じである必要があります。





認証フロー次の例は、FSBL およびアプリケーションに対して認証を有効にし、PPK ハッシュ値の検証をスキップしたブートヘッダー認証を有効にしてブートイメージを作成する方法を示しています。the_ROM_image: { [fsbl_config] bh_auth_enable [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] PSK.pem [sskfile] SSK.pem [bootloader, authentication=rsa, destination_cpu=a53-0] ZynqMP_Fsbl.elf [destination_cpu=a53-0, encryption=aes] App_A53_0.elf }

SHA-3 eFUSE RSA 認証と PPK0 を使用する BIF ファイル次の例は、FSBL およびアプリケーションに対して認証を有効にし、PPK ハッシュ値の検証をスキップしたブートヘッダー認証を有効にしてブートイメージを作成する方法を示しています。the_ROM_image: { [auth_params] ppk_select=0; spk_id=0x00000000 [pskfile] PSK.pem [sskfile] SSK.pem [bootloader, authentication=rsa, destination_cpu=a53-0] ZynqMP_Fsbl.elf [destination_cpu=a53-0, authentication=aes] App_A53_0.elf }

XIP次の例は、zynqmp (Zynq® UltraScale+™ MPSoC) に対して、XIP を実行するブートイメージの作成方法を示しています。the_ROM_image: { [bootloader, destination_cpu=a53-0, xip_mode] mpsoc_qspi_xip.elf }

コマンドの詳細は、xip_mode を参照してください。





付録 B

BIF 属性の参照aeskeyfile構文[aeskeyfile = <keyfile name>] <partition>[aeskeyfile] <key filename>

説明AES キーファイルへのパスです。キーファイルには、パーティションの暗号化に使用される AES キーが含まれます。ファイルの内容は eFUSE または BBRAM に書き込む必要があります。キーファイルが指定されたパスに存在しない場合、Bootgen が暗号化に使用される新しいキーを生成します。注記: Zynq® UltraScale+™ MPSoC のみ: 複数のキーファイルは BIF ファイルで指定する必要があります。Key0、IV0、および Key Opt は、使用されるすべての NKY ファイルで同じものである必要があります。ELF ファイルに対して複数のパーティションが生成される場合、各パーティションは一意のキーファイルからのキーを使用して暗号化できます。次の例を参照してください。引数指定されたファイル名。

戻り値なし

Zynq-7000 SoC 例fsbl.elf パーティションと hello.elf パーティションは test.nky のキーを使用して暗号化されます。Sample BIF - test.bif all: { [keysrc_encryption] bbram_red_key [aeskeyfile] test.nky [bootloader, encryption=aes] fsbl.elf [encryption=aes] hello.elf }




Sample key (.nky) file - test.nky Device xc7z020clg484; Key 0 8177B12032A7DEEE35D0F71A7FC399027BF....D608C58; Key StartCBC 952FD2DF1DA543C46CDDE4F811506228; Key HMAC 123177B12032A7DEEE35D0F71A7FC3990BF....127BD89;

Zynq UltraScale+ MPSoC 例例 1:

fsbl.elf パーティションは test.nky のキーを使用し、hello.elf は test1.nky のキーを使用し、app.elf はtest2.nky のキーを使用して暗号化されます。Sample BIF - test_multipl.bifall: { [keysrc_encryption] bbram_red_key [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf [encryption=aes,aeskeyfile=test1.nky] hello.elf [encryption=aes,aeskeyfile=test2.nky] app.elf }

例 2:

Bootgen が、hello.elf の hello.elf.0、hello.elf.1、および hello.elf.2 という 3 つのパーティションを作成するとします。Sample BIF - test_mulitple.bifall: { [keysrc_encryption] bbram_red_key [bootloader,encryption=aes,aeskeyfile=test.nky] fsbl.elf [encryption=aes,aeskeyfile=test1.nky] hello.elf }

その他の情報:

• fsbl.elf パーティションは、test.nky のキーで暗号化されます。すべての hello.elf パーティションは、test1.nky のキーを使用して暗号化されます。

• test1.1.nky および test1.2.nky という名前のキーファイルを test1.nky と同じパスに置くことで、hello パーティションごとに一意のキーファイルを使用できます。

• hello.elf.0 は test1.nky を使用• hello.elf.1 は test1.1.nky を使用• hello.elf.2 は test1.2.nky を使用• キーファイル (test1.1.nky または test1.2.nky) が存在しない場合、Bootgen はそのキーファイルを生成します。

付録 B: BIF 属性の参照




alignment構文[alignment= <value>] <partition>

バイトアライメントを設定します。パーティションは、この値の倍数値に揃えられるまでパディングされます。この属性はオフセットと共に使用することはできません。

引数揃えられるバイト数。

例Sample BIF - test.bifall: { [bootloader]fsbl.elf [alignment=64] u-boot.elf }

auth_params• 構文:

[auth_params] ppk_select=<0|1>; spk_id <32-bit spk id>;/ spk_select=<spk-efuse/user-efuse>; auth_header

説明認証パラメーターは、ブートイメージ内のパーティションの認証に使用する PPK、SPK などの追加設定を指定します。この BIF パラメーターの引数は次のとおりです。• ppk_select: 使用する PPK を選択します。オプションは 0 (デフォルト) または 1 です。• spk_id: 使用または取り消し可能な SPK を指定します。ユーザー eFUSE サポートおよび RSA キー取り消しの改善を参照してください。デフォルト値は 0x00 です。

• spk_select: SPK とユーザー eFUSE を識別します。オプションは spk-efuse (デフォルト) と user_efuse です。• header_auth: パーティションが認証されていない場合のヘッダーを認証します。注記:

1. ppk_select は各イメージに固有です。2. 各パーティションは固有の spk_select および spk_id を持つことができます。3. spk-efuse id はイメージ全体で一意ですが、spk-efuse id はパーティションによって異なる場合があります。





4. パーティションの範囲外の spk_select/spk_id は、ヘッダーと、これらの指定をパーティション属性として持たないその他のパーティションに使用されます。

例Sample BIF 1 - test.bifall: { [auth_params]ppk_select=0;spk_id=0x12345678 [pskfile] primary.pem [sskfile]secondary.pem [bootloader, authentication=rsa]fsbl.elf }

Sample BIF 2 - test.bifall: { [auth_params] ppk_select=0;spk_select=user-efuse;spk_id=0x22 [pskfile] primary.pem [sskfile] secondary.pem [bootloader, authentication = rsa] fsbl.elf }

Sample BIF 3 - test.bifall: { [auth_params] ppk_select=1; spk_select= user-efuse; spk_id=0x22; header_auth [pskfile] primary.pem [sskfile] secondary.pem [destination_cpu=a53-0] test.elf }

Sample BIF 4 - test.bifall: { [auth_params] ppk_select=1;spk_select=user-efuse;spk_id=0x22 [pskfile] primary.pem [sskfile] secondary0.pem /* FSBL - Partition-0) */ [ bootloader, destination_cpu = a53-0, authentication = rsa, spk_id = 0x12345678, spk_select = spk-efuse, sskfile = secondary1.pem ]fsbla53.elf /* Partition-1 */ [ destination_cpu = a53-1, authentication = rsa, spk_id = 0x24, spk_select = user-efuse, sskfile = secondary2.pem ]hello.elf }





authentication構文[authentication=<option>] <partition>

説明認証されるパーティションを指定します。

引数• none: パーティションは認証されない。これがデフォルト値です。• rsa: パーティションは RSA アルゴリズムを使用して認証される。例Sample BIF - test.bif all: { [ppkfile] ppk.txt [spkfile] spk.txt [bootloader,authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }

bh_keyfile構文[bh_keyfile] <key file path>

説明ブートヘッダーに格納される 256 ビットの難読化キーまたはブラックキーです。これは、暗号化キーのソースがグレーキーまたはブラックキーの場合にのみ有効です。

引数難読化キーまたはブラックキーへのパス (選択されているソースによって異なる)。





例Sample BIF - test.bif all: { [keysrc_encryption] bh_gry_key [bh_keyfile] obfuscated_key.txt [bh_key_iv] obfuscated_iv.txt [bootloader, encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf }

bh_key_iv構文[bh_key_iv] <iv file path>

説明難読化キーまたはブラックキーを復号化する際に使用する初期化ベクターです。

引数ファイルへのパス。

例Sample BIF - test.bif all: { [keysrc_encryption] bh_gry_key [bh_keyfile] obfuscated_key.txt [bh_key_iv] obfuscated_iv.txt [bootloader, encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf }

bhsignature構文[bhsignature] <signature-file>

説明ブートヘッダーの署名を認証証明にインポートします。これは、秘密キー PSK を共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。





例all: { [ppkfile] ppk.txt [spkfile] spk.txt [spksignature] spk.txt.sha384.sig [bhsignature] bootheader.sha384.sig [bootloader,authentication=rsa] fsbl.elf }

blocks構文[blocks = <size><num>;<size><num>;...;<size><*>] <partition>

説明暗号化におけるキーローリング機能のブロックサイズを指定します。各モジュールは独自のキーを使用して暗号化されます。最初のキーはデバイスのキーソースで格納され、後続の各モジュールのキーは直前のモジュール内で暗号化 (ラップ) されます。

引数指定した <size> は、バイト単位で取り込まれます。サイズが X(*) として指定されている場合、残りのブロックのサイズはすべて「X」になります。

例Sample BIF - test.bif all: { [keysrc_encryption] bbram_red_key [bootloader,encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0,blocks=4096(2);1024;2048(2);4096(*)] fsbl.elf }

注記: 上記の例では、最初の 2 つのブロックは 4096 バイトで、2 番目のブロックは 1024 バイトで、次の 2 つのブロックは 2048 バイトです。残りのブロックは 4096 バイトです。

boot_device構文[boot_device] <options>





説明セカンダリブートデバイスを指定します。パーティションが存在するデバイスを示します。

引数オプションは次のとおりです。• qspi32

• qspi24

• nand

• sd0

• sd1

• sd-ls

• mmc

• usb

• ethernet

• pcie

• sata

例all: { [boot_device]sd0 [bootloader,destination_cpu=a53-0]fsbl.elf }

bootimage構文[bootimage] <image created by bootgen>

説明続くファイルの仕様が Bootgen によって作成されたブートイメージであり、入力として再利用されることを指定します。

引数指定されたファイル名。





例Sample BIF - test.bifall: { [bootimage]fsbl.bin [bootimage]system.bin }

上記の例では、fsbl.bin および system.bin は Bootgen を使用して生成されたイメージです。

fsbl.bin 生成の例image: { [pskfile] primary.pem [sskfile] secondary.pem [bootloader, authentication=rsa, aeskeyfile=encr_key.nky, encryption=aes] fsbl.elf } Command: bootgen -image fsbl.bif -o fsbl.bin -encrypt efuse

system.bin 生成の例image: { [pskfile] primary.pem [sskfile] secondary.pem [authentication=rsa] system.bit } Command: bootgen -image system.bif -o system.bin

bootloader構文[bootloader] <partition>

説明ELF ファイルを FSBL として認識します。• この属性は ELF ファイルのみに適用可能です。• 1 ファイルのみブートローダーに指定可能です。• この ELF ファイルのプログラムヘッダーには、ファイルサイズ > 0 の LOAD セクションが 1 つだけ必要です。このセクションは実行可能でなければなりません (xフラグを設定する必要がある)。






例Sample BIF - test.bifall: { [bootloader] fsbl.elf hello.elf }

bootvectors構文[bootvectors] <values>

説明この属性は、XIP (eXecute In Place) のベクターテーブルを指定します。

例all: { [bootvectors]0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000,0x14000000 [bootloader,destination_cpu=a53-0]fsbl.elf }

checksum構文[checksum = <options>] <partition>

説明チェックサムを実行する必要があるパーティションを指定します。認証や暗号化などのよりセキュアな機能と共に使用することはできません。

引数• none: チェックサムなし。• MD5: Zynq®-7000 SoC デバイスの MD5 チェックサム。このデバイスでは、チェックサムはブートローダーでサポートされていません。

• SHA3: Zynq® UltraScale+™ MPSoC デバイスのチェックサム。





destination_cpu構文[destination_cpu <options>] <partition>

説明パーティションをどのコアで実行するかを指定します。次の例では、FSBL を A53-0 コアで実行し、アプリケーションを R5-0 コアで実行するように指定します。注記:

• FSBL は、A53-0 または R5-0 のいずれかでのみ実行できます。• FSBL によってロードされる PMU: [destination_cpu=pmu] pmu.elf。このフローでは、最初に bootROM が

FSBL をロードし、続いて FSBL が PMU ファームウェアをロードします。• bootROM によってロードされる PMU: [pmufw_image] pmu.elf。このフローでは、bootROM が PMU をロードした後に FSBL のロードが続くため、PMU は FSBL が起動する前に電力管理タスクを実行します。

引数• a53-0

• a53-1

• a53-2

• a53-3

• r5-0 (デフォルト)

• r5-1

• r5-lockstep

• pmu

例Sample BIF - test.bifall: { [bootloader,destination_cpu=a53-0]fsbl.elf [destination_cpu=r5-0] app.elf }

destination_device構文[destination_device <options>] <partition>





説明パーティションのターゲットを PS または PL のいずれに指定します。

引数• ps: パーティションのターゲットは PS。これがデフォルト値です。• pl: パーティションのターゲットは PL (ビットストリームの場合)。例 Sample BIF - test.bifall: { [bootloader,destination_cpu=a53-0]fsbl.elf [destination_device=pl]system.bit [destination_cpu=r5-1]app.elf }

early_handoff構文[early_handoff] <partition>

説明このフラグは、パーティションのロード直後に重要なアプリケーションへのハンドオフが確実に実行されるようにします。このオプションを使用しない場合は、最初にすべてのパーティションが順にロードされ、続いてハンドオフが順に実行されます。注記: 次のシナリオでは、FSBL は app1 をロードしてから app2 をロードし、その後すぐに app2 に制御を渡して app1に制御を渡します。例Sample BIF - test.bifall: { [bootloader, destination_cpu=a53_0]fsbl.el [destination_cpu=r5-0]app1.elf [destination_cpu=r5-1,early_handoff]app2.elf }





encryption構文[encryption = <options>] <partition>

説明パーティションを暗号化する必要があることを指定します。暗号化アルゴリズムは次のとおりです。

引数• none: パーティションは暗号化されない。これがデフォルト値です。• aes: パーティションは AES アルゴリズムを使用して暗号化される。例Sample BIF - test.bifall: { [aeskeyfile]test.nky [bootloader,encryption=aes] fsbl.elf hello.elf }

exception_level構文[exception_level=<options>] <partition>

説明コアに設定する例外レベルを指定します。

引数• el-0

• el-1

• el-2

• el-3 (デフォルト)





例Sample BIF - test.bifall: { [bootloader, destination_cpu=a53-0]fsbl.elf [destination_cpu=a53-0, exception_level=el-3] bl31.elf [destination_cpu=a53-0, exception_level=el-2] u-boot.elf }

familykey構文[familykey] <key file path>

説明ファミリキーを指定します。ファミリキーを入手するには、ザイリンクスの代理店 ([email protected]) までお問い合わせください。

引数ファイルへのパス。

例Sample BIF - test.bifall: { [aeskeyfile] encr.nky [bh_key_iv] bh_iv.txt [familykey] familykey.cfg }

fsbl_config構文[fsbl_config <options>] <partition>

説明このオプションは、ブートイメージのコンフィギュレーションに使用するパラメーターを指定します。FSBL は、ブートヘッダー認証モードで 64 ビットモードの A53 上で実行する必要があります。





引数• bh_auth_enable: ブートヘッダー認証イネーブル: ブートイメージの RSA 認証を実行します (PPK ハッシュおよび

SPK ID の検証を除く)。• auth_only: ブートイメージは RSA 署名のみです。FSBL の復号化は実行しません。• opt_key: block-0 の復号化に操作キーを使用します。操作キーはセキュアヘッダーにあります。• pufhd_bh: PUF ヘルパーデータはブートヘッダーに格納されます(デフォルトは efuse)。/PUF ヘルパーデータファイルは、[puf_file] オプションを使用して Bootgen に渡されます。

• puf4kmode: PUF は 4k ビットコンフィギュレーションでの使用に合わせて調整されています(デフォルトは 12kビット)。shutter = <value> 32 ビットの PUF_SHUT レジスタの値で、シャッターオフセット時間およびシャッターオープン時間を PUF に設定します。

例 all: { [fsbl_config] bh_auth_enable, [pskfile] primary.pem [sskfile]secondary.pem [bootloader,destination_cpu=a53-0,authentication=rsa] fsbl.elf }

headersignature構文[headersignature] <signature file>

説明ヘッダーの署名を認証証明にインポートします。これは、秘密キーを共有しない場合に使用できます。署名を作成して Bootgen に与えることができます。

引数<signature_file

例Sample BIF - test.bifall: { [ppkfile] ppk.txt [spkfile] spk.txt [headersignature] headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa] fsbl.elf }





hivec構文[hivec] <partition>

説明例外ベクターテーブルの場所を hivec として指定します。これは、a53 (32 ビット) および r5 コアにのみ適用されます。• hivec: 0xFFFF0000 の例外ベクターテーブル。• lovec: 0x00000000 の例外ベクターテーブル。これがデフォルト値です。引数なし例BIF ファイルのサンプルを次に示します。 all: { [bootloader, destination_cpu=a53_0]fsbl.elf [destination_cpu=r5-0,hivec]app1.elf }

init構文[init] <filename>

説明ブートローダーの最後にあるレジスタ初期化ブロックであり、INT ファイルの仕様を解析して構築されます。最大256 のアドレスと値の初期化ペアが許可されます。INT ファイルには特定のフォーマットがあります。

例BIF ファイルのサンプルを次に示します。Sample BIF - test.bif all: { [init] test.int }





keysrc_encryption構文[keysrc_encryption] <options> <partition>

説明暗号化に使用するキーソースを指定します。

引数• bbram_red_key: BBRAM に格納されているレッドキー。• efuse_red_key: eFUSE に格納されているレッドキー。• efuse_gry_key: eFUSE に格納されているグレー (難読化) キー。• bh_gry_key: ブートヘッダーに格納されているグレー (難読化) キー。• bh_blk_key: ブートヘッダーに格納されているブラックキー。• efuse_blk_key: eFUSE に格納されているブラックキー。• kup_key: ユーザーキー。例all: { [keysrc_encryption]efuse_gry_key [bootloader,encryption=aes, aeskeyfile=encr.nky, destination_cpu=a53-0]fsbl.elf }

FSBL は、暗号化用に eFUSE に格納されている encr.nky キーを使用して暗号化されます。

load構文[load=<value>] <partition>

説明メモリ内のパーティションのロードアドレスを設定します。





例 all: { [bootloader] fsbl.elf u-boot.elf [load=0x3000000, offset=0x500000] uImage.bin [load=0x2A00000, offset=0xa00000] devicetree.dtb [load=0x2000000, offset=0xc00000] uramdisk.image.gz }

offset構文[offset=<value>] <partition>

説明ブートイメージ内のパーティションの絶対オフセットを設定します。

引数指定された値およびパーティション。

例 all: { [bootloader] fsbl.elf u-boot.elf [load=0x3000000, offset=0x500000]uImage.bin [load=0x2A00000, offset=0xa00000] devicetree.dtb [load=0x2000000, offset=0xc00000] uramdisk.image.gz }

partition_owner構文[partition_owner = <options>] <partition>

説明パーティションをロードするパーティションオーナー。

引数• fsbl (デフォルト)





• u-boot

例Sample BIF - test.bifall: { [bootloader]fsbl.elf [partition_owner=uboot] hello.elf }

pid構文 [pid = <id_no>] <partition>

説明パーティション ID を指定します。デフォルト値は 0 です。

例Sample BIF - test.bifall: { [encryption=aes, aeskeyfile=test.nky, pid=1] hello.elf }

pmufw_image構文[pmufw_image] <PMU ELF file>

説明FSBL をロードする前に bootROM によってロードされる PMU ファームウェアイメージです。pmufw_image のオプションは、ブートローダーパーティションに含まれます。Bootgen は、pmufw_image オプションと共に与えられる余分な属性を考慮しません。

引数ファイル名





例the_ROM_image: { [pmufw_image] pmu_fw.elf [bootloader, destination_cpu=a53-0] fsbl_a53.elf [destination_cpu=a53-1] app_a53.elf [destination_cpu=r5-0] app_r5.elf }

ppkfile構文[ppkfile] <key filename>

説明プライマリ公開キー (PPK) は、ブートイメージ内のパーティションを認証するために使用されます。認証の使用を参照してください。

引数指定されたファイル名。注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。例all: { [ppkfile] primarykey.pub [pskfile] primarykey.pem [spkfile] secondarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }

presign構文[presign = <signature_file>] <partition>





説明パーティション署名をパーティション認証証明にインポートします。これは、秘密キー (SSK) を共有しない場合に使用します。署名を作成して Bootgen に与えることができます。• <signature_file>: 署名ファイルを指定します。• <partition>: signature_file に適用するパーティションをリストします。

例Sample BIF - test.bifall: { [ppkfile] ppk.txt [spkfile] spk.txt [headsignature] headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa, presign=fsbl.sig]fsbl.elf }

pskfile構文[pskfile] <key filename>

説明このプライマリ秘密キー (PSK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。

引数指定されたファイル名。注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。例//Sample BIF - test.bifall: { [pskfile]primarykey.pem [sskfile]secondarykey.pem [bootloader,authentication=rsa]fsbl.elf [authentication=rsa] hello.elf }





puf_file構文[puf_file] <puf data file>

説明PUF ヘルパーデータファイル。• PUF は、暗号化キーソースとしてブラックキーと共に使用されます。• PUF ヘルパーデータは 1544 バイトです。• 1536 バイトの PUF HD + 4 バイトの CHASH + 3 バイトの AUX + 1 バイトアライメント。詳細は、ブラックキー/PUF キーを参照してください。

例all: { [fsbl_config]pufhd_bh [puf_file] pufhelperdata.txt [bh_keyfile] black_key.txt [bh_key_iv] bhkeyiv.txt [bootloader,destination_cpu=a53-0,encryption=aes] fsbl.elf }

reserve構文[reserve=<value>] <partition>

説明パーティションのメモリサイズを維持します。このサイズになるまでパーティションにパディングが追加されます。維持するメモリサイズは、バイト数で指定します。

引数指定されたパーティション。





例all: { [bootloader]fsbl.elf [reserve=0x1000]test.bin }

split構文[split] mode = <mode-options>, fmt=<format>

説明モードに基づいてイメージを分割します。スレーブブート (slaveboot) モードでは次のように分割されます。• ブートヘッダー + ブートローダー• イメージヘッダーおよびパーティションヘッダー• 残りのパーティション通常 (normal) モードでは次のように分割されます。• ブートヘッダー + イメージヘッダー + パーティションヘッダー + ブートローダー• パーティション 1

• パーティション 2、以下同様スレーブブートモードは Zynq MP でのみサポートされ、通常モードは Zynq および Zynq MP の両方でサポートされています。分割 (split) モードのほかに、出力フォーマットも bin または mcs に設定できます。

オプション引数で使用可能なオプションは次のとおりです。• slaveboot

• normal

• bin

• mcs





例all:{ [split]mode=slaveboot,fmt=bin [bootloader,destination_cpu=a53-0]fsbl.elf [destination_device=pl]system.bit [destination_cpu=r5-1]app.elf}

注記: オプションの split の normal モードは、コマンドラインオプションの split と同じです。このコマンドラインオプションは廃止予定です。

spkfile構文[spkfile] <key filename>

説明セカンダリ公開キー (SPK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。


例all: { [pskfile] primarykey.pem [spkfile] secondarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }

注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (SSK) が指定されている場合は、公開キー (SPK) を指定する必要はありません。

spksignatureコード例[spksignature] <Signature file>





説明SPK 署名を認証証明にインポートします。これは、ユーザーが秘密キー PSK を共有しない場合に可能で、ユーザーは署名を作成して Bootgen に与えることができます。


例Sample BIF - test.bifall: { [ppkfile] ppk.txt [spkfile] spk.txt [headersignature]headers.sha256.sig [spksignature] spk.txt.sha256.sig [bootloader, authentication=rsa] fsbl.elf }

spk_select構文[spk_select = <options>]or [auth_params] spk_select = <options>

説明オプションは次のとおりです。• spk-efuse: パーティションに spk_id eFUSE が使用されていることを示します。これがデフォルト値です。• user-efuse: パーティションにユーザー eFUSE が使用されていることを示します。CSU ROM によってロードされるパーティションは、常に spk_efuse を使用します。注記: spk_id eFUSE は、どのキーが有効であるかを指定します。したがって、ROM は spk_id eFUSE のフィールド全体を SPK ID と照合してビットが一致することを確認します。ユーザー eFUSE は、どのキー ID が有効でない (取り消された) かを指定します。したがって、ファームウェア (ROM以外) は、SPK ID を表すそのユーザー eFUSE がプログラムされているかどうかをチェックします。spk_select =user-efuse の場合、そのパーティションにユーザー eFUSE が使用されることを意味します。例the_ROM_image: { [auth_params]ppk_select = 0 [pskfile]psk.pem [sskfile]ssk1.pem [bootloader, authentication = rsa, spk_select = spk-efuse, spk_id =





0x12345678,sskfile = ssk2.pem]zynqmp_fsbl.elf [destination_cpu =a53-0,authentication = rsa,spk_select = user-efuse,spk_id = 200,sskfile = ssk3.pem] application1.elf [destination_cpu =a53-0, authentication = rsa,spk_select = spk-efuse,spk_id =0x12345678,sskfile = ssk4.pem] application2.elf }

sskfile構文[sskfile] <key filename>

説明セカンダリ秘密キー (SSK) は、ブートイメージ内のパーティションを認証するために使用されます。詳細は、認証の使用を参照してください。


例//Sample BIF - test.bifall: { [pskfile] primarykey.pem [sskfile] secondarykey.pem [bootloader, authentication=rsa]fsbl.elf [authentication=rsa] hello.elf }

注記: 秘密キーファイルには、キーの公開キーコンポーネントが含まれます。秘密キー (PSK) が指定されている場合は、公開キー (PPK) を指定する必要はありません。

startup構文[startup=<address_value>] <pattiion>

説明このオプションは、ロード後のパーティションのエントリアドレスを設定します。この識別子は、実行しないパーティションでは無視されます。





例Sample BIF - test.bifall: { [bootloader] fsbl.elf [startup=0x1000000] app.elf }

TrustZone構文[trustzone=<options>] <partition>

説明コアを TrustZone セキュアまたは非セキュアに設定します。オプションは次のとおりです。• secure

• nonsecure (デフォルト)

例Sample BIF - test.bif all: { [bootloader,destination_cpu=a53-0] fsbl.elf [exception_level=el-3,trustzone = secure] bl31.elf }

udf_bh構文[udf_bh] <filename>

説明ブートヘッダーのユーザー定義フィールドにコピーされるデータのファイルをインポートします。入力されたユーザー定義データは、16 進数文字列フォーマットのテキストファイルで提供されます。ザイリンクス SoC におけるUDF の総バイト数は次のとおりです。• zynq: 76 バイト• zynqmp: 40 バイト






例Sample BIF - test.bifall: { [udf_bh]test.txt [bootloader]fsbl.elf hello.elf }

udf_bh の入力ファイルの例を次に示します。Sample input file for udf_bh - test.txt 123456789abcdef85072696e636530300301440408706d616c6c6164000508 266431530102030405060708090a0b0c0d0e0f101112131415161718191a1b 1c1d1

udf_data構文[udf_data=<filename>] <partition>

説明最大 56 バイトのデータを含むファイルを認証証明のユーザー定義フィールド (UDF) にインポートします。認証証明の詳細は、認証を参照してください。


例 Sample BIF - test.bifall: { [pskfile] primary0.pem [sskfile]secondary0.pem [bootloader, destination_cpu=a53-0, authentication=rsa,udf_data=udf.txt]fsbl.elf [destination_cpu=a53-0,authentication=rsa] hello.elf }





xip_mode構文[xip_mode] <partition>

説明FSBL が QSPI フラッシュから直接実行されるよう XIP (eXecute-In-Place) を示します。注記: この属性は、FSBL/ブートローダーパーティションにのみ適用されます。引数指定されたパーティション。

例次の例は、Zynq® UltraScale+™ MPSoC デバイスに対して、XIP を実行するブートイメージの作成方法を示しています。 Sample BIF - test.bifall: { [bootloader, xip_mode] fsbl.elf application.elf }





付録 C

コマンドリファレンスarch構文-arch [options]

説明ブートイメージを作成する必要のあるザイリンクスファミリアーキテクチャ。

引数• zynq: Zynq®-7000 デバイスアーキテクチャ。これがデフォルト値です。• zynqmp: Zynq® UltraScale+™ MPSoC デバイスアーキテクチャ。• fpga: イメージはほかの FPGA アーキテクチャをターゲットとしています。戻り値なし

例bootgen -arch zynq -image test.bif -o boot.bin

bif_help構文bootgen -bif_help

bootgen -bif_help aeskeyfile

説明サポートされている BIF ファイルの属性をリストします。各 BIF 属性の詳細は、コマンドラインで -bif_help の引数として属性名を指定すると説明が得られます。

付録 C: コマンドリファレンス




dual_qspi_mode構文bootgen -dual_qspi_mode [parallel]|[stacked <size>

説明Dual QSPI コンフィギュレーションの場合は 2 つの出力ファイルを生成します。スタックドコンフィギュレーションの場合は、フラッシュのサイズ (MB) を指定する必要があります (16、32、64、または 128)。

例次の例は、QSPI デュアルパラレルコンフィギュレーションの 2 つのフラッシュを個別にプログラムするため、2 つの出力ファイルを生成します。bootgen -image test.bif -o -boot.bin -dual_qspi_mode parallel

次の例は、QSPI デュアルパラレルコンフィギュレーションの 2 つのフラッシュを個別にプログラムするため、2 つの出力ファイルを生成します。実際のイメージの最初の 64MB が 1 つ目のファイルに書き込まれ、残りは 2 つ目のファイルに書き込まれます。実際のイメージが 64MB 未満の場合は、1 つのファイルのみ生成されます。bootgen -image test.bif -o -boot.bin -dual_qspi_mode stacked 64

引数• parallel

• stacked <size>

efuseppkbits構文

bootgen -image test.bif -o boot.bin -efuseppkbits efusefile.txt

引数efusefile.txt

説明このオプションは、PPK ハッシュを書き込む eFUSE ファイルの名前を指定します。また、パディングなしでダイレクトハッシュを生成します。PPK キーのハッシュを含む efusefile.txt ファイルが生成されます。ハッシュ処理については、次のとおりです。• Zynq®-7000 は、ハッシュ処理に SHA2 プロトコルを使用します。





• Zynq® UltraScale+™ MPSoC は、ハッシュ処理に SHA3 を使用します。

encrypt構文bootgen -image test.bif -o boot.bin -encrypt <efuse|bbram|>

説明このオプションは、暗号化の実行方法とキーの格納場所を指定します。NKY キーファイルは、BIF ファイルのaeskeyfile 属性で渡されます。コマンドラインで指定されるのはキーソースのみです。

引数キーソースの引数は次のとおりです。efuse: AES キーは eFUSE に格納されます。これがデフォルト値です。bbram: AES キーは BBRAM に格納されます。

encryption_dump構文bootgen -arch zynqmp -image test.bif -encryption_dump

説明暗号ログファイル aes_log.txt を生成します。生成される aes_log.txt には、データの各ブロックの暗号化に使用される AES キー/IV ペアの詳細が含まれます。また、パーティションとそれを暗号化するために使用した AES キーファイルもログに記録されます。注記: このオプションは、Zynq® UltraScale+™ MPSoC でのみサポートされています。例Sample BIF - test.bif all: { [bootloader, encryption=aes, aeskeyfile=test.nky] fsbl.elf [encryption=aes, aeskeyfile=test1.nky] hello.elf }





fill構文bootgen -arch zynq -image test.bif -fill 0xAB -o boot.bin

説明このオプションは、パディング/予約されているメモリを <hex byte> フォーマットで埋めるために使用するバイトを指定します。

出力0xAB バイトの boot.bin ファイル。

例出力イメージは boot.bin という名前で生成されます。出力イメージのフォーマットは、-o オプションで指定するファイル拡張子に基づいて決まります。この例では、-fill: でパディングするバイトを指定します。0xFF ではなく<hex byte> がヘッダーテーブルにパディングされます。bootgen -arch zynq -image test.bif -fill 0xAB -o boot.bin

generate_hashes構文bootgen -image test.bif -generate_hashes

説明このオプションは、すべてのパーティションおよびその他のコンポーネントがブートヘッダー、イメージ、およびパーティションヘッダーと同様に署名されるようハッシュファイルを生成します。また、Zynq®-7000 フォーマット用に PKCS＃1v1.5 のパディングされたハッシュを含むファイルを生成します。表 23: Zynq: SHA-2 (256 バイト)

値 SHA-2 ハッシュ* T-パディング 0x0 0xFF 0x01 0x00

バイト数 32 19 1 202 1 1

このオプションは、Zynq® UltraScale+™ MPSoC フォーマット用に PKCS＃1v1.5 のパディングされたハッシュを含むファイルを生成します。





表 24: ZynqMP: SHA-3 (384 バイト)

値 0x0 0x1 0xFF 0xFF T-パディング SHA-3 ハッシュバイト数 1 1 314 1 19 48

例test: { [pskfile] ppk.txt [sskfile] spk.txt [bootloader, authentication=rsa] fsbl.elf [authentication=rsa] hello.elf }

Bootgen は、指定された BIF で次のハッシュファイルを生成します。• ブートヘッダーハッシュ• spk ハッシュ• ヘッダーテーブルハッシュ• fsbl.elf パーティションハッシュ• hello.elf パーティションハッシュ

generate_keys構文bootgen -image test.bif -generate_keys <rsa|pem|obfuscated>

説明このオプションは、認証用のキーと暗号化に使用される難読化キーを生成します。注記: 暗号化キーの生成の詳細は、キーの生成を参照してください。認証キー生成の例認証キー生成の例。この例では、BIF ファイルで指定したパスに認証キーを生成します。

例test.bifimage: { [ppkfile] <path/ppkgenfile.txt> [pskfile] <path/pskgenfile.txt> [spkfile] <path/spkgenfile.txt> [sskfile] <path/sskgenfile.txt> }





難読化キー生成の例この例では、familykey.txt と同じパスで難読化されたものを生成します。

コマンドbootgen -image test.bif -generata_keys rsa

BIF ファイルの例を次に示します。image: { [aeskeyfile] aes.nky [bh_key_iv] bhkeyiv.txt [familykey] familykey.txt }

引数• rsa

• pem

• obfuscated

image構文-image <BIF_filename>

説明このオプションは、入力する BIF ファイル名を指定します。BIF ファイルは、ブートイメージの各コンポーネントをブート順に指定し、オプションで各イメージコンポーネントに属性を指定できるようにします。各イメージコンポーネントは、通常 1 つのパーティションにマップされますが、1 つのイメージコンポーネントがメモリ内で連続する場合は、1 つのイメージコンポーネントが複数パーティションにマップされます。

引数bif_filename

例bootgen -arch zynq -image test.bif -o boot.bin





BIF ファイルの例を次に示します。the_ROM_image: { [init] init_data.int [bootloader] fsbl.elf Partition1.bit Partition2.elf }

log構文bootgen -image test.bif -o -boot.bin -log trace

説明ブートイメージの作成中にログを生成します。情報のレベルに応じてさまざまなオプションがあります。情報はコンソールに表示され、bootgen_log.txt という名前のログファイルが作業ディレクトリに生成されます。

引数• error: エラー情報のみ記録されます。• warning: 警告およびエラー情報が記録されます。これがデフォルト値です。• info: 一般的な情報および上記すべての情報が記録されます。• trace: より詳細な情報が上記の情報と共に記録されます。

nonbooting構文bootgen -arch zynq -image test.bif -o test.bin -nonbooting

説明このオプションは、中間のブートイメージを作成するために使用されます。中間の test.bin イメージは、認証イメージの生成に必要な秘密キーがなくても出力として生成されます。この中間イメージはブートできません。





例Sample BIF - test.bif all: { [ppkfile]primary.pub [spkfile]secondary.pub [spksignature]secondary.pub.sha256.sig [bootimage,authentication=rsa,presign=fsbl_0.elf.0.sha256.sig]fsbl_e.bin }

o構文bootgen -arch zynq -image test.bif -o boot.<bin|mcs>

説明このオプションは、出力イメージファイルの名前 (拡張子) を .bin または .mcs で指定します。

出力BIN または MCS フォーマットのフルブートイメージファイル。

例bootgen -arch zynq -image test.bif -o boot.mcs

ブートイメージは MCS フォーマットで出力されます。

p構文bootgen -image test.bif -o boot.bin -p xc7z020clg48 -encrypt efuse

説明このオプションは、ザイリンクスデバイスのパーツ名を指定します。これは、暗号化キーを生成するために必要です。NKY ファイルの Device 行の *.nky ファイルにそのままコピーされます。これは、暗号化が有効な場合にのみ適用されます。BIF ファイルで指定されたパスにキーファイルが存在しない場合、同じパスに新しい暗号化キーが生成され、nky ファイルの Device フィールドの横に xc7z020clg484 がコピーされます。生成されたイメージは暗号化されたイメージです。





padimageheader構文bootgen -image test.bif -w on -o boot.bin -padimageheader=<0|1>

説明このオプションは、イメージヘッダーテーブルとパーティションヘッダーテーブルを可能な限り数多くのパーティションにパディングし、続くパーティションを強制的に揃えます。この機能はデフォルトで有効になっています。0を指定すると、無効になります。実際の boot.bin にはイメージヘッダーテーブルとパーティションヘッダーテーブルがあり、余分なテーブルはパディングされていません。何も指定されていない場合、または -padimageheader=1 の場合、イメージヘッダーテーブルおよびパーティションヘッダーテーブルの合計が最大数のパーティションにパディングされます。

引数• 1: ヘッダーテーブルを最大数のパーティションにパディングする。これがデフォルト値です。• 0: ヘッダーテーブルをパディングしない。イメージヘッダーまたはパーティションヘッダーの長さ• zynq: 最大数のパーティション - 14 パーティション• zynqmp: 最大数のパーティション - 32 パーティション

process_bitstream構文-process_bitstream <bin|mcs>

説明BIF からのビットストリームのみを処理し、MCS ファイルまたは BIN ファイルとして出力します。たとえば、BIF ファイルのビットストリームに暗号化を選択した場合、出力は暗号化されたビットストリームとなります。

引数• bin: BIN フォーマットでの出力。• mcs: MCS フォーマットでの出力。戻り値生成される出力は、BIN フォーマットまたは MCS フォーマットのビットストリームで、ヘッダーが添付されていない処理済みファイルです。





spksignature構文bootgen -image test.bif -w on -o boot.bin -spksignature spksignfile.txt

説明このオプションは、SPK 署名ファイルの生成に使用します。これは、spkfile および pskfile が BIF で指定されている場合にのみ使用する必要があります。SPK 署名ファイル (spksignfile.txt) が生成されます。

オプション生成する署名ファイルの名前を指定します。

split構文bootgen -arch zynq -image test.bif -split bin

説明このオプションは、ヘッダーを含む各データパーティションを MCS または BIN フォーマットの新しいファイルとして出力します。

出力• 出力ファイルは次のとおりです。• ブートヘッダー + イメージヘッダー + パーティションヘッダー + Fsbl.elf

• Partition1.bit

• Partition2.elf

例the_ROM_image: { [bootloader] Fsbl.elf Partition1.bit Partition2.elf }





w構文bootgen -image test.bif -w on -o boot.binor bootgen -image test.bif -w -o boot.bin

説明このオプションは、既存のファイルを上書きするかどうかを指定します。boot.bin ファイルが既にパスに存在する場合は上書きされます。-w on オプションと -w オプションは同じように扱われます。-w オプションが指定されていない場合、ファイルはデフォルトで上書きされません。

引数• on: 引数ありの -w on コマンドまたは引数なしの -w で指定します。これがデフォルト値です。• off: 既存ファイルを上書きしないよう指定します。

zynqmpes1構文bootgen -arch zynqmp -image test.bif -o boot.bin -zynqmpes1

説明生成されたイメージを ES1 (1.0) で使用することを指定します。このオプションは、認証イメージを生成する場合にのみ影響をおよぼします。それ以外は無視されます。デフォルトのパディング方式は、ES2 (2.0) 以降が対象です。

初期化ペアおよび INIT ファイルの属性について初期化ペアを使用すると、MIO マルチプレクサーおよびフラッシュクロックのプロセッサシステム (PS) レジスタの初期化が容易になります。これにより、FSBL イメージを OCM にコピーする前、または XIP (eXecute in place) でフラッシュから実行する前に MIO マルチプレクサーを完全にコンフィギュレーションでき、フラッシュデバイスのクロックを帯域幅が最大となるように設定できます。ブートイメージヘッダーの固定部分の最後に 256 の初期化ペアがあります。1 つのペアは 32 ビットのアドレス値と 32 ビットのデータ値で構成されるため、初期化ペアはこれに従って指定されます。初期化が実行されない場合、アドレス値はすべて 0xFFFFFFFF となり、データ値はすべて 0x00000000 となります。これらの初期化ペアは、デフォルトでファイル拡張子が .int のテキストファイルで設定されますが、拡張子は変更できます。このファイルは、ファイル名の前に [init] ファイル属性を使用することによって、BIF 内で INIT ファイルとして認識されます。データフォーマットでは、動作指示子の後に次の情報が続きます。





• アドレス値• = 文字• データ値ライン (行) は、セミコロン (;) で終わります。次に示す例は、1 つの .set. operation directive; です。.set. 0xE0000018 = 0x00000411; // This is the 9600 uart setting.

Bootgen は、最大で 256 ペアまで、INT ファイルからのブートヘッダー初期化データを埋めていきます。bootROMが実行されると、アドレス値を参照します。その値が 0xFFFFFFFF でなければ、bootROM はアドレス値に続く次の32 ビット値を使用してアドレスの値を書き込みます。bootROM は、アドレス値が 0xFFFFFFFF になるまで、または 256 番目の初期化ペアに到達するまで、初期化ペアを順に設定し続けます。Bootgen では、次に示す演算子を含む式の評価 (優先を強調するネストされたかっこを含む) を実行できます。* = multiply/ = divide% = modan address valueulo divide+ = addition- = subtraction~ = negation>> = shift right<< = shift left& = binary and = binary or^ = binary nor

数値は 16 進数 (0x)、8 進数 (0o)、または 10 進数が可能です。数表現は、128 ビットの固定小数点整数として保持されます。読みやすいように、表現演算子の前後にスペースを入れることができます。





付録 D

Bootgen ユーティリティbootgen_utility は、Bootgen によって生成されたブートイメージの内容をヒトが読めるログファイルにダンプするツールです。これは、ブートイメージのさまざまなヘッダーテーブルの内容をデバッグおよび理解するのに役立ちます。ユーティリティは、次のファイルを出力として生成します。• すべてのヘッダーテーブルのダンプ。• レジスタ init テーブルのダンプ。• 個々のパーティションのダンプ。注記: パーティションが暗号化されている場合、ダンプは暗号化されたパーティションとなり、復号化されたパーティションとはなりません。使用法:

bootgen_utility -arch <zynq | zynqmp> -bin <binary input file name> -out <output text file>

例:

bootgen_utility -arch zynqmp -bin boot.bin -out info.txt

サンプルの出力ファイルは、次のようになります。

付録 D: Bootgen ユーティリティ




図 24: 出力例

付録 D: Bootgen ユーティリティ




付録 E

その他のリソースおよび法的通知

Documentation Navigator およびデザインハブザイリンクス Documentation Navigator (DocNav) では、ザイリンクスの資料、ビデオ、サポートリソースにアクセスでき、特定の情報を取得するためにフィルター機能や検索機能を利用できます。DocNav を開くには、次のいずれかを実行します。• Vivado® IDE で [Help] → [Documentation and Tutorials] をクリックします。• Windows で [スタート] → [すべてのプログラム] → [Xilinx Design Tools] → [DocNav] をクリックします。• Linux コマンドプロンプトに「docnav」と入力します。ザイリンクスデザインハブには、資料やビデオへのリンクがデザインタスクおよびトピックごとにまとめられており、これらを参照することでキーコンセプトを学び、よくある質問 (FAQ) を参考に問題を解決できます。デザインハブにアクセスするには、次のいずれかを実行します。• DocNav で [Design Hub View] タブをクリックします。• ザイリンクスウェブサイトでデザインハブページを参照します。注記: DocNav の詳細は、ザイリンクスウェブサイトの Documentation Navigator ページを参照してください。注意: DocNav からは、日本語版は参照できません。ウェブサイトのデザインハブページをご利用ください。

ザイリンクスリソースアンサー、資料、ダウンロード、フォーラムなどのサポートリソースは、ザイリンクスサポートサイトを参照してください。

Bootgen リソースBootgen の資料およびリソース次に示すドキュメントは、Bootgen プロセスをサポートするプロセスに関する補足情報を提供します。• Zynq®-7000 SoC:

付録 E: その他のリソースおよび法的通知


https://japan.xilinx.com/cgi-bin/docs/ndoc?t=design+hubs

https://japan.xilinx.com/cgi-bin/docs/rdoc?t=docnav

https://japan.xilinx.com/support



○ 『Zynq-7000 SoC ソフトウェア開発者向けガイド』 (UG821: 英語版、日本語版)

○ 『Zynq-7000 SoC テクニカルリファレンスマニュアル』 (UG585: 英語版、日本語版)

• Zynq® UltraScale+™ MPSoC:

○ 『Zynq UltraScale+ MPSoC: ソフトウェア開発者向けガイド』 (UG1137: 英語版、日本語版)

○ 『Zynq UltraScale+ デバイステクニカルリファレンスマニュアル』 (UG1085: 英語版、日本語版)

○ ザイリンクス Zynq UltraScale+ MPSoC ソリューションセンター: http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

Bootgen のその他の資料およびリソース• 『Zynq-7000 SoC のセキュアブートスタートアップガイド』 (UG1025)

• 『ザイリンクスソフトウェアコマンドラインツール (XSCT) リファレンスガイド』 (UG1208)

• 『Zynq UltraScale+ MPSoC: エンベデッドデザインチュートリアル』 (UG1209: 英語版、日本語版)

• 『Zynq-7000 SoC のセキュアブート』 (XAPP1175)

• 『Zynq-7000 SoC システムメモリのランタイムインテグリティと認証チェック』 (XAPP1225)

• 『BBRAM および eFUSE のプログラミング』 (XAPP1319)

お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ) に開示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適用される法律が許容する最大限の範囲で、(1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供され、ザイリンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれらに限られません)、すべての保証および条件を負わない (否認する) ものとします。また、(2) ザイリンクスは、本情報 (貴殿または貴社による本情報の使用を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、直接、間接、特別、付随的、結果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、その他あらゆる種類の損失や損害を含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であったり、ザイリンクスがそれらの可能性について助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれるいかなる誤りも訂正する義務を負わず、本情報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事前の書面による同意のない限り、貴殿または貴社は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製品は、ザイリンクスの限定的保証の諸条件に従うこととなるので、https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。IP コアは、ザイリンクスが貴殿または貴社に付与したライセンスに含まれる保証と補助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、または、フェイルセーフの動作を要求するアプリケーションに使用するために、設計されたり意図されたりしていません。そのような重大なアプリケーションにザイリンクスの製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。



https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug821-zynq-7000-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug585-Zynq-7000-TRM.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1137-zynq-ultrascale-mpsoc-swdev.pdf

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=j_ug1137-zynq-ultrascale-mpsoc-swdev.pdf



http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

http://www.wiki.xilinx.com/Solution+ZynqMP+PL+Programming

https://www.xilinx.com/cgi-bin/docs/ndoc?t=user_guides;d=ug1025-zynq-secure-boot-gsg.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=2018.3;d=ug1208-xsct-reference-guide.pdf

https://www.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1209-embedded-design-tutorial.pdf

https://japan.xilinx.com/cgi-bin/docs/rdoc?v=latest;d=ug1209-embedded-design-tutorial.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp1175_zynq_secure_boot.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp1225-rtic.pdf

https://www.xilinx.com/support/documentation/application_notes/xapp1319-zynq-usp-prog-nvm.pdf

https://japan.xilinx.com/legal.htm#tos

https://japan.xilinx.com/legal.htm#tos



自動車用のアプリケーションの免責条項オートモーティブ製品 (製品番号に「XA」が含まれる) は、ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性の機能 (「セーフティ設計」) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション (「セーフティアプリケーション」) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用前または提供前に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品を使用するリスクはすべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

著作権情報© Copyright 2018 Xilinx, Inc. Xilinx、Xilinx のロゴ、Alveo、Artix、ISE、Kintex、Spartan、Versal、Virtex、Vivado、Zynq、およびこの文書に含まれるその他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。OpenCL および OpenCL のロゴは Apple Inc. の商標であり、Khronos による許可を受けて使用されています。HDMI、HDMI のロゴ、および High-Definition Multimedia Interface は、HDMI Licensing LLC の商標です。 AMBA、AMBA Designer、Arm、ARM1176JZ-S、CoreSight、Cortex、PrimeCell、Mali、および MPCore は、EU およびその他各国の Arm Limited 社の商標です。すべてのその他の商標は、それぞれの保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、[email protected] まで、または各ページの右下にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。フィードバックは日本語で入力可能です。いただきましたご意見を参考に早急に対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじめご了承ください。



mailto:[email protected]



この資料は表記のバージョンの英語版を翻訳したもので、内 …...が hsm...

Documents