AI支援型リバースエンジニアリングを用いたThinkPad X61へのcoreboot移植

AI支援型リバースエンジニアリングがファームウェア移植を加速させる

大規模言語モデル（LLM）をリバースエンジニアリングのワークフローに統合することで、サポートされていないプラットフォームへのファームウェア移植に要する時間を、数ヶ月から数週間に短縮できる可能性があります。ThinkPad X61のケースでは、LLMを使用してベンダーのBIOSモジュールを分析し、初期化シーケンスを抽出しましたが、そのプロセスには、ハルシネーション（幻覚）やハードウェア固有のエラーを修正するために、依然として多大な人間の介入とドメイン知識が必要でした。

課題：ThinkPad X61の移植

ThinkPad X61は、GM965ノースブリッジとICH8サウスブリッジを使用しています。X200（GM45）のようなサポートされているプラットフォームと似ていますが、X61はDDR2のみであり、流出したドキュメントも存在しないため、corebootへの移植はリバースエンジニアリングが唯一の実行可能な手段となります。SerialICE（QEMUでファームウェアを実行し、IO/MMIOを実際のハードウェアに転送するツール）のようなツールを使用した以前の試みは、動作する移植版を作成することに失敗していました。

手法：従来のツールとLLMの組み合わせ

データ抽出とベースラインの確立

AIを利用する前に、開発者は標準的なcorebootツールを使用して、動作しているシステムから情報をダンプすることによって、既知の正常なベースラインを確立しました：

  • inteltool: PCI構成空間およびノースブリッジ/サウスブリッジのレジスタ概要に使用。
  • acpidump, acpixtract, and iasl: デバイス記述と電力管理を理解するために、ACPIテーブルをダンプおよびデコンパイルするために使用。
  • ectool: Embedded Controller (EC) のRAMおよび動作を分析するために使用。

AIエージェントの統合

Phoenix BIOSを分析するために、開発者は bios_extract を使用してイメージをモジュールに分割し、AIエージェント（Claude Opus 4.6）に特定のツールを提供しました：

  • ghidra-cli: raminitで使用されるIntel Memory Reference Code (MRC) のようなPE32モジュールを分析するために採用。Cスタイルのデコンパイルが最も効果的でした。
  • radare2: ファームウェアの16ビット・リアルモード部分に使用。

「Vibe Reverse Engineering」の現実

初期の結果は即座に得られるように見えましたが、開発者は、（LLMの出力のみに頼る）「vibe reverse engineering」（感覚的なリバースエンジニアリング）は、プロダクショングレードのファームウェアには不十分であると指摘しています。LLMは、開発者がX60やX200プラットフォームの経験に基づき、広範な「手助け」と誘導が必要でした。

プロセス中に必要となった主な修正事項は以下の通りです：

  • GPIO Muxing: X61がGPIO42上のSMBUS用のGPIO muxを持っていることを特定。これは、SPD対EEPROMの可視性に影響します。
  • Memory Specifications: メモリコントローラ・サポートをDDR2 533MT/sおよび666MT/sに修正（LLMは誤って666/800MT/sと提案しました）。
  • Register Access: 誤ったサイズのレジスタ読み取り/書き込み（例：16ビット・レジスタへの32ビット書き込み）を修正し、GMCH FSB周波数のソースをMCHBARレジスタに修正。
  • CAS Semantics: corebootのエンコーディングとMRCのエンコーディングにおけるCASの混同を解決。

ハードウェア・テストとフラッシング・ワークフロー

テストは、シリアル出力用のRS232 UARTコネクタを備えたドッキングステーションを使用して行われました。フラッシングは、基板の底面にあるSOIC8フラッシュチップにクリップを装着したCH341A SPIプログラマーを使用して行われました。使用されたフラッシング・コマンドは以下の通りです：

flashprog -p ch341a_spi --ifd -i bios -w build/coreboot.rom

アップストリーミングと品質保証

コードをアップストリームへ送る際、LLMが導入した、あるいは見落とした、いくつかの「自分のマシンでは動く」バグが明らかになりました。シニア・コントリビューターによる徹底的なレビューにより、以下の事項が識別されました：

  • Hallucinated Semantics: GM965 0xa00 MCHBAR範囲における、誤ったレジスタ名およびハルシネーションによるブロック・セマティクス。
  • Logic Errors: 誤しくインデックスされたタイミング・テーブルおよび、誤った意味を持つビットフィールド。
  • Hardcoded Values: X61固有の初期化ビットおよびデバイス・イネーブルが、一般的なチップセット・コードとして提示された。

ファームウェアにおけるより広範な影響

このプロジェクトは、クローズドソースのバイナリ・ファームウェアのリバースエンジニアリングが、より実現可能になっていることを示しています。開発者は、これが最終的にIntel FSP (Firmware Support Package) にも適用可能であると示唆しています。FSPはGhidraで分析可能な32ビットPEコードです。理解し、置き換えるための障壁が下がり続けているため、この変化は、シリコン・ベンダーがクローズド・バイナリのみのファームウェアに依存する動機を低減させる可能性があります。

コミュニティ・インサイト

コミュニティ内での議論は、X61のフォームファクタへの根強い人気と、LLMMが非専門的な開発者でも、以前は「不可能」とされていた移植プロジェクトに取り組めるようにする可能性をハイライトしています。あるユーザーは次のように述べています：

「理論上、特にLLMの能力が向上するにつれて、私のような馬鹿でも、サポートされていないプラットフォームにCorebootを移植できる可能性があるというのは、なんとも複雑な恩恵（mixed blessing）である。それは、おそらく、私がそのようなシナリオリオに遭遇することはないだろうから、おそらく、私が持っている最も良い手段だ。」

さらに、開発者は、Rustで書かれたcoreboot/u-bootの代替品である fstart へのX61の移植についても示唆しました。

Sources