デバッグ支援ハイパーバイザとRaspberry pi 5でのAMP

Transcript

1. BitVisor Summit 14 @立命館大学 2026年3月9日 デバッグ支援ハイパーバイザと Raspberry Pi 5でのAMP 番匠夏希(東京科学大学?)
2. 自己紹介 番匠 夏希 詳細なプロフィール 東京科学大学 学士2年 SecHack365 '25 坂井ゼミ サイボウズ・ラボユース ‘25 セキュリティキャンプ 2024 全国大会 ハイパーバイザゼミ 沖縄、四国地方の1周間旅行の帰りです
3. OSのデバッグ支援ハイパーバイザ GDB Remote Serial Protocolに対応してGDBでのデバッグを 可能にしました。 Raspberry Pi 5でのAMPへの挑戦 LinuxとRTOSの同時動作を目指して
4. OSのデバッグ支援ハイパーバイザ GDB Remote Serial Protocolに対応してGDBでのデバッグを 可能にしました。
6. ユーザー側PC GDB/VSCode 一部の割り込みのみ注入 + 監視 HyprProbeの仕組み UART HyprProbe 割り込み コントローラー GDB メインコントローラー GDB Remote Serial Protocol デバッグ対象のOS MMU MMIOフィルタ 割り込み発生機器 Peripheral デバッグレジスタ DBGWCR/DBGBCR メモリ 実機ハードウェア OSアクセス時 フィルタリング
7. このHyprProbeは25年度のSecHack365の作品です ポスターはここから GDBとの接続の他にも 異常MMIO検知、異常IRQ/例外検知などの独自機能 を持っています
8. Raspberry Pi 5でのAMPへの挑戦 LinuxとRTOSの同時動作を目指して
9. Raspberry Pi 5 Cortex A57 現在行おうとしていること ハイパーバイザ Linux VGic 仮想割込みへ変換 RP1 Linuxからは RP1が見えない BCM2712 BCM2712の3コアをLinux、1コアをRTOSで利用する Thin Hypervisorにより、LinuxにRP1を見せないようにする PCIe 2.0 ✕ 4 Cortex A57 Cortex A57 Cortex A57 パススルー RTOS
10. Thin HypervisorをAMPで使う理由について 今回求めている要件 Linux側を全く改変したくない(dtbの改変のみ) Linuxのバージョン依存にはしたくない Linuxのmain streamでRP1の大規模な改変あり 　　　 (もっとPCIeとして扱いたいらしい?) RP1にあるデバイスをLinux/RTOSどっちもで使いたい 　 (カメラをLinuxで、PWMをRTOSで) RTOSには厳密なリアルタイム性は要求しない ページングやキャッシュでの誤差は無視する BCM2712からRP1へ送るときの遅延も無視( 1μsぐらい遅延があるらしい)
11. Thin HypervisorをAMPで使う理由について RP1にあるデバイス類をLinux/RTOSどっちもで使うためにはPCIeの初期化を どちらか片方で請け負う必要あり (PCIeのコネクション確立、inbound/outbound設定、MSI-X設定など) Linux側にはRP1を見せずに直接RP1の子デバイスを利用するようdtbを改変
12. Cortex A76 ✕ 4 GIC-400 (Gic v2) ④:IRQ/FIQ MSI-X Interrupt Peripheral ③:SPI RP1 割込みコントローラ ②:MSI/X PL011 UARTコントローラ ①: SPI Raspberry Pi 5から、GPIOのコントローラとしてRP1が追加された このため、RP1のGPIOからの割込みが複数のコントローラを経由するため難しくなっている RP1(GPIOコントローラ) BCM2712(Soc) PL011 UARTコントローラ ①: SPI GIC-400 (Gic v2) Raspberry Pi 5 Raspberry Pi 4 GIC-400 (Gic v2) Cortex A72 ✕ 4 ②:IRQ/FIQ 割込みがCPUに受理されるまでの仕組み Thin HypervisorをAMPで使う理由について
13. Thin HypervisorのAMPでの利用方法 RTOSはThin Hypervisorに統合してしまいEL2で動作させようかと考えている (例外レベルの変更により遅くなる可能性 + RTOS自体を監視する必要性は低い) Linuxに関しては、ある程度遅延しても構わない処理を担当するので、 RP1の設定部分(GPIO設定、PCIeの設定、MSI-X割込み設定)を触らせないようにしたい。 Linuxのvgicがいじられたときに、MSI-Xの設定等をそれに応じて行ってあげる、 RP1を抽象化するためのhypervisorを作成しようとしている dtbのRP1の子ノードのうち、Linux側で使いたいもの(カメラなど)をRaspberry Pi 4等と 同じくsoc直下に置くようにすれば良いと考えている。
14. Raspberry Pi 5 Cortex A57 現在行おうとしていること(再掲) ハイパーバイザ Linux VGic 仮想割込みへ変換 RP1 Linuxからは RP1が見えない BCM2712 BCM2712の3コアをLinux、1コアをRTOSで利用する Thin Hypervisorにより、LinuxにRP1を見せないようにする PCIe 2.0 ✕ 4 Cortex A57 Cortex A57 Cortex A57 パススルー RTOS
15. Raspberry Pi 5のI/O chipであるRP1はBCM2712(Soc)とPCIe 2.0 ✕ 4で接続されている このため、PCIeの初期化などの設定をまず最初に行う必要があるが めんどくさい + 今回の内容に直接関係せず非本質 config.txtのファームウェアが RP1をリセットせずに起動してくれる + UART0の初期設定を行ってくれる オプション(pciex4_reset=0, enable_rpi1_uart=1)を利用すれば良い 困ったこと: RP1のアドレスが公式と違う おまけ
16. 困ったこと: RP1のアドレスが公式と違う UART0を使うためには アドレス 0x1f_0003_0000を使えばいいとわかる 公式のchange logより
17. 困ったこと: RP1のアドレスが公式と違う UART0を使うためには アドレス 0x1f_0003_0000を使えばいいとわかる ✕
18. 困ったこと: RP1のアドレスが公式と違う どこかのファームウェアのアップデートでのタイミングでアドレスが 0x1f_0003_0000 → 0x1C_0003_0000 に変更されていた PeripheralのBARを読むことでわかった 結局PCIeの設定からは逃れられない