Slide 1

Slide 1 text

BitVisor Summit 14 @立命館大学 2026年3月9日 デバッグ支援ハイパーバイザと Raspberry Pi 5でのAMP 番匠夏希(東京科学大学?)

Slide 2

Slide 2 text

自己紹介 番匠 夏希 詳細なプロフィール 東京科学大学 学士2年 SecHack365 '25 坂井ゼミ サイボウズ・ラボユース ‘25 セキュリティキャンプ 2024 全国大会 ハイパーバイザゼミ 沖縄、四国地方の1周間旅行の帰りです

Slide 3

Slide 3 text

OSのデバッグ支援ハイパーバイザ GDB Remote Serial Protocolに対応してGDBでのデバッグを 可能にしました。 Raspberry Pi 5でのAMPへの挑戦 LinuxとRTOSの同時動作を目指して

Slide 4

Slide 4 text

OSのデバッグ支援ハイパーバイザ GDB Remote Serial Protocolに対応してGDBでのデバッグを 可能にしました。

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

ユーザー側PC GDB/VSCode 一部の割り込みのみ注入 + 監視 HyprProbeの仕組み UART HyprProbe 割り込み コントローラー GDB メインコントローラー GDB Remote Serial Protocol デバッグ対象のOS MMU MMIOフィルタ 割り込み発生機器 Peripheral デバッグレジスタ DBGWCR/DBGBCR メモリ 実機ハードウェア OSアクセス時 フィルタリング

Slide 7

Slide 7 text

このHyprProbeは25年度のSecHack365の作品です ポスターはここから GDBとの接続の他にも 異常MMIO検知、異常IRQ/例外検知などの独自機能 を持っています

Slide 8

Slide 8 text

Raspberry Pi 5でのAMPへの挑戦 LinuxとRTOSの同時動作を目指して

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Thin HypervisorをAMPで使う理由について 今回求めている要件 Linux側を全く改変したくない(dtbの改変のみ) Linuxのバージョン依存にはしたくない Linuxのmain streamでRP1の大規模な改変あり     (もっとPCIeとして扱いたいらしい?) RP1にあるデバイスをLinux/RTOSどっちもで使いたい   (カメラをLinuxで、PWMをRTOSで) RTOSには厳密なリアルタイム性は要求しない ページングやキャッシュでの誤差は無視する BCM2712からRP1へ送るときの遅延も無視( 1μsぐらい遅延があるらしい)

Slide 11

Slide 11 text

Thin HypervisorをAMPで使う理由について RP1にあるデバイス類をLinux/RTOSどっちもで使うためにはPCIeの初期化を どちらか片方で請け負う必要あり (PCIeのコネクション確立、inbound/outbound設定、MSI-X設定など) Linux側にはRP1を見せずに直接RP1の子デバイスを利用するようdtbを改変

Slide 12

Slide 12 text

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で使う理由について

Slide 13

Slide 13 text

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直下に置くようにすれば良いと考えている。

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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のアドレスが公式と違う おまけ

Slide 16

Slide 16 text

困ったこと: RP1のアドレスが公式と違う UART0を使うためには アドレス 0x1f_0003_0000を使えばいいとわかる 公式のchange logより

Slide 17

Slide 17 text

困ったこと: RP1のアドレスが公式と違う UART0を使うためには アドレス 0x1f_0003_0000を使えばいいとわかる ✕

Slide 18

Slide 18 text

困ったこと: RP1のアドレスが公式と違う どこかのファームウェアのアップデートでのタイミングでアドレスが 0x1f_0003_0000 → 0x1C_0003_0000 に変更されていた PeripheralのBARを読むことでわかった 結局PCIeの設定からは逃れられない