zynq ultrascale+ mpsoc での分離手法...zynq ultrascale+ mpsoc apu は arm® v8...

XAPP1320 (v3.0) 2020 年 4 月 30 日 1japan.xilinx.com

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

概要

Zynq® UltraScale+™ MPSoC は複数のプロセッシングユニットを提供しており、 4 つの Cortex™-A53 コア、 2 つの Cortex-R5 コア、プラットフォーム管理ユニット (PMU)、コンフィギュレーションセキュリティユニット (CSU)、プログラマブルロジック (PL) 内のユーザー指定数の MicroBlaze™ プロセッサが含まれています。複数のソフトウェアチームがシステム開発に従事している場合、これらのプロセッシングユニットが互いに干渉する可能性があります。この潜在的な干渉を防ぐには分離が必要です。セキュリティおよび機能安全アプリケーションではその性質上、分離が必要条件となります。

Zynq UltraScale+ MPSoC は、ザイリンクスメモリ保護ユニット (XMPU) とザイリンクスペリフェラル保護ユニット (XPPU) でメモリとペリフェラルのハードウェア保護を提供します。これらの保護ユニットは、 TrustZone (TZ) と Zynq UltraScale+ MPSoC のメモリ管理ユニット (MMU) およびシステムメモリ管理ユニット (SMMU) によって提供される分離を補完するものです。ここで説明する手法に従うことで、構造化された分離手法を使用してシステムを構築できます。このアプリケーションノートでは、 XMPU、 XPPU、 TZ を使用して Zynq UltraScale+ MPSoC システム内のサブシステムを分離する方法について説明します。

このアプリケーションノートのリファレンスデザインファイルは、ザイリンクスのウェブサイトからダウンロードできます。デザインファイルの詳細は、 47 ページの「デザインファイル」を参照してください。

注記: このアプリケーションノートではターゲットデバイスの例として MPSoC を使用しますが、ここで説明する分離手法は RFSoC デバイスにも適用できます。

はじめに

Zynq UltraScale+ MPSoC のデザインは複数のサブシステムを使用します。サブシステムには、 1 つ以上の中央演算処理装置 (CPU) またはその他のマスター、メモリ、ペリフェラルが含まれます。干渉が生じるのは、あるサブシステム内のマスターが、アクセスを想定されていないメモリ領域またはペリフェラルにアクセスしたときです。干渉の原因には、ソフトウェアのバグや悪意ある攻撃者の存在があります。

このアプリケーションノートでは、 Vivado® Design Suite の分離手法を用いて、分離サブシステムを使用するシステムを定義します。対象となるサブシステムは、アプリケーションプロセッシングユニット (APU)、リアルタイムプロセッシングユニット (RPU)、 PMU です。これらの手法の目標は、各サブシステムを、ほかのサブシステムとの間で無干渉 (FFI: Freedom From Inference) で実行できるようにすることです。保護ユニットと TZ を構成してサブシステムの分離を実現します。 Vivado Design Suite で生成されたシステムハードウェアをザイリンクスのソフトウェア開発キット (SDK) にエクスポートし、 SDK を使用してシステムソフトウェアを作成します。 SDK は、サブシステム上で実行される基本ソフトウェアだけでなく、保護ユニットと TZ の機能を制御および監視するアプリケーションの作成にも使用できます。このソフトウェアには、サブシステムの干渉に対するエラー対応を含めることができます。

システムを定義して実装したら、サブシステム間の相互通信を含む基本機能を検証する必要があります。サブシステム間の分離は、保護ユニットおよび TZ の分離機能を呼び出すフォールトを挿入することで検証できます。これには、システム設計者が定義した干渉へのエラー対応テストも含まれます。

アプリケーションノート : Zynq UltraScale+ MPSoCs

XAPP1320 (v3.0) 2020 年 4 月 30 日

Zynq UltraScale+ MPSoC での分離手法著者: Steven McNeil、 Peter Schillinger、 Aniket Kolarkar、Emmanuel Puillet、 Uwe Gertheinrich

https://japan.xilinx.com

https://japan.xilinx.com/cgi-bin/docs/ctdoc?cid=3acbfd52-f0c9-4182-892b-07be84336a5e;d=xapp1320-isolation-methods.zip

https://japan.xilinx.com/about/feedback/document-feedback.html?docType=Application_Notes&docId=XAPP1320&Title=Zynq%20UltraScale+%20MPSoC%20%26%2312391%3B%26%2312398%3B%26%2320998%3B%26%2338626%3B%26%2325163%3B%26%2327861%3B&releaseVersion=3.0&docPage=1

はじめに


このアプリケーションノートの対象はベアメタルシステムです。ここで説明する手法は、オペレーティングシステムを使用するシステムでの分離開発フレームワークを提供します。このアプリケーションノートでは、次の内容について説明しています。

• UltraScale MPSoC アーキテクチャ

• 分離ツール

• 分離リファレンスデザイン

ハードウェアおよびソフトウェアの要件

リファレンスデザインシステムのハードウェアおよびソフトウェア要件は、次のとおりです。

• ザイリンクス ZCU102 評価プラットフォーム

• USB Type-A/mini-B ケーブル 2 本 (UART、 JTAG 通信用)

• セキュアデジタル (SD) メモリカード

• ザイリンクス SDK 2019.1

• ザイリンクス Vivado Design Suite 2019.1

• シリアル通信ターミナルソフトウェア (Tera Term や PuTTY など)

• ウォームリスタートパッチが必要。詳細は、「ソフトウェアパッチ要件 (2019.1/2019.2)」を参照してください。



UltraScale MPSoC アーキテクチャ



このセクションでは、サブシステムを作成するために使用する UltraScale MPSoC アーキテクチャのハードウェアコンポーネントと、 FFI を実現するために使用する保護ユニットについて説明します。 Zynq UltraScale+ MPSoC はプロセッシングシステム (PS) とプログラマブルロジック (PL) で構成されています。また、 Zynq UltraScale+ MPSoC の領域は、フル電力ドメイン (FPD) 領域と低電力ドメイン (LPD) 領域などの電力ドメインによって定義されています。これらの電力ドメインには、ユーザーが電源を制御できるアイランドがあります。

また、ダブルデータレート (DDR) メモリ、オンチップメモリ (OCM)、密結合メモリ (TCM)、 PL 内の Advanced eXtensible Interface (AXI) ブロック RAM という 4 つの基本メモリ領域があります。メモリアクセスを制御するのは、メモリコントローラー、ダイレクトメモリアクセスコントローラー (DMAC)、メモリ管理ユニット (MMU)、 SMPU です。主に LPD 内にあるペリフェラルには、入力/出力ユニット (IOU) 内のデバイスと、ギガビットイーサネット MAC (GEM) などのその他のデバイスが含まれます。 GEM ペリフェラルと USB ペリフェラルは、マスターおよびスレーブのいずれの AXI デバイスとしても動作します。ペリフェラルには専用または共有でアクセスできますが、ペリフェラルを共有する場合、アクセスに対してアービトレーションを実行するかはユーザーが指定します。ペリフェラルの分離は XPPU を使用して提供されます。

Zynq UltraScale+ MPSoC 内の XMPU と XPPU の位置を図 1 に示します。合計 8 つの XMPU があり、 6 つは DDR へのトランザクションを保護し、 1 つは OCM を、残りの 1 つは FPD へのトランザクションを保護します。 XPPU は 1 つあり、LPD への入力位置にあります。





X-Ref Target - Figure 1

図 1: Zynq UltraScale+ のアーキテクチャ





システムメモリ管理ユニット (SMMU)、 AXI タイムアウトブロック (ATB)、 AXI 分離ブロック (AIB)、 TZ といった分離に必要なその他のコンポーネントがハードウェアで提供されています。 SMMU は、ダイレクトメモリアクセスコントローラー (DMAC) など、 CPU 以外のマスターのメモリ管理を提供します。 SMMU はハイパーバイザーと組み合わせて使用でき、同じメモリにアクセスする 2 つの異なるプロセッサ間を分離します。 ATB は、スレーブ応答のない AXI トランザクションが停止しないようにするもので、 AIB は、電源が切断された領域を電源切断ステートに移行します。分離において、未使用領域の電源切断は重要です。

いくつかのアクセス制御タイプを保護ユニットおよび TZ と組み合わせて使用する必要があります。 AXI トランザクションは、読み出しも書き込みもできますが、コードまたはデータ定数を含むセクションの書き込みはしないようにしてください。この分離要件に対応するため、 TZ とザイリンクス保護ユニット (XMPU および XPPU) を使用して、メモリ領域の読み出し /書き込みパーミッションを定義できます。

注記: 保護ユニットは分離を実現するためにマスター ID を使用しますが、 TZ は AXI AxProt[] を使用します。

Zynq UltraScale+ MPSoC APU は Arm® v8 アーキテクチャであり、 4 つの例外レベルをサポートしています。これらの例外レベルを使用して、アプリケーションレベルで権限を制御します (アプリケーションごとに個別の例外レベルがある)。Arm®v8 アーキテクチャの例外レベル (EL) は、 APU 上で実行されるアプリケーション専用であり、 RPU と PMU ではサポートされていません。ただし、 RPU は、例外レベルと概念の似た特権レベルの制御モードをサポートしています。詳細は、 https://developer.arm.com/docs/den0024/latest/fundamentals-of-armv8/changing-exception-levels#BEIJHGDA を参照してください。

未使用の領域およびアイランドの電源を切断することは、分離だけでなく、一般的なセキュリティおよび安全性対策にも有効な手段です。コンポーネントの電源を切断すれば、ほかのコンポーネントに干渉することはありません。図 2 に、Zynq UltraScale+ MPSoC の電源アイランドの概要を示します。


https://developer.arm.com/docs/den0024/latest/fundamentals-of-armv8/changing-exception-levels#BEIJHGDA





図 2: Zynq UltraScale+ MPSoC の電源ドメイン

VCU H.265, H.265

BRAM

PL SYSMON(SYSMONE4)

100 Gb Ethernet Interlaken

PL Con gura on

PL F

abric

PL Fabric

DSP, LUT, Clks

SerDes

HD I/O

eFUSE

RealTimeClock BBRAM

Oscillator

USB 0

USB 1

PS-GTR

1.2 to 1.5V

Ba ery Power Domain (BPD)

1.8VVCC_PSAUX good

1.8V to 3.3V VCCO_PSIO3




0.85 or 0.9V VCC_PSINTLP

1.2V VCC_PSPLL

0.85 or 0.9VVCC_PSINTFP

0.85V PS_MGTRAVCC

1.8V PS_MGTRAVTT

1.1 to 1.5V VCCO_PSDDR

1.8V VCC_PSDDR_PLL

VCCBRAM

VCCINT_VCU0.9VVCCADC1.8VVREFP1.25VVCCAUX1.8V

VCCO1.2 to 3.3V

0.85 or 0.9V

VCC_PSINTFP_DDR

PS SysMon

APLLVPLLDPLL

RPLLIOPLL

System

MIO 2MIO 1MIO 0

L2 CacheRAM

CPU 3

CPU 1

CPU 2

CPU 0

APU MPCore(SCU, GIC, CCI)

APU DebugRPU debug

Arm DAPPL debug

FPDDMA SATA

GPU pipelinePCIe

Interconnect and SLCRDisplayPort

GPU PP0

GPU PP1

Bank 0

Bank 1

Bank 2

Bank 3

TCM A0

TCM A1

TCM B0

TCM B1

OCM CtrlIOP

CSU PMU

IPI

Interconnect and SLCRLPD DMA

PS TAP

PLLs (x6) DDR Memory ControllerDDRIOB Po

rts

Ba ery

Power Supplies

PCAP

PCAP-LPD Isola on WallPL

-LPD

Isol

aon

Wal

l

VCC_PSAUX

Low Power Domain (LPD)

Full Power Domain (FPD)

PL Power Domain (PLPD)

PSIO {0:3} Power

High-Performance I/O PL Power Domains for Mul ple PL Units

PLL Power DomainsVCC_PSBATT

ETMGIC

RPU MPCore

PL-FPD Isola on Wall

PS Auxiliary Power Domain

GTH/GTY Supplies0.9 to 1.8V

1.8V VCC_PSADC

PCIe Gen3, 4

PL TAP

PMU so ware control

PHY

HP I/OVCCAUX_IO1.8V

VCCINT0.72, 0.85, or 0.9V PLPDVCCO1.0 to 1.8V

X22405-022719



分離ツール


分離ツール

Zynq UltraScale+ MPSoC には、分離デザインの開発に役立つさまざまなツールがあります。ここでは、主なツールについて説明します。

TrustZoneこのアプリケーションノートで説明する分離手法は、前提として保護ユニットおよび TZ を使用します。保護ユニットは、 AXI トランザクションの違反を検出することで分離を可能にします。ザイリンクスは、保護ユニットによる分離と TZ による分離を区別するために、それぞれトランザクション分離とステート分離という用語を使用しています。ステート分離はトランザクション分離よりも範囲が広く、サブシステム内のプロセッサ、 IP、メモリ、割り込みが、セキュア環境 (SW) 設定または非セキュア環境 (NSW) 設定に指定されます。サブシステムは SW ステートと NSW ステート間でコンテキスト切り替えを実行でき、これによりソフトウェアは複雑になりますが、デバイス使用率を高めることができます。

リファレンスデザインでは、 TZ の使用開始に不可欠なフレームワークを提供します。 TZ は複雑なので、その利点をすべて活用するには、 Trusted Execution Environment (TEE) の実行とザイリンクスのエコシステムパートナーによるサポートが一般に必要になります。詳細は、『Zynq UltraScale+ デバイスにおけるセキュリティ重視アプリケーションの分離』 (WP516) [参照 5] を参照してください。後述のリファレンスシステム (図 13 を参照) では、APU と APU のメモリおよびペリフェラルが TZ の非セキュアに割り当てられており、RPU と PMU の専用メモリおよびペリフェラルは TZ セキュアに割り当てられています。共有も可能ですが (通常は推奨されない)、セキュリティレベルをマスターのレベルと一致させる必要があります。たとえば、非セキュアマスターはセキュアのメモリやペリフェラルにはアクセスできませんが、セキュアマスターは、セキュアまたは非セキュアのいずれのメモリおよびペリフェラルにもアクセスできます。

一般的な Arm ユースケースでは、 TZ はハードウェア機能とソフトウェア機能を使用して分離を提供します。 SW および NSW の動作ステートは TZ によって定義されます。機能安全 (FS) アプリケーションでも、セキュリティアプリケーションと同様の分離要件が求められることがあります。 FS アプリケーションでは、セキュアおよび非セキュアの代わりに、それぞれセーフティクリティカルおよび非セーフティクリティカルという用語を使用します。これらの用語は類似しているため、セキュリティの文脈での用語 (セキュア環境と非セキュア環境) と揃えるために、簡潔にセーフティ環境と非セーフティ環境という用語を使用します。

ここでの目的は、セーフティクリティカル機能が非セーフティクリティカル機能によって損なわれないようにすることです。すべてではありませんが、一部の TZ システムでは、同一の CPU が SW と NSW 間で多重化されます。これは、リソースを効率的に使用できるためですが、通常は非常に複雑なコンテキスト切り替えが必要になります。ただし、トラステッドソフトウェアは一般に、スタンドアロンのボードサポートパッケージ (BSP) または SW 内の小規模なオペレーティングシステムを使用して、 SW 内で実行されます。 NSW ソフトウェアは機能豊富なオペレーティングシステム (多くの場合 Linux) で実行されるので、一般に攻撃対象の領域が広くなります。

例を挙げると、セキュアブート、セキュアファームウェアアップデート、キー管理、リセット制御、パワーマネージメントなどのクリティカルシステム機能が SW 内で実行されます。ステータス通知、必須ではないアナリティクス、パフォーマンス監視などの非クリティカルアプリケーションは、 NSW 内で Linux アプリケーションとして実行されます。TZ が提供する分離により、NSW 内のサイバー攻撃やソフトウェアバグが SW 内のコードまたはデータに影響する可能性が小限に抑えられます。

SW と NSW 間で実行されているコードのコンテキストを切り替えるのは複雑な処理なので、 1 つの CPU を SW で動作するように静的に設定し、 2 つ目の CPU は NSW で動作するように静的に設定する方が簡単です。 Zynq UltraScale+ MPSoC で提供される CPU の数を考慮すると、これは実行可能な選択肢です。たとえば、 R5-0 を SW 内で静的に動作させて、A53-0 は NSW 内で静的に動作させることができます。

TZ では、マスター、スレーブ、メモリは、 SW または NSW のいずれか一方で動作するように指定します。 SW 内のマスターは、 SW と NSW のいずれかに属するスレーブおよびメモリ (つまり、すべて) にもアクセスできます。 NSW 内のマスターは、 NSW に属するスレーブおよびメモリにのみアクセスできます。 NSW マスターが SW 内のペリフェラルまたはメモリにアクセスしようとしても許可されません。権限のないアクセスはスレーブによって拒否され、通常は SLVERR または DECERR 応答が返されます。



分離ツール


Zynq UltraScale+ MPSoC の TZ ハードウェア分離は、 AXI バス上の AxPROT[1] 信号をフィルタリングメカニズムとして使用して、アクセスが正当かとうかを判断します。これは、 PS 内の Arm Advanced High-performance Bus (AHB) と Advanced Peripheral Bus (APB) の両方で使用されています。 PL で使用される AXI Interconnect IP も AxPROT[1] をサポートしているため、 PL (1) では TZ による分離が比較的わかりやすくなっています。 MicroBlaze プロセッサおよび AXI IP は SW/NSW 動作ステートをサポートしていませんが、 AxPROT 信号を追加するカスタムロジックは比較的簡単です。

システム保護ユニット

「TrustZone」で詳細を説明したように、 Arm TrustZone テクノロジは、それぞれの AXI トランザクションにセキュリティレベルをタグ付けします。 XMPU と XPPU は、指定のアドレス範囲 (メモリとペリフェラル) にセキュア環境または非セキュア環境の TrustZone タグを割り当てることで、特定のシステムマスターが明示的にアクセス許可されていることを検証します。

XMPU

どのようなセキュアシステムや機能安全システムにとっても基本になるのがメモリの分離です。 XMPU により、ユーザー定義のメモリ領域を分割して、分離された特定のサブシステムに割り当てることができます。図 3 に XMPU の機能図を示します。

1. これらのビットを利用するコアのデザインは、ユーザーの責任で行います。


図 3: XMPU の機能

OCM Memory

OCM Switch

O set address +[BASE] register

APB

AXI

AddressPoison

AXI

FPD_XMPU

IOP Switch(to Peripheral Slaves)

FPD Switch

DECERR

DDR {0:5}

OriginalAddress

AxUser [Poison]signal

0: LPD AXI1: CCI AXI2: CCI AXI3: HP0, DisplayPort4: HP1, HP25: HP3, FPD_DMA

AXI

AttributePoison

AXI

OCM_XMPU andDDR_XMPUx

FPD_SinkIRQ

PSLVERRAPB

Poisoned Trans

or Invalid Reg

IRQ

PSLVERR Invalid Reg

Secure

BridgeAXI

Poisoned Transor Invalid Reg

APB

IRQ

PSLVERR Invalid Reg

Poisoned Transor Invalid Reg

X22784-042519



分離ツール


DDRC インターフェイスの入力に XMPU が 6 つあり、 OCM の入力に XMPU が 1 つあります。また、 FPD インターコネクトの入力には、 FPD コントローラー (SATA および PCIe®) を保護するために XMPU が 1 つあります。 Vivado ツールで生成される XMPU の設定は、 FSBL (第 1 段階ブートローダー ) にエクスポートされます。この FSBL で分離コンフィギュレーションレジスタが設定されます。追加の安全またはセキュリティチェックとして、これらのレジスタが読み出され、ステートが検証されます。 Zynq UltraScale+ MPSoC の機能安全ソフトウェアテストライブラリ (STL) の一部として、ザイリンクスは XMPU でのセルフテスト実行機能を提供しています。該当ライブラリは、機能安全ラウンジ (1) で提供されています。 XMPU が大 16 の領域を保護し、これらの領域は 1MB (DDR) または 4KB (OCM) の境界に揃えられています。それぞれの領域に対して、次の 2 つのチェックに基づいてメモリ保護が提供されます。

• トランザクションのアドレスが、 START_ADDR および END_ADDR で定義された領域内にあるかどうか。

• 受信したトランザクションのマスター ID がアクセス許可されているかどうか。

これらのレジスタは実行時に再設定できますが、安全システムやセキュアシステムでは推奨されていません。このようなシステムでは通常レジスタをロックする必要があります。この方法は XPPU に対して推奨されていますが、 XMPU には推奨されていません。 XMPU の設定をロックすることで、 XMPU からの割り込みがクリアされなくなる場合 (割り込みをクリアするレジスタもロックされる )、競合が発生します。この競合に起因して、リファレンスデザインには追加のサブシステムとして XPMU マスターとなる PMU が追加されています。この例では、 XMPU の設定はロックされておらず、PMU システムによる書き込みのみが許可されます。 PMU のフレームワークコードは割り込みハンドラーとして提供されます。このフレームワークでは、ユーザーのエラー応答要件に基づいて付加的なコードを追加できます。

注記: この競合は XMPU でのみ発生します。 XPPU は、割り込みのクリア機能に影響することなくロックできます。

START_ADDR、 END_ADDR、マスター ID (MID) の値はシステム設定内に定義されており、 XMPU レジスタ空間で読み出すことができます。 APU のマスター ID は 1 つですが、 RPU には次の 2 つの可能性があります。ロックステップモードで構成されている場合、 1 つの R5 マスター ID が使用されます。スプリットモードで構成されている場合、それぞれの R5 が独自のマスター ID を持ちます。アクセスがいずれかの保護条件に違反した場合、 XMPU がポイズン処理を適用することでこれを阻止します。

条件違反のトランザクションが試行された場合、 XMPU は AxUser[10] をアサートしますが、トランザクションはメモリコントローラーに渡されます。このメカニズムは属性によるポイズンと呼ばれ、トランザクションは XMPU 自体ではなくエンドポイントによってゲート制御されます。 DDR の場合、ユーザーが無効なトランザクションの処理方法を選択できます (いずれの方法も実際には許可しない)。トランザクションのポイズン処理には 2 番目の方法 (アドレスによる ) がありますが、 XMPU では属性によるポイズン処理を推奨します。

任意で XMPU から割り込みを生成することで、割り込みハンドラーにエラー対応を含めることができます。 XMPU の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 2] の「システム保護ユニット」の章を参照してください。

1. ザイリンクス機能安全ラウンジは、機能安全に関する資料とライブラリにアクセス可能な有料のリポジトリです。無料のランディン

グページは、 japan.xilinx.com/applications/industrial/functional-safety.html です。


https://japan.xilinx.com/applications/industrial/functional-safety.html


分離ツール


XPPU

XPPU は、ペリフェラル、メッセージバッファー、プロセッサ間割り込み (IPI)、通信、およびクワッド SPI フラッシュメモリを保護します。保護対象オブジェクトへのトラフィックがすべて通過する「チョークポイント」に実装すると、大の範囲に保護を適用できます。 XPPU は XMPU よりも細かいアドレス照合を使用するため、提供するアドレスア

パーチャの数が多くなります。また、 XMPU では、属性ではなくアドレスによるポイズン処理の使用は推奨されていない一方で、 XPPU で使用できるのはアドレスポイズン処理のみです。アドレスポイズン処理アプローチは、図 3 の左側に示されています。違反アクセスは、この目的のために予約された特定のメモリ領域に転送されます。マスター ID リストは、ペリフェラルへのアクセスが許可されたマスターを定義するために使用します。 20 個のうち 8 個のマスター ID が事前に定義されています。アパーチャパーミッションリスト (APL) には、マスターがアクセスできるペリフェラルアドレスに対するパーミッションが指定されています。パーミッションはマスター ID に基づきます。

図 4 に、 XPPU の機能図を示します。

マスター ID リストおよびアパーチャパーミッションリスト、パーミッションチェック、エラー処理の詳細は、『Zynq UltraScale+ MPSoC Processing System LogiCORE IP 製品ガイド』 (PG201) [参照 3] または『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 2] を参照してください。


図 4: XPPU の機能図

APBInterface

AxADDRAxUSERAxPROT

APB

ControlRegisters

Permission RAM

Address Decode

ADDR

IDPermission

CheckMatch

Data

Aperture Info

poison

Master ID Lookup

AXIAxADDRAxUSERAxPROT

AXI

X22786-042519



分離ツール


メモリ管理ユニットとメモリ保護ユニット

ザイリンクス保護ユニット以外に、Arm Cortex R5 システムと A53 システムには標準的なメモリ保護 (それぞれメモリ保護ユニットとメモリ管理ユニット ) が備わっているため、各プロセッサコンプレックス内で追加のアクセス制御を提供できます。ここでは要点のみを説明するため、詳細はそれぞれのテクニカルリファレンスマニュアルを参照してください。

Arm Cortex R5 のメモリ保護ユニット (MPU) では、 0、 12、または 16 のメモリ領域を作成できます。このため、各領域に個別の保護属性を設定できます。各領域はベースアドレスとサイズを指定して定義します。特定のアドレス空間を共有する必要がある場合は、領域のオーバーラップが可能です。また、 Armv8 アーキテクチャは 2 段階の変換をサポートしているため、ユーザーの OS とハイパーバイザーが独自の段階で変換を実行できます。

各 Arm Cortex A53 で、さらに細かい領域を定義できます。領域の数を指定するのではなく、領域の粒度 (4KB または 64KB) を指定します。アドレス領域ごとに独自の ID (ASID) が割り当てられます。

ザイリンクスのシステムメモリ管理ユニット (SMMU) は、プロセッサコアの MMU 機能を残りの Zynq UltraScale+ MPSoC アーキテクチャに拡張したもので、 6 つの変換バッファーユニット (TBU) を使用するその他のマスター /DMA 対応デバイスにも適用されます。使用に関する概略図を図 5 に示します。


図 5: SMMU システムロケーションの例

Cache Coherent Interconnect (CCI)

DDR Memory Subsystem

Cache Coherent Master 1

Cache Coherent Master n

Interconnect

Non-coherent Master 1

Non-coherent Master n

Interconnect

SMMU TBUStage 1

SMMU TBUStages 1

and 2

SMMU TBUStages 1

and 2

MMU Stage 1 and 2

L1 Cache

GPU Masters

MMU Stage 1Cache

Coherent Interconnect

L2 Cache

APU MPCoreCPU 0

CPU 1CPU 2

CPU 3CPUx

X22407-022719



分離ツール


AXI 分離ブロック

AXI 分離ブロック (AIB) の本来の目的は、電源切断に備えてマスターをスレーブから分離することですが、分離を拡張するためにも使用できます。 AXI ブロックはデバイスの PS 全体に分散しており、権限のないアクセスが試行された場合、望ましくないアクセスをブロックし、 SLVERR 応答を生成するように設定できます。 AIB の制御レジスタは XPPU によって保護できます。

例外レベル

Armv8 アーキテクチャでは 4 つの例外レベル (EL0 ～ EL3) を設定できるため、Arm A53 コンプレックス内で追加のアクセス制御を提供できます。 4 つの例外レベルは次のとおりです。

• EL0: も低いソフトウェア実行権限レベルで、特権なし実行レベルと呼ばれることもあります。ユーザーアプリケーションは通常このレベルで実行されます。

• EL1: 実際の「特権」を持つ初のレベルで、オペレーティングシステムは通常このレベルで実行されます。非セキュアステートに基本サポートを提供します。

• EL2: プロセッサ仮想化サポートが追加された、より高い特権レベルです。ハイパーバイザーは通常このレベルで実行されます。プロセッサ仮想化をサポートします。

• EL3: セキュアステートのサポートが追加されたも高い特権レベルです。セキュアモニターコードはこのレベルで実行されます。 Zynq UltraScale+ MPSoC の場合、これは Arm トラステッドファームウェア (ATF) です。

図 6 は、この構成 (と TrustZone) を図示したものです。


図 6: Armv8 の例外レベルと TrustZone

Non-secure State

App 0

AArch64 orAArch32

App n

AArch64 orAArch32

App 0

AArch64 orAArch32

App n

AArch64 orAArch32

Supervisor (Guest OS1)

AArch64 or AArch32

Supervisor (Guest OS2)

AArch64 or AArch32

Hypervisor Mode

AArch64 or AArch32

EL0

EL1

EL2

SVC

HVC

SMC

Secure Monitor Mode

Supervisor (Secure OS)

AArch64 or AArch32

App 0

AArch64 orAArch32

App n

AArch64 orAArch32

EL3

Secure State

X22408-022719



分離ツール


プロセッサ間の通信

分離されているシステムを含め、ほぼすべてのシステムで、何らかのサブシステム間通信が必要になります。たとえば、APU サブシステムは、 APU および RPU の両サブシステムで、サーバーとの間でデータを送受信するイーサネットインターフェイスをサポートします。 RPU サブシステムでログファイルを生成して APU サブシステムに送信すると、イーサネットを使用してログファイルがサーバーに転送されます。同様に、サーバーが APU サブシステムのイーサネットを使用して RPU サブシステムにコマンドを送信すると、サブシステム間通信メカニズムを使用してコマンドが RPU サブシステムに送信されます。

Zynq UltraScale+ MPSoC は、 APU、 RPU、 PMU サブシステム間でのプロセッサ間通信をサポートするため、 IPI バッファーを提供しています。 APU、 RPU、 PMU サブシステム間でのデータ交換には、 32 バイトの要求および応答バッファーが使用されます。リファレンスデザインで IPI を使用して、 APU および RPU サブシステム間でプロセッサ間通信を使用する具体例を図 7 に示します。これは IPI を使用する一例にすぎず、通信は IPI システムのいずれの参加サブシステムからでも開始できます。 IPI の詳細は、『Zynq UltraScale+ MPSoC テクニカルリファレンスマニュアル』 (UG1085) [参照 2] を参照してください。

このメッセージ交換のプロトコルでは、要求側サブシステム (APU) が受信側サブシステム (RPU) への割り込みをトリガーします。割り込みをトリガーするサブシステムは、 IPI チャネルの要求バッファー内にデータを書き込みます。 RPU の割り込み受信マスターは、要求バッファーの内容を読み出します。割り込み受信マスターが割り込みをトリガーしたマスターに応答データを提供する必要がある場合、応答バッファーを使用します。応答バッファーは、トリガー側のマスター (APU) によって読み出されます。


図 7: IPI を使用したプロセッサ間通信

RPU Subsystem

A53 R5-0

APU Subsystem

Response

Request

Response

Request

WriteRead Write

Read

Write

Read

Read

Write

IPI Registers

X22421-030119



分離ツール


Zynq UltraScale+ MPSoC は、サブシステム間通信用に 11 個の IPI チャネルを提供しています。11 個のうちのチャネル 3 ～ 6 は PMU 専用で、残りはマスターとして設定可能です。サブシステム間通信はハードウェアでサポートされており、xipipsu デバイスドライバーを使用します。各チャネルが 6 つのレジスタを提供し、割り込みのトリガーとステータスのチェックに使用されます。図 8 に、 Vivado Design Suite でのプロセッサ間割り込みに対するハードウェアサポートを示します。このラボの目的上、デフォルト設定を使用します。


図 8: Vivado Design Suite の IPI 通信設定

X19460-030119



分離ツール


PMU による割り込みの処理

XMPU と XPPU は、メモリまたはペリフェラルのアクセス違反が発生したときに、オプションで割り込みを生成します。割り込みが APU GIC、 RPU GIC、 AXI INTC のいずれかに接続されるようにシステムを設定すると、 APU、 RPU、または PMU による割り込みハンドラーの実装が可能です。

割り込みハンドラーのエラー対応は、システム要件で定義されています。たとえば、エラー対応として、システム電源を切断してシステム再起動のための介入を要求するシステムが考えられます。また、可用性が一般的な要件になっているシステムでは、システム機能はそのまま維持するかもしれません。その場合、エラー対応としてエラーを記録し、計画メンテナンスの可能性をサーバーに通知した上で、運用を継続するでしょう。

図 9 に、 PMU FW のエラー処理コードを示します。表示されているファイルは xpfw_xpu.c で、 SDK の BSP ツリーにあります。メッセージ (後述) は、 XPfw_Xpu_IntrHandler 関数から出力されます。このハンドラーは、必要なエラー対応を実装するように変更できます。


図 9: PMU FW のエラー処理コード

X19463-062617



分離ツール


フォールト挿入/アプリケーションフォールトのエラー処理

機能安全システムとセキュリティシステムでは、安全機能やセキュリティ機能が有効かどうかをテストせずに機能を追加することはできません。機能性をテストする場合は、正常に実行できれば有効と判断されますが、セキュリティまたは安全関連の機能では、システムが機能することは何の証明にもなりません。これらの機能を確認できるのは、フォールトが発生した場合のみかもしれないからです。フォールトの発生を待つのは現実的ではないため、通常はシステムにフォールトを挿入する必要があります。このサンプルデザインでは、違反を試行して分離を証明する必要があります。

複数の分離領域間での分離を検証するため、フォールトを挿入するためのコードを作成します。このコードにより、 TZ で保護された XMPU および XPPU ゲートを介して、メモリやペリフェラルに権限のないアクセスが実行されるため、このアクセスがブロックされてシステムに通知が送信されることを確認します。 PMU コードに別のシンボルを追加して詳細エラーメッセージを送信できるようにしておき、アプリケーションコードに付加的なエラー処理ルーチンを追加すると、分離違反が発生してもコードの実行を継続できます。ただし、これらのシンボルはオプションであり、 UART へのエラーメッセージ送信でのみ使用されるため、必須の処理ではなく、実際には望ましくありません。

権限のない読み出しと書き込みを実行するアプリケーションの実行を継続するには、これに対処するエラーハンドラーの構築が不可欠です。これにより、フォールトが発生した場合にも突然終了するのではなく、アプリケーションの実行を継続できます。システムハンドラーの割り込み方法は、割り込み処理に対するシステム要件に従って開発者が決定する必要があります。このサンプルはデモ用のコードであり、実際のユーザーコードを配置するプレースホルダーとして使用できます。

APU ドメインで実行されるサンプルアプリケーションは、同期アボートとエラーアボートという 2 種類の割り込みを生成します。実際のエラータイプがどちらになるかは、対応するトランザクションタイプ (読み出しまたは書き込み) によって異なり、それぞれに固有のハンドラーが必要になります。エラータイプは、対応するトランザクションタイプが読み出しであるか、書き込みであるかによって異なります。エラータイプが 2 種類必要な理由は Arm アーキテクチャ自体によるもので、ザイリンクス固有の実装ではありません。図 10 に、両方の割り込み用のエラーハンドラーコードを示します。同期アボートの場合、コードでブール変数を設定して、メインルーチンにアボートの発生を知らせます。次に、命令を 1 つ進めて、ループが問題となる同じステートメントに戻らないようにします。エラーアボートの場合は、アボートの発生を記録するだけです。アプリケーションはこのブール変数の値によって、ステートメントが「通過」したか、「失敗」したかを判断します。図 11 に、カスタムハンドラーを登録するコードを示します。 RPU システムでも同様のハンドラーが生成されましたが、生成される割り込みタイプは 1 つのみであるため、必要なのは同期エラーハンドラーのみでした。これらのハンドラーはデモ用であり、実際の使用を想定されているものではありません。エラーの処理方法は、対象のシステムの要件に沿って開発者が決定する必要があります。


図 10: アプリケーションの割り込みハンドラー

X22388-022819



分離リファレンスデザイン



Zynq UltraScale+ MPSoC でシステムを開発する際の初の手順は、アーキテクチャ面での機能定義です。つまり、 APU、RPU、 PL で実行するタスクを定義します。ほとんどのシステムで、サブシステムを分離して干渉なしでタスクを実行可能にするという共通の要件があります。

サブシステム間で何らかの通信が要求されることはよくあります。これに対応しながらサブシステム間の分離を維持する一般的な方法として、プロセス間割り込み (IPI) と共有メモリの 2 つがあります。 IPI は共通のメッセージバッファーと統合割り込みシステムを使用するのに対し、共有メモリは 2 つのサブシステム間で共有されるメモリのパーティションを作成します。 IPI の場合、 Zynq UltraScale+ MPSoC アーキテクチャがメッセージ通知を処理しますが、共有メモリの場合はユーザーが同様の通知アーキテクチャを作成する必要があります。ユーザー要件によって、いずれの方法にもメリットがあります。

サブシステム間でリソースを共有する理由がある場合があります。わかりやすい例に、電源投入時にロードされるすべてのサブシステムのブートイメージが不揮発性メモリ (NVM) に格納されているデバイスコンフィギュレーションがあります。ほかにも、 DDR コントローラー (DDRC) があります。 AXI DDRC を PL に追加することは可能ですが、リソース使用量が増えるためコストが増加します。分離が強化されるのは事実ですが、追加した DDRC リソースの使用による信頼性への効果が不明確になります。

ZCU102 や UltraZed-EG などの開発ボードを使用する場合、各サブシステムが使用するリソースが制約を受ける可能性があります。多重化された I/O (MIO) とデバイスボードインターフェイスによって、カスタムボードでは存在しないリソース制約が課される場合があります。このリファレンスデザインは ZCU102 開発ボードをターゲットとしています。


図 11: アプリケーションの割り込みハンドラーの登録

X22389-022719





ソフトウェアパッチ要件 (2019.1/2019.2)2019.1 および 2019.2 では、ウォームリスタート機能が分離と競合するという問題が報告されています。 PMU はウォームリスタートをサポートする目的で FSBL を DDR にコピーしますが、これにより 2 つの重大な競合が発生します。

• このリファレンスデザインでは、 PMU が OCM を読み出す必要がありますが、 PMU には OCM のへアクセス権がありません。

• FSBL に対する認証または暗号化を使用した場合、セキュリティ違反が発生します。

° FSBL がチップ外部の DDR に暗号化なしでコピーされます。

° 整合性のために FSBL のハッシュがコピーされますが、このハッシュが外部の DDR にも格納されます。

詳細は、 AR73475 を参照してください。このラボでは次のパッチが必須です。

• 0001-sw_apps-zynqmp_fsbl-Fix-logic-in-writing-FSBL-runnin.patch

• 0002-sw_apps-zynqmp_pmufw-Make-FSBL-copy-as-user-option.patch

インストール後に、 xpfw_config.h ファイルを開き、 USE_DDR_FOR_APU_RESTART_VAL の値を (1) から (0) に変更します (図 12 を参照)。プロジェクトごとに変更することも可能ですが、 (デフォルトで有効になっている ) このオプションを無効にしなければ、ほとんどの分離システムで分離エラーが発生します。 PMU ファームウェアプロジェクト単位ではなく、パッチリポジトリで無効化することを推奨します。 xpfw_config.h ファイルは、 <local patch repository>/embeddedsw/lib/sw_apps/zynqmp_pmufw/src にあります。

注記: パッチのインストールの詳細は、アンサーレコード 72710 を参照してください。


図 12: 2019.1 パッチでの USE_DDR_FOR_APU_RESTART_VAL オプションの変更

X23827-041320


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

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




システムの概要

図 13 に、 3 つのサブシステムで構成されるリファレンスシステムを示します。このデザインでは、 APU サブシステムが非セキュアシステム (緑色) と見なされ、PMU および RPU サブシステムがセキュアシステム (赤色) と見なされています。セキュアマスターと共有される非セキュア領域は、緑色と赤色の両方で表示されています。

このリファレンスシステムでは、次のとおりに PS が分割されています。

• DDR は 3 つの領域にわかれています。 APU サブシステムがアドレス 0x0000_0000 ～ 0x01FF_FFFF を専有し、アドレス 0x6000_0000 ～ 0x600F_FFFF を RPU サブシステムと共有しています。領域 0x4000_0000 ～ 0x40FF_FFFF は RPU サブシステムが専有しています。

• OCM は 2 つの領域に分割されています。アドレス範囲 0xFFFC_0000 ～ 0xFFFC_0000 は RPU サブシステムが専有し、残りのアドレス (0xFFFF_0000 ～ 0xFFFF_FFFF) は APU サブシステムと RPU サブシステムが共有しています。

• R5 は R5_0_ATCM 領域全体を占有しています。

• APU サブシステムは TTC0 と SWDT0 を占有していますが、 GPIO は RPU サブシステムと共有し、 UART0 については PMU サブシステムと共有しています。 RPU サブシステムは TTC1、 SWDT1、 I2C1 を占有し、 UART1 を PMU サブシステムと共有しています。


図 13: 分離リファレンスデザイン

UART_0

TTC_0

GPIO

SDWT_0

UART_1

TTC_1

SDWT_1

I2C_1

PMU Subsystem

RPU SubsystemAPU Subsystem

OCMDDR

0x0000_0000

0x01FF_FFFF

0x4000_0000

0x40FF_FFFF

0x6000_0000

0x600F_FFFF

0xFFFC_0000

0xFFFF_0000

0xFFFF_FFFF

R5_0 ATCM

0xFFE0_0000

0xFFE0_FFFF

Secure Subsystem

Non-secure Subsystem

Non-secure Subsystem (shared with Secure Subsystem)

CRF_APBCRL_APB

RPUEFUSE

IOU_SLCR

X22375-042120





より詳細なアドレスマップを表 1 に示します。

表 1: システムアドレスマップ

APU サブシステム

A53-0 NSW

OCM 0xFFFF_0000 64KB NSW R/W

DDR_LOW 0x0000_0000 32MB NSW R/W


UART0 NSW R/W

GPIO NSW R/W

SWDT0 NSW R/W

TTC0 NSW R/W

RPU サブシステム

R5-0 SW

OCM 0xFFFC_0000 192KB SW R/W

OCM 0xFFFF_0000 64KB NSW R/W

DDR_LOW 0x4000_0000 16MB SW R/W


R5_0_ATCM_GLOBAL SW R/W

SWDT1 SW R/W

UART1 SW R/W

TTC1 SW R/W

I2C1 SW R/W

GPIO NSW R/W

CRF_APB SW R/W

CRL_APB SW R/W

RPU SW R/W

EFUSE SW R/W

IOU_SLCR SW R/W

PMU サブシステム

PMU SW

UART0 NSW R/W

UART1 SW R/W

CRF_APB SW R/W

DDR_XMPU0_CFG SW R/W






FPD_SLCR SW R/W





XMPU および XPPU を使用して分離したセキュアシステムと安全システムの場合、不適切なソフトウェアや攻撃者が設定を変更して意図した分離を無効にすることを防ぐため、この設定を保護することを推奨します。これには次の方法があります。

• psu_protection_lock を呼び出す。

• XMPU/XPPU ロックビットをセットする。

• FPD_XMPU 保護を使用する。

ただし、「XMPU」で説明した競合が発生するため、 XMPU のロックは推奨しません。リファレンスデザインで実証されているように、 PMU などのセキュアマスターに XMPU を追加する方が適切です。

ハードウェアプラットフォームの構築

UltraScale+ MPSoC ファミリでの分離の基本はハードウェアにあります。このため、分離システムを構築するための初の手順はハードウェアの設定になります。次に示す手順では、ハードウェアをセットアップして 3 つの分離サブシステムを作成し、 XMPU、 XPPU、 TrustZone ハードウェアを使用して各サブシステムを分離します。初の手順は、基盤となるベースハードウェアプラットフォームの作成です。

Vivado ツールを起動したら、 Quick Start ページで [Create Project] をクリックし、 New Project ウィザードを開きます。次の情報に基づいて、ウィザードの各画面で項目を選択します。

• [Create a New Vivado Project]

選択肢はありません。 [Next] をクリックします。

• [Project Name]

[Project name]: ps_isolation_lab

[Project location]: c:/temp/xapp1320_2019.1/ (この後は <your lab location> と示します)

[Create project subdirectory]: オンにします。

• [Project Type]

[Example Project] をオンにします。

• [Select Project Template]

[Base Zynq UltraScale+ MPSoC] を選択します。

• [Default Board or Part]

[Zynq UltraScale+ ZCU102 Evaluation Board] を選択します。

• [New Project Summary]

選択肢はありません。 [Finish] をクリックします。

FPD_XMPU_CFG SW R/W

LPD_XPPU SW R/W

CRL_APB SW R/W

EFUSE SW R/W

IOU_SLCR SW R/W

LPD_SLCR SW R/W

OCM_XMPU_CFG SW R/W

RPU SW R/W

表 1: システムアドレスマップ (続き)





図 14 のような画面が表示されます。

ベースハードウェアプラットフォームが生成されたので、分離を提供するために定義を調節します。

1. [Zynq UltraScale+ IP] (zynq_ultra_ps_e_0 インスタンス) をダブルクリックします。

2. 新たに表示されたポップアップウィンドウの Page Navigator で、 [Switch To Advanced Mode] をオンにします。

3. Page Navigator で [Isolation Configuration] をクリックします。

4. [Isolation Configuration] ページの上部で [Enable Isolation] をオンにします。


図 14: 初期の IP インテグレーター図

X22376-022819





Secure Subsystem はセキュアブートを目的としたベースラインサブシステムで、作業を開始するための基準としてツールによって作成されたものです。説明を簡単にするために、このリファレンスデザインでは独自システムを構築しますが、時間を節約するために Secure Subsystem を利用して作業を開始できます。ただし、 2019.1 と 2019.2 では、この名前を変更するオプションが提供されていません。今後のソフトウェアリリースで名前を変更できるようになる可能性があります。

5. Secure Subsystem を削除します。

6. 2 つの分離サブシステム (RPU と APU) を作成します。

a. ボタンをクリックし、 RPU という名前の新規サブシステムを追加します。

b. ボタンをクリックし、 APU という名前の新規サブシステムを追加します。

完了すると、ウィンドウは図 15 のようになります。

分離サブシステムをカスタマイズする前に、図 15 に示した 3 つのチェックボックスについて理解することが重要です。これらは分離システムに重大な影響を及ぼします。

[Enable Isolation]

分離を実現するためにも重要な機能です。このリファレンスデザインで分離設定を有効にするには、このチェックボックスをオンにする必要があります。

[Enable Secure Debug]

これにより、それぞれの分離サブシステムに特定のコンポーネントが追加されます。具体的には、 DAP コンポーネントと CoreSight コンポーネントがマスターとして追加されます。このオプションをオフにすると、すべてのセキュアサブシステムへの JTAG アクセスが禁止されます。このリファレンスデザインは、分離およびデバッグを使用するためのトレーニングガイドとしての利用が想定されているため、このオプションはデフォルトでオンになっています。ただし、実際のシステムでは、デバッグロジックおよびデバッグアクセスポイントの使用には注意が必要です。これらのコンポーネントは、デザイン内でもセキュアな (信頼できる ) サブシステムの制御下に置くことを推奨します。


図 15: [Re-customize IP] ウィンドウ: ベースの分離サブシステム

X22377-030119





[Lock Unused Memory]

このオプションをオンにすると、分離設定によって明示的に定義されていないすべてのメモリロケーション (メモリとペリフェラル) の使用が制限されます。セキュアシステムの場合、このオプションは通常オンにしますが、必ずしも明示的ではないシステム動作がある場合、このパラメーターにより影響を受ける可能性があります。たとえば、ブート後に認証されたイメージや暗号化イメージをロードする場合 (パーシャルビットファイル)、システムには CSU や eFuse、場合によっては BBRAM レジスタ空間へのアクセスが必要です。これらが、このアクションを実行するセキュアサブシステムに明示的に追加されていない場合、 [Lock Unused Memory] オプションをオンにするとアクセスがブロックされます。このリファレンスデザインでは、このオプションの使用をテストしておらず、オフになっていると想定しています。

ここで、各分離サブシステムにマスターを追加します。

1. [APU] を右クリックして [Add Master] をクリックし、 [APU] を検索/選択します。

2. [RPU] を右クリックして [Add Master] をクリックし、 [RPU0] を検索/選択します。

° デフォルトの [Secure] 設定はそのままにします。

各サブシステムにマスターを追加したので、次に、 APU サブシステムにスレーブコンポーネントを割り当てます。

1. スレーブペリフェラルを APU サブシステムに追加します。

a. [APU] を右クリックして [Add Slaves] をクリックし、 [GPIO] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。

注記: これは RPU サブシステムと共有されます。

b. [APU] を右クリックして [Add Slaves] をクリックし、 [SWDT0] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。

c. [APU] を右クリックして [Add Slaves] をクリックし、 [TTC0] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。

d. [APU] を右クリックして [Add Slaves] をクリックし、 [UART0] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。

2. スレーブメモリを APU サブシステムに追加します。

a. [APU] を右クリックして [Add Slaves] をクリックし、 [OCM] を検索/選択します。

- [Start Address]: 0xFFFF0000

- [Size]: 64KB

- [TZ Settings]: NonSecure


b. [APU] を右クリックして [Add Slaves] をクリックし、 [DDR_LOW] を検索/選択します。

- [Start Address]: 0x0

- [Size]: 32MB


c. [APU] を右クリックして [Add Slaves] をクリックし、 [DDR_LOW] を検索/選択します。


- [Size]: 1MB







APU サブシステムの入力を完了したので、次に、スレーブコンポーネントを RPU サブシステムに割り当てます。

注記: このサブシステムの構築中、初に追加した時点で、一部のリソースが赤色で表示される場合があります。これは一時的なセキュリティの競合によるもので、サブシステムをすべて定義すると解決します。構築が正しく完了していれば、競合 (赤色) は表示されません。

1. スレーブペリフェラルを RPU サブシステムに追加します。

a. [RPU] を右クリックして [Add Slaves] をクリックし、 [GPIO] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。

注記: これは APU サブシステムと共有されます。

b. [RPU] を右クリックして [Add Slaves] をクリックし、 [I2C1] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

c. [RPU] を右クリックして [Add Slaves] をクリックし、 [SWDT1] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

d. [RPU] を右クリックして [Add Slaves] をクリックし、 [TTC1] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

e. [RPU] を右クリックして [Add Slaves] をクリックし、 [UART1] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

2. スレーブレジスタを RPU サブシステムに追加します (FSBL が RPU で実行されるため必要)。

a. [RPU] を右クリックして [Add Slaves] をクリックし、 [CRF_APB] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

b. [RPU] を右クリックして [Add Slaves] をクリックし、 [CRL_APB] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

c. [RPU] を右クリックして [Add Slaves] をクリックし、 [EFUSE] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

d. [RPU] を右クリックして [Add Slaves] をクリックし、 [IOU_SLCR] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

e. [RPU] を右クリックして [Add Slaves] をクリックし、 [RPU] を検索/選択します。 [TZ Settings] の [Secure] を選択します。

3. スレーブメモリを RPU サブシステムに追加します。

a. [RPU] を右クリックして [Add Slaves] をクリックし、 [OCM] を検索/選択します。

- [Start Address]: 0xFFFC0000

- [Size]: 192KB

- [TZ Settings]: Secure

b. [RPU] を右クリックして [Add Slaves] をクリックし、 [OCM] を検索/選択します。

- [Start Address]: 0xFFFF0000

- [Size]: 64KB



c. [RPU] を右クリックして [Add Slaves] をクリックし、 [DDR_LOW] を検索/選択します。


- [Size]: 16MB

- [TZ Settings]: Secure

d. [RPU] を右クリックして [Add Slaves] をクリックし、 [DDR_LOW] を検索/選択します。


- [Size]: 1MB






e. [RPU] を右クリックして [Add Slaves] をクリックし、 [R5_0_ATCM_GLOBAL] を検索/選択します。

- [Start Address]: <デフォルト >

- [Size]: <デフォルト >- [TZ Settings]: Secure

この時点で、 APU サブシステムと RPU サブシステムの入力が完了しました。ただし、エラーメッセージが外部に届くようにするため、 PMU サブシステムを数か所変更する必要があります。

1. スレーブペリフェラルを PMU ファームウェアサブシステムに追加します。

a. [PMU Firmware] を右クリックして [Add Slaves] をクリックし、 [UART0] を検索/選択します。 [TZ Settings] の [NonSecure] はそのままにします。


b. [PMU Firmware] を右クリックして [Add Slaves] クリックし、 [UART1] を検索/選択します。 [TZ Settings] の [Secure] はそのままにします。


2. この時点で、 [Isolation Configuration] ページは図 16 のようになります。





3. [OK] をクリックします。


図 16: Re-customize IP ウィンドウ: PMU の完了

X22379-022619





Vivado ツールによって、サンプルデザイン内に AXI IP のアドレスマップが自動的に生成されます。ただし、分離制限のためにプラットフォームを変更したので、この IP をリマップする必要があります。

1. [Block Design] ウィンドウの [Address Editor] で、 [axi_bram_ctrl_0] と [axi_gpio_0] の両セグメントを同時に選択します。

a. 右クリックして、 [Unmap Segment] をクリックします。

2. [Address Editor] で、 [Data] セグメントを選択します。

a. 右クリックし、 [Auto Assign Address] をクリックします。

注記: PL ペリフェラルの axi_bram_ctrl_0 と axi_gpi_0 は保護メカニズムをサポートしておらず、 AXI マスターからアクセスできます。

プラットフォームデザインを作成したので、次に、デザインをインプリメントして、 SDK に必要なハードウェアファイルをすべて生成します。

1. Flow Navigator ウィンドウで、 [Generate Bitstream] をクリックし、 [Yes] をクリックします。

a. 要求された場合は、 [Save] をクリックします。

2. [Launch Runs] ポップアップウィンドウで [OK] をクリックします。

a. この処理は、実行するマシンの性能によって数分かかる場合があります。

3. [Bitstream Generation Completed] ポップアップウィンドウで [Cancel] をクリックします。インプリメントされたデザインを開く必要はありません。

次に、新しく作成されたハードウェアプラットフォームをエクスポートして、 SDK を起動します。

1. [File] → [Export] → [Export Hardware] をクリックして、ハードウェアプラットフォームをエクスポートします。

2. [Export Hardware] ポップアップウィンドウで [Include bitstream] をオンにし、 [OK] をクリックします。

a. デフォルトの [Local to Project] 設定はそのままにします。

3. [File] → [Launch SDK] をクリックします。

a. [Exported location] と [Workspace] の両方で、デフォルトの [Local to Project] をそのままにします。

b. [OK] をクリックします。

デモ用ソフトウェアの作成

このセクションでは、 SDK を使用して、前のセクションで作成した分離システム上で稼働するソフトウェアを作成する方法を説明します。前述の機能をテストするため、 5 つのソフトウェアプロジェクトを作成します。これらのプロジェクトとその機能を表 2 に示します。

このラボでは複数のプロジェクトを同時に実行するため、プロジェクトごとにリンカースクリプトを手動で変更する必要があります。変更しない場合、メモリ競合が発生します。ただし、このラボの目的上、リンカースクリプトとコードをインポートします (FSBL プロジェクトと PMU プロジェクトはデフォルト設定のままなので対象外)。

表 2: ソフトウェアプロジェクト

プロジェクト機能

pmu_firmware PMU ファームウェア: イベントハンドラー

r5_fsbl R5_0 で実行される FSBL

rpu_ipi R5_0 で実行されるプロセッサ間割り込みコード

rpu_fault_injection R5_0 で実行されるフォールト挿入コード

apu_ipi APU_0 で実行されるプロセッサ間割り込みコード

apu_fault_injection APU_0 で実行されるフォールト挿入コード





FSBL プロジェクトの作成

FSBL はブート時に実行され、 PS ソフトウェアプロジェクトと PL ビットストリーム (存在する場合) をロードします。このセクションでは、 FSBL プロジェクトの作成に必要な手順を説明します。

1. [File] → [New] → [Application Project] をクリックします。

a. [Project name]: r5_fsbl

b. [OS Platform]: <デフォルト >

c. [Hardware Platform]: <デフォルト >d. [Processor]: psu_cortexr5_0

e. [Language]: <デフォルト >

f. [Compiler]: <デフォルト >

g. [Hypervisor Guest]: <デフォルト >

h. [Board Support Package]: <デフォルト >

2. [Next] をクリックします。

a. [Available Templates]: Zynq MP FSBL

3. [Finish] をクリックします。

PMU プロジェクトの作成

次の理由により、 PMU ファームウェアプロジェクトを含める必要があります。

• すべのて MPSoC プロセッサシステムで、 PMU ファームウェアプロジェクトが必須である。

• XMPU 割り込みの問題があるため、独立したセキュアマスターが保護ユニット (XMPU および XPPU) を使用することが望ましい。


a. [Project name]: pmu_firmware


c. [Hardware Platform]: <デフォルト >d. [Processor]: psu_pmu_0






a. [Available Templates]: ZynqMP PMU Firmware


PMU が保護ユニットを所有しており、システムレベルのプライマリエラーハンドラーとなるため、 4 つのビルド変数を追加する必要があります。

• ENABLE_EM: PMU のエラーマネージャーを有効にします。

• ENABLE_SCHEDULER: ENABLE_EM を使用するための前提として必須です ( 『Zynq UltraScale+ MPSoC ソフトウェア開発者向けガイド』 (UG1137) [参照 4] の PMU ファームウェアのビルドフラグ表を参照)。

• XPU_INTR_DEBUG_PRINT_ENABLE: 拡張されたデバッグ出力情報。

• XPFW_DEBUG_DETAILED: 拡張されたデバッグ出力情報。

注記: 上記の変数は実際のシステムでは不要です。これらの目的は、外部へのメッセージ通知とより詳細なメッセージの追加のみであり、実際のシステムでは通常設定されません。





1. SDK の [Project Explorer] で [pmu_firmware] を右クリックし、 [C/C++ Build Settings] をクリックします。

2. [C/C++ Build] の下の [Settings] をクリックします。

3. MicroBlaze gcc compiler の下の [Symbols] をクリックします。

4. [Defined Symbols] ビューでアイコンをクリックします。

a. 「ENABLE_EM」と入力し、 [OK] をクリックします。


a. ENABLE_SCHEDULER と入力し、 [OK] をクリックします。


a. 「XPU_INTR_DEBUG_PRINT_ENABLE」と入力し、 [OK] をクリックします。


a. 「XPFW_DEBUG_DETAILED」と入力し、 [OK] をクリックします。

8. SDK の [Project Explorer] で [OK] をクリックします。

[Properties for pmu_firmware] ウィンドウは図 17 のようになります。


図 17: PMU のビルドシンボル

X23828-041320





APU プロセッサ間割り込みプロジェクトの作成

分離システムでも、サブシステム間での通信が必要になる場合があります。これを安全かつセキュアに実現する方法の 1 つが IPI システムの利用です。これを実証するために 2 つのプロジェクトを使用します。 1 つは APU サブシステム内で実行され、もう 1 つは RPU サブシステム内で実行されます。このプロジェクトのターゲットは APU サブシステムです。

実際のソースコードはラボで提供されるため、コードをインポートするための空のプロジェクトを作成します。


a. [Project name]: apu_ipi


c. [Hardware Platform]: <デフォルト >d. [Processor]: psu_cortexa53_0






a. [Available Templates]: Empty Application


空のプロジェクトを作成したので、提供されたコードをインポートします。

1. [Project Explorer] で、 [apu_ipi] を展開し、 [src] を選択します。

2. [src] を右クリックして [Import] をクリックします。

3. [Import] ウィンドウで [General] を展開し、 [File System] をクリックして [Next] をクリックします。

4. [Browse] ボタンを使用して <各自のラボロケーション>\software\c\ipiTest\apu に移動し、 [OK] をクリックします。

5. 左側のペインで [apu] をクリックし、右側のペインに表示されるファイルがすべて選択されていることを確認して、[Finish] をクリックします。ファイルを上書きするかどうかを尋ねるプロンプトが表示されたら、 [Yes] をクリックします。

RPU プロセッサ間割り込みプロジェクトの作成

分離システムでも、サブシステム間での通信が必要になる場合があります。これを安全かつセキュアに実現する方法の 1 つが IPI システムの利用です。これを実証するために 2 つのプロジェクトを使用します。 1 つは APU サブシステム内で実行され、もう 1 つは RPU サブシステム内で実行されます。このプロジェクトのターゲットは RPU サブシステムです。



a. [Project name]: rpu_ipi















1. [Project Explorer] で、 [rpu_ipi] を展開し、 [src] を選択します。



4. [Browse] ボタンを使用して <各自のラボロケーション>\software\c\ipiTest\rpu に移動し、 [OK] をクリックします。

5. 左側のペインで [rpu] をクリックし、右側のペインに表示されるファイルがすべて選択されていることを確認して、[Finish] をクリックします。ファイルを上書きするかどうかを尋ねるプロンプトが表示されたら、 [Yes] をクリックします。

APU フォールト挿入プロジェクトの作成

アプリケーションの安全性やセキュリティを確保する上で、分離システムをセットアップして想定どおり動作することを確認するだけでは不十分です。実行中のソフトウェアを使用した物理的なテストが必要です。デバッグモード (JTAG ブートなど) を使用した検証は初期システムの立ち上げには便利ですが、システムを全面的に検証または認証するには不十分です。このため、 APU サブシステムから各種メモリおよびペリフェラルへの読み出し /書き込みで権限が不足している場合にこのアクセスを阻止する機能を実証するためのベーステンプレートとして、アプリケーションが作成されています。現実のシステムでは、このテストの範囲はずっと網羅的なものになると考えられます。



a. [Project name]: apu_fault_injection


c. [Hardware Platform]: <デフォルト >d. [Processor]: psu_cortexa53_0









1. [Project Explorer] で、 [apu_fault_injection] を展開し、 [src] を選択します。



4. [Browse] ボタンを使用して <各自のラボロケーション>\software\c\faultInjectionTest\apu に移動し、[OK] をクリックします。

5. 左側のペインで [apu] をクリックし、右側のペインに表示されるファイルがすべて選択されていることを確認して、[Finish] をクリックします。ファイルを上書きするかどうかを尋ねるプロンプトが表示されたら、 [Yes] をクリックします。





RPU フォールト挿入プロジェクトの作成

アプリケーションの安全性やセキュリティを確保する上で、分離システムをセットアップして想定どおり動作することを確認するだけでは不十分です。実行中のソフトウェアを使用した物理的なテストが必要です。デバッグモード (JTAG ブートなど) を使用した検証は初期システムの立ち上げには便利ですが、システムを全面的に検証または認証するには不十分です。このため、 RPU サブシステムから各種メモリおよびペリフェラルへの読み出し /書き込みで権限が不足している場合にこのアクセスを阻止する機能を実証するためのベーステンプレートとして、アプリケーションが作成されています。現実のシステムでは、このテストの範囲はずっと網羅的なものになると考えられます。



a. [Project name]: rpu_fault_injection











1. [Project Explorer] で、 [rpu_fault_injection] を展開し、 [src] を選択します。



4. [Browse] ボタンを使用して <各自のラボロケーション>\software\c\faultInjectionTest\rpu に移動し、[OK] をクリックします。

5. 左側のペインで [rpu] をクリックし、右側のペインに表示されるファイルがすべて選択されていることを確認して、[Finish] をクリックします。ファイルを上書きするかどうかを尋ねるプロンプトが表示されたら、 [Yes] をクリックします。





アプリケーションの実行

ハードウェアプラットフォームと関連ソフトウェアアプリケーションの構築が完了したので、次に、ブートイメージを生成してデモ用ソフトウェアを実行します。

注記: プロジェクトをまだ構築していない場合、 [Project] → [Build All] をクリックし、ビルドが完了してから次の手順に進みます。

プロセッサ間割り込み

IPI 機能をテストするこのアプリケーションは、 2 つのシステム間で干渉を引き起こすことなく、 2 つの分離サブシステムが相互通信する方法を実証するために構築されたものです。このビルドには、 APU プロセッサと RPU プロセッサ上で同時に実行されるソフトウェアが含まれています。各アプリケーションが次の 2 つの重要機能を備えています。

• 一方のサブシステムにメッセージを送信する

• 一方のサブシステムから受信したメッセージを出力する

このシステムを構築するには、 5 つのパーティションを含む BIF ファイルを作成する必要があります。

• r5_fsbl: デバイスの分離の設定とその他すべてのパーティションのロード。

• pmu_firmware: エラーハンドラーおよびメッセンジャー。

• Base_Zynq_MPSoC_wrapper_hw_platform_0 (PL ビットストリーム): このシステムには実際の機能は含まれません。

• apu_ipi: A53_0 で実行されるアプリケーションで、 RPU サブシステムとの間でメッセージを送受信します。

• rpu_ipi: R5_0 で実行されるアプリケーションで、 APU サブシステムとの間でメッセージを送受信します。

注記: ここから先の手順では、 <ビルドパス> = <各自のラボロケーション>\xapp1320_2019.1\ps_isolation_lab.sdk とします。

1. [Xilinx] → [Create Boot Image] をクリックします。

a. [Architecture]: Zynq MP

b. [Create new BIF file] をオンにします。

c. [Output BIF file path]: <ビルドパス>\output.bif

d. [Output path]: <ビルドパス>\BOOT.bin

e. [Create Image] をクリックせずに、次の手順に進みます。

2. [Add] をクリックします。

a. [File path]: <ビルドパス>\r5_fsbl\Debug\r5_fsbl.elf

b. [Partition type]: bootloader

c. [Destination Device]: PS

d. [Destination CPU]: R5 Single



a. [File path]: <ビルドパス>\pmu_firmware\Debug\pmu_firmware.elf

b. [Partition type]: datafile

- オプション: pmu の選択も可能です (bootROM によるロード )。c. [Destination Device]: PS

d. [Destination CPU]: PMU







a. [File path]: <ビルドパス>\Base_Zynq_MPSoC_wrapper_hw_platform_0\Base_Zynq_MPSoC_wrapper.bit


c. [Destination Device]: PL



a. [File path]: <ビルドパス>\apu_ipi\Debug\apu_ipi.elf



d. [Destination CPU]: A53 0

e. [Exception Level]: EL0

f. [Enable Trust Zone]: オン



a. [File path]: <ビルドパス>\rpu_ipi\Debug\rpu_ipi.elf



d. [Destination CPU]: R5 0

11. [Create Boot Image] ウィンドウは図 18 のようになります。

12. [Create Image] をクリックします。


図 18: IPI システムの BIF の設定

X22381-042220





BOOT.bin ファイルを作成したので、開発ボードのブート用に SD カードにコピーします。

1. <ビルドパス>\BOOT.bin を SD カードにコピーします。

2. USB-UART ケーブルをボードの UART ポートに接続し、このポートにマップされていた COM ポートを確認します。

3. UART0 (APU) および UART1 (RPU) の出力を観察するため、シリアル通信ターミナルを 2 つセットアップします。

a. [Baud rate]: 115200

b. [Data]: 8-bit

c. [Parity]: None

d. [Stop]: 1 bit

4. ブートモードを SD に設定します (図 19 を参照)。a. MODE[3:0] > 1110 > ON-ON-ON-OFF

5. SD カードを挿入します。

6. ボードに電源を投入します。


図 19: ZCU102 ボードの設定

3

4

5X22382-022619





図 20 に、 IPI システムの出力を示します。

APU のフォールト挿入

それぞれのデモで、フォールト挿入は APU と RPU の 2 つのシステムに分割されます。初に構築されるシステムは APU で、その機能は次のとおりです。

• APU ドメイン内のメモリの非セキュア領域の読み出しと書き込み。

• APU ドメイン外部のメモリの非セキュア領域の読み出しと書き込み。

• メモリのセキュア領域の読み出しと書き込み (APU ドメインの外部)。

• メモリの未定義領域の読み出しと書き込み。

° このラボでは許可していますが、未定義領域は必要に応じて除外できます。除外するには、分離サブシステムを設定するときに、 [Isolation Configuration] ページで [Lock Unused Memory] をオンにします。

• APU ドメイン内の非セキュアペリフェラルの読み出し。

° ペリフェラルに書き込むことで望ましくない結果が生じることを避けるため、書き込みは意図的に省略されています。

• セキュアペリフェラルの読み出し (APU ドメインの外部)。

° ペリフェラルに書き込むことで望ましくない結果が生じることを避けるため、書き込みは意図的に省略されています。





• apu_fault_injection: A53_0 で実行されるアプリケーションで、システムの各種メモリおよびペリフェラルの読み出しと書き込みを実行します。


図 20: IPI システムの出力

X23829-041320





FSBL、 PMU、アプリケーションの間でメッセージが競合することを避けるため、 PMU が使用する UART を変更する必要があります。前述したように、 PMU は UART0 と UART1 の両方を使用できますが、 APU が UART0 に出力する必要があるため、 PMU の UART は UART1 に変更します。

1. [Project Explorer] で [pmu_firmware_bsp] を右クリックし、 [Board Support Package Settings] をクリックします。

2. [standalone] を選択します。

3. stdin と stdout の値を psu_uart_1 に変更します。それぞれのフィールドをクリックし、プルダウンメニューから [psu_uart_1] を選択します (図 21 を参照)。


次に、システムを構築します。

注記: ここから先の手順では、 <ビルドパス> = <各自のラボロケーション>\ps_isolation_lab\ps_isolation_lab.sdk とします。




















図 21: [Board Support Package Settings]

X22785-042519











a. [File path]: <ビルドパス>\apu_fault_injection\Debug\apu_fault_injection.elf



d. [Destination CPU]: A53 0

e. [Exception Level]: EL0

f. [Enable Trust Zone]: オン



11. [Create Image] をクリックします。作成済みの BIF/BIN ファイルを上書きするかどうかを尋ねられたら、 [OK] をクリックします。


図 22: APU フォールト挿入システムの BIF の設定

X22384-042220







2. UART0 (APU) および UART1 (PMU) の出力を観察するため、シリアル通信ターミナルを 2 つセットアップします。


b. [Data]: 8-bit

c. [Parity]: None

d. [Stop]: 1 bit






3

4

5X22382-022619





図 24 に、 APU フォールト挿入システムの出力を示します。

注記: 図 24 に表示された PMU エラーメッセージは、制限されたアドレスへの APU システムによるアクセス試行の「失敗」に相当します。

RPU のフォールト挿入

それぞれのデモで、フォールト挿入は APU と RPU の 2 つのシステムに分割されます。初に構築されたシステムは APU です。このセクションでは、次の機能を持つ RPU システムの構築方法を説明します。

• RPU ドメイン内のメモリの非セキュア領域の読み出しと書き込み。

• RPU ドメイン外部のメモリの非セキュア領域の読み出しと書き込み。

• メモリのセキュア領域の読み出しと書き込み。

• メモリの未定義領域の読み出しと書き込み。

° このラボでは許可していますが、未定義領域は、必要に応じて分離サブシステムの設定時に除外できます。

• RPU ドメイン内の非セキュアペリフェラルの読み出し。

° むやみにペリフェラルに書き込むことで望ましくない結果が生じることを避けるため、書き込みは意図的に省略されています。

• セキュアペリフェラルの読み出し (RPU ドメインの外部)。

° むやみにペリフェラルに書き込むことで望ましくない結果が生じることを避けるため、書き込みは意図的に省略されています。


図 24: APU フォールト挿入システムの出力

X23830-041320









• rpu_fault_injection: R5_0 で実行されるアプリケーションで、システムの各種メモリおよびペリフェラルの読み出しと書き込みを実行します。

FSBL、 PMU、アプリケーションの間でメッセージが競合することを避けるため、 PMU が使用する UART を変更する必要があります。前述したように、 PMU は UART0 と UART1 の両方を使用できますが、 RPU が UART1 に出力する必要があるので、 PMU の UART は UART0 に変更します。

1. [Project Explorer] で [pmu_firmware_bsp] を右クリックし、 [Board Support Package Settings] をクリックします。

2. [standalone] を選択します。

3. stdin と stdout の値を psu_uart_0 に変更します。それぞれのフィールドをクリックし、プルダウンメニューから [psu_uart_0] を選択します。


次に、システムを構築します。

注記: ここから先の手順では、 <ビルドパス> = <各自のラボロケーション>\ps_isolation_lab\ps_isolation_lab.sdk とします。





























a. [File path]: <ビルドパス>\rpu_fault_injection\Debug\rpu_fault_injection.elf



d. [Destination CPU]: R5 0



11. [Create Image] をクリックします。作成済みの BIF/BIN ファイルを上書きするかどうかを尋ねられたら、 [OK] をクリックします。


図 25: RPU フォールト挿入システムの BIF の設定

X22386-042220







2. UART0 (PMU) および UART1 (RPU) の出力を観察するため、シリアル通信ターミナルを 2 つセットアップします。


b. [Data]: 8-bit

c. [Parity]: None

d. [Stop]: 1 bit






3

4

5X22382-022619





図 27 に、 RPU フォールト挿入システムの出力を示します。

注記: 図 27 に表示された PMU エラーメッセージは、制限されたアドレスへの RPU システムによるアクセス試行の「失敗」に相当します。「失敗」メッセージは、アプリケーションエラーハンドラーの一部です。 PMU メッセージは、組み込みの PMU システムエラーハンドラーの一部です。


図 27: RPU フォールト挿入システムの出力

X23831-041320





セキュアブート

ここまで、リファレンスデザインの焦点は分離にのみ当てられていましたが、分離を使用するアプリケーションの多くで、デバイスのセキュアなブートが求められます。このようなアプリケーションでは、ブートイメージを使用する前に、その信頼性を検証する必要があります。 IP の機密性を維持する場合は、ブートイメージの暗号化が必要です。

セキュアブートに関しては専用のアプリケーションノートが提供されているため、ここでは詳しく説明しません。必要な変更はすべてリファレンスデザインの ZIP ファイルに含まれています。セキュアブートなしで構築されたものと同じブートイメージを生成する BIF、キー、スクリプトが含まれており、次の方法が示されています。

• RSA 4096 と SHA3 を署名に使用した認証の追加。

• AES-256 と Galois/Counter Mode (GCM) を使用した暗号化。

• オペレーションキーの使用 (適切なキー管理手法のため)。

• Physically Unclonable Function (PUF: 物理複製困難関数) を使用した、ブラック (暗号化) 形式でのユーザーの暗号化キーの格納。

次にサンプル BIF ファイルを示します。

//arch = zynqmp; split = false; format = BIN

boot_image:

{

// Authentication

[pskfile]..\..\..\..\..\keys\psk0.pem

[sskfile]..\..\..\..\..\keys\ssk0.pem

// Encryption

[keysrc_encryption]efuse_blk_key

[bh_key_iv]..\..\..\..\..\keys\black_iv.txt

// FSBL

[fsbl_config]shutter=0x01000005E, opt_key

[bootloader, authentication = rsa, ppk_select = 0, spk_select=spk-efuse, spk_id = 0x00, encryption = aes, aeskeyfile = ..\..\..\..\..\keys\RedAESkey.nky, destination_cpu = r5-0]..\..\..\r5_fsbl\Debug\r5_fsbl.elf

// PMU Firmware

[authentication = rsa, ppk_select = 0, spk_select=user-efuse, spk_id = 0x001, encryption = aes, aeskeyfile = ..\..\..\..\..\keys\pmuFW.nky, destination_cpu = pmu]..\..\..\pmu_firmware\Debug\pmu_firmware.elf

// PL Bitfile

[authentication = rsa, ppk_select = 0, spk_select=user-efuse, spk_id = 0x002, encryption = aes, aeskeyfile = ..\..\..\..\..\keys\pl_bitfile.nky, destination_device = pl]..\..\..\Base_Zynq_MPSoC_wrapper_hw_platform_0\Base_Zynq_MPSoC_wrapper.bit

// R5-0 Application

[authentication = rsa, ppk_select = 0, spk_select=user-efuse, spk_id = 0x003, encryption = aes, aeskeyfile = ..\..\..\..\..\keys\r50_hello.nky, destination_cpu = r5-0]..\..\..\rpu_ipi\Debug\rpu_ipi.elf

// A53-0 Application

[authentication = rsa, ppk_select = 0, spk_select=user-efuse, spk_id = 0x004, encryption = aes, aeskeyfile = ..\..\..\..\..\keys\a530_hello.nky, destination_cpu = a53-0]..\..\..\apu_ipi\Debug\apu_ipi.elf

}

セキュアブートを追加するためにリファレンスデザインを変更する必要はありません。変更するのは、終的な BOOT.BIN ファイルの生成に使用する BIF のみですが、次の準備が必要になります。

• RSA 認証および AES 暗号化用のキーセット (デバイスキーとオペレーションキー )。

• PUF をプロビジョニングしたデバイス。

• RSA キーをプロビジョニングしたデバイス。

• AES キーをプロビジョニングしたデバイス (BBRAM または EFUSE)。

ベースリファレンスデザインとセキュアブート用の変更に必要なすべてのファイルが含まれるディレクトリの情報は、付属の README.TXT ファイルを参照してください。





デザインファイル

このアプリケーションノートのリファレンスデザインファイルは、ザイリンクスのウェブサイトからダウンロードできます。

表 3 に、リファレンスデザインの詳細を示します。

表 3: リファレンスデザインの詳細

パラメーター説明

全般

開発者 Steven McNeil

ターゲットデバイス Zynq UltraScale+ MPSoCs

ソースコードの提供あり

ソースコードの形式 C

既存のザイリンクスアプリケーションノート / リファレンスデザイン、またはサードパーティからデザインへのコード /IP の使用

なし

コードのスタティック解析/MISRA C なし

シミュレーション

論理シミュレーションの実施 N/A

タイミングシミュレーションの実施 N/A

論理シミュレーションおよびタイミングシミュレーションでのテストベンチの利用

N/A

テストベンチの形式 N/A

使用したシミュレータ /バージョン N/A

SPICE/IBIS シミュレーションの実施 N/A

インプリメンテーション

使用した合成ツール/バージョン N/A

使用したインプリメンテーションツール/バージョン N/A

スタティックタイミング解析の実施 N/A

ハードウェア検証

ハードウェア検証の実施あり

使用したハードウェアプラットフォーム ZCU102 評価ボード


https://japan.xilinx.com/cgi-bin/docs/ctdoc?cid=3acbfd52-f0c9-4182-892b-07be84336a5e;d=xapp1320-isolation-methods.zip


まとめ


まとめ

Zynq UltraScale+ MPSoC に多数のプロセッサが存在する場合、設計者は、任意のプロセッサまたはマスター上で実行されるコードが、そのマスターのサブシステムに含まれていないメモリ領域やペリフェラルに対して干渉や破損を引き起こさないようにする必要があります。このアプリケーションノートでは、 XMPU、 XPPU、 TZ によって提供されるハードウェアおよびソフトウェアのメカニズムを使用して、サブシステムを分離する方法について説明しています。この機能は、小権限、ハイパーバイザー、 Trusted Execution Environment (TEE) などのその他の分離手法を補完します。

参考資料

注記: 日本語版のバージョンは、英語版より古い場合があります。

1. 『Zynq UltraScale+ MPSoC レジスタリファレンス』 (UG1087)

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

3. 『Zynq UltraScale+ MPSoC Processing System LogiCORE IP 製品ガイド』 (PG201: 英語版、日本語版)

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

5. 『Zynq UltraScale+ デバイスにおけるセキュリティ重視アプリケーションの分離』 (WP516)6. Arm TrustZone

改訂履歴

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

日付バージョン改訂内容

2017 年 7 月 26 日 1.0 初版

2019 年 6 月 21 日 2.0 新しいソフトウェアバージョンに合わせた更新とカスタマーフィードバックによる問題への対応。

2020 年 4 月 30 日 3.0 • 新しいソフトウェアバージョンに合わせた更新。

• セキュアブートおよびソフトウェアパッチセクションの追加。


https://japan.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-ultrascale-registers.html

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

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=zynq_ultra_ps_e;v=latest;d=pg201-zynq-ultrascale-plus-processing-system.pdf

https://japan.xilinx.com/cgi-bin/docs/ipdoc?c=zynq_ultra_ps_e;v=latest;d=j_pg201-zynq-ultrascale-plus-processing-system.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

https://japan.xilinx.com/cgi-bin/docs/ndoc?t=white_papers;d=wp516-security-apps.pdf

https://www.arm.com/products/security-on-arm/trustzone


お読みください: 重要な法的通知


お読みください: 重要な法的通知本通知に基づいて貴殿または貴社 (本通知の被通知者が個人の場合には「貴殿」、法人その他の団体の場合には「貴社」。以下同じ ) に開

示される情報 (以下「本情報」といいます) は、ザイリンクスの製品を選択および使用することのためにのみ提供されます。適用される

法律が許容する大限の範囲で、 (1) 本情報は「現状有姿」、およびすべて受領者の責任で (with all faults) という状態で提供され、ザイリ

ンクスは、本通知をもって、明示、黙示、法定を問わず (商品性、非侵害、特定目的適合性の保証を含みますがこれらに限られません)、すべての保証および条件を負わない (否認する ) ものとします。また、 (2) ザイリンクスは、本情報 (貴殿または貴社による本情報の使用

を含む) に関係し、起因し、関連する、いかなる種類・性質の損失または損害についても、責任を負わない (契約上、不法行為上 (過失の

場合を含む)、その他のいかなる責任の法理によるかを問わない) ものとし、当該損失または損害には、直接、間接、特別、付随的、結

果的な損失または損害 (第三者が起こした行為の結果被った、データ、利益、業務上の信用の損失、その他あらゆる種類の損失や損害を

含みます) が含まれるものとし、それは、たとえ当該損害や損失が合理的に予見可能であったり、ザイリンクスがそれらの可能性につい

て助言を受けていた場合であったとしても同様です。ザイリンクスは、本情報に含まれるいかなる誤りも訂正する義務を負わず、本情

報または製品仕様のアップデートを貴殿または貴社に知らせる義務も負いません。事前の書面による同意のない限り、貴殿または貴社

は本情報を再生産、変更、頒布、または公に展示してはなりません。一定の製品は、ザイリンクスの限定的保証の諸条件に従うことと

なるので、 https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。 IP コアは、ザイリンクスが貴殿

または貴社に付与したライセンスに含まれる保証と補助的条件に従うことになります。ザイリンクスの製品は、フェイルセーフとして、

または、フェイルセーフの動作を要求するアプリケーションに使用するために、設計されたり意図されたりしていません。そのような

重大なアプリケーションにザイリンクスの製品を使用する場合のリスクと責任は、貴殿または貴社が単独で負うものです。

https://japan.xilinx.com/legal.htm#tos で見られるザイリンクスの販売条件を参照してください。

自動車用のアプリケーションの免責条項

オートモーティブ製品 (製品番号に「XA」が含まれる ) は、 ISO 26262 自動車用機能安全規格に従った安全コンセプトまたは余剰性の機

能 ( 「セーフティ設計」 ) がない限り、エアバッグの展開における使用または車両の制御に影響するアプリケーション ( 「セーフティアプリケーション」 ) における使用は保証されていません。顧客は、製品を組み込むすべてのシステムについて、その使用前または提供前

に安全を目的として十分なテストを行うものとします。セーフティ設計なしにセーフティアプリケーションで製品を使用するリスクは

すべて顧客が負い、製品の責任の制限を規定する適用法令および規則にのみ従うものとします。

© Copyright 2017-2020 Xilinx, Inc. Xilinx、 Xilinx のロゴ、 Artix、 ISE、 Kintex、 Spartan、 Virtex、 Vivado、 Zynq、およびこの文書に含まれる

その他の指定されたブランドは、米国およびその他各国のザイリンクス社の商標です。 PCI、 PCIe、および PCI Express は PCI-SIG の商標

であり、ライセンスに基づいて使用されています。 AMBA、 AMBA Designer、 Arm、 ARM1176JZ-S、 CoreSight、 Cortex、 PrimeCell、Mali、および MPCore は、 EU およびその他各国の Arm Limited の商標です。すべてのその他の商標は、それぞれの保有者に帰属します。

この資料に関するフィードバックおよびリンクなどの問題につきましては、 [email protected] まで、または各ページの右下

にある [フィードバック送信] ボタンをクリックすると表示されるフォームからお知らせください。いただきましたご意見を参考に早急

に対応させていただきます。なお、このメールアドレスへのお問い合わせは受け付けておりません。あらかじめご了承ください。


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

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

mailto:[email protected]


zynq ultrascale+ mpsoc での 分離手法...zynq ultrascale+ mpsoc apu は arm® v8...

Documents

zynq ultrascale+ mpsoc での分離手法...zynq ultrascale+ mpsoc apu は arm® v8...