信頼できる自由／オープンソースのLinux対応64ビットRISC-Vセルフホスティングコンピュータ
(contrib.andrew.cmu.edu)- 目標は、システム全体の動作を公開されたHDLとソフトウェアソースから追跡でき、そのシステム上でツールチェーンまで再ビルド・実行されるセルフホスティングの自由／オープンソーススタックを作ること
- 自前でASICを製造することはできないため、ハードウェアはFPGA上に載せ、ビットストリーム生成とプログラミングも自由／オープンソースのツールで処理する必要がある
- FPGAの利用は、ファウンドリが実際の用途や機密性の高いビット配置を把握しにくくするため、製造段階の攻撃をDoSレベルに制限できるという考え方
- 規則的な格子構造を持つFPGAは、化学的除去やTEMイメージングのような破壊的な視覚検査を専用ASICより現実的に行いやすい
- 残る信頼性の問題は、HDL・ソフトウェア・コンパイラ・ツールチェーンをすべて公開ソースからビルド可能にし、検証範囲を監査可能なソースへと絞り込むことにある
信頼できるコンピュータのための条件
- 目標は、最下層から自由／オープンソースのコンピュータを構築し、ハードウェアとソフトウェア全体の動作を公開されたHDLおよびソフトウェアソースで説明可能にすること
- システム全体を作るコンパイラと関連ツールチェーンも自由／オープンソースでなければならず、そのコンピュータ上でビルド・実行できる必要がある
- 結果として必要なのは、セルフホスティングな自由／オープンソースのハードウェア＋ソフトウェアスタック
- シリコンファウンドリを所有または制御できないため、ハードウェア構成要素はFPGA上に実装する
- FPGAのプログラミングとビットストリーム生成も、信頼モデルを維持するために自由／オープンソースのツールで処理する必要がある
FPGAがもたらす信頼性のトレードオフ
- FPGAの使用は、専用ASICを自作する代わりに選んだ現実的なトレードオフ
- チップファウンドリは、そのFPGAが何に使われるのか、いわゆるprivilege bitがチップ内のどこに配置されるのかを把握しにくい
- この条件では、権限昇格のハードウェアバックドアを緩和でき、FPGAの製造段階で仕込める攻撃はDoSに限定されると考えられる
- コンピュータが完全に停止することはあり得ても、正常に動作しているふりをしながら所有者を裏切る可能性は低くなるという判断
- FPGAは同一構成要素が繰り返される規則的な格子構造を持つため、専用ASICより破壊的な視覚検査がしやすいと考えられる
- 例としては化学的除去とTEMイメージングが挙げられる
- 製造段階の攻撃面を減らした後でも、悪意あるソースやツールチェーンといったリスクは残る
- この問題には、すべてのHDL・ソフトウェア・ツールチェーンをビルド可能な公開ソースに限定することで対処する
参考資料と実装実験
- FOSDEM 23: 最近のスライドと発表
- linux-on-litex-rocket: 最新のビルド手順
- self-hosting demo: セルフホスティングのデモ
- CReSCT 2020 Paper, Slides, Presentation: IEEE S&P 2020関連の発表資料
- lowRISC project: 構成要素の理解に役立ったが、当時はクローズドなHDLツールチェーンやDRAMコントローラなどの独自IPモジュールに依存していた
- yoloRISC: Lattice ECP5 5G Versaボード向けRV64IMAC Rocket-ChipベースのblinkyデモSoC
1件のコメント
Hacker News の意見
理論的には、FPGA の中に隠された CPUがあり、FPGA プログラム全体への読み書きアクセスも可能だと考えられる
また、同じシステムや次世代向けに FPGA の生産量が増えれば、ファウンドリは追加情報を得ることになり、権限ビットがどこにあるかをかなり高い精度で推測できる
もっと単純には、FPGA にコードを載せて直接解析することもできる
大きな FPGA を買うと ARM コアが入っていて、それらの ARM コアはすべて、ユーザーが置き換えられない不透明な署名付き blob を EL3 で実行する
これはファブリック上のソフトコアではなく専用シリコンであり、Xilinx デバイスの ICAP、つまり内部構成アクセスポートや、他メーカーの同等機能にもアクセスできる
現代の DRAM にはリンクトレーニング、ターゲットリフレッシュ、オンダイ誤り訂正のような複雑な機能が多く、正確な実装が分からなくても、バックドアを隠すには十分な複雑さがある
特定のメモリアクセスパターンを監視し、正しいパターンが検出されたら任意の読み書き権限を提供する機能を入れられるだろう
そうすれば JavaScript のような信頼できないがサンドボックス化されたコードから権限昇格に使え、任意メモリ読み取りで書き込み先を見つけられるため、CPU アーキテクチャや OS にも依存せず動作できる
DIMM や複数チップのメモリモジュールでは効果は薄いだろうが、RISC-V コンピュータはたいてい DRAM チップを 1 個だけ載せた小型シングルボードコンピュータだ
ソースコードには現れないが、バイナリには自ら注入される
Thompson は管理された条件下でこれを実演したが、現実にそのようなバックドアが検出を逃れるには、ほとんど AGI 級の巧妙さに近いものが必要になる
ハードウェアとソフトウェアが進化しても動作し続け、伝播し続けなければならず、サイズや実行時間といった痕跡も常に低く保つ必要がある
このように現代のコンピューティングをまったく別の基盤の上に作り直す作業は、こうしたバックドアの使用を大きく妨げ、複雑にするだろう
https://en.wikipedia.org/wiki/Backdoor_(computing)#Compiler_...
もちろん大規模な無差別監視にはまったく非現実的だろうが、ある組織が監視を逃れるためにこの手法を使っていて、ソフトウェア構成も予測可能だと国家主体が知っているなら話は変わってくる
配置は固定されておらず、ハードウェア LUT/FF と合成された機能との間に一貫したマッピングもない
オープンソースのツールチェーンでビルドした RISC-V ソフトコアが動く orangecrab FPGA に、Linux シェルでログインできるというのは本当に驚きだ
少し前までは不可能で、うまくいっても Xilinx PetaLinux と同社のプロプライエタリな寄せ集め程度だった
小さな iCE40 LP1K にも SERV、さらには QERV まで問題なく収まる
完全互換の RISC-V 実装がどこまで小さくなれるのかには驚かされる
オープンハードウェアとオープンソフトウェアがついに一緒に動いており、10 年以内に非常に大きな流れになるだろう
似た方向に進んでいるが、経路は違う
私の設計は VexRiscv ベースで、すべてのハードウェアは SpinalHDL で書かれている
Karnix ボードの SRAM が 512KB に制限されているため、まだ Linux は動かせないが、Ethernet と HDMI がある
グラフィック 320x240x4 とテキスト 80x30x16 モードをサポートし、ハードウェア支援のスムーズスクロールができる CGA 風のビデオアダプタも HDMI インターフェイスで実装した
興味があれば短い README はここにある: https://github.com/Fabmicro-LLC/VexRiscvWithKarnix/blob/karn...
ボード用 KiCAD プロジェクト: https://github.com/Fabmicro-LLC/Karnix_ASB-254
素晴らしい仕事だ
trusting trust 攻撃に対する私の **多様な二重コンパイル（DDC）**の仕事が目立つ形で引用されていてうれしかった
DDC に興味があればこちらを参照: https://dwheeler.com/trusting-trust
システムを自分自身の上で再ビルドし、bitfile が同一かを検証するのは良いことだ
512MB で再ビルドできること、そして約 65MHz の CPU で「たった」4.5 時間しかかからなかったことに驚く
yosys や vivado などを使った経験では、通常は数 GB を要求される印象だった
65MHz の Linux 対応 CPU は 1990 年代半ばの Intel 486 と初代 Pentium を思い起こさせると言っていたが、50〜65MHz と 512MB の組み合わせは、1990 年代初頭の Unix ワークステーションに近く見える
RAM の面ではむしろもっと良いとも言える
参考までに、lowRISC/50MHz での倍精度 linpack は 4.5 Mflops だ
2022 年に似たことを LiteX でやってみたが、Kintex-7 FPGA を使ったため、少なくとも当時は実際の配置配線に Vivado が必要で、セルフホスティングではなかった
それでも Linux と Xorg が動くオープンなゲートウェアのノート PC ができた。Linux-on-LiteX-VexRiscV のおかげだ: https://mntre.com/media/reform_md/2022-09-29-rkx7-showcase.h...
インドの IIT-Madras による RISC-V ベースの Shakti も参考になる: Open Source Processor Development Ecosystem - https://shakti.org.in/
Wikipedia の概要もよい: https://en.wikipedia.org/wiki/SHAKTI_(microprocessor)
この人は以前、qemu/kvm で OS X を動かす関連の作業もしていた人: https://www.contrib.andrew.cmu.edu/~somlo/OSXKVM/
本当にすばらしい
完全にセルフホスティングできる RISC-V マシンが切実に必要だと、しばらく前から思っていた
今いちばん大きな制約は、十分なオンボード RAM を備えた FPGA ボードを見つけることのように思う
ここで対象になっているボードは 512MB のようだが、FPGA ツールチェーンはたいてい数 GB 使えるとずっと扱いやすい
セルフホスティングのハードウェアとソフトウェアという考え方はよいが、60MHz CPU で GCC みたいなものをビルドする苦痛は想像もつかない
しかも Rocket CPU は Scala で書かれている
最近 RockPro64 で Gentoo を使うのをやめたが、コンパイル時間が耐えられなかったからだ
そのシステムでさえ、ここで使おうとしているものより何桁も速い
こうした自由・オープンソースのコアの多くは、そもそも最適化が不十分だったり ASIC 向けだったりして、FPGA では性能が非常に悪く出る
よく設計されたコアを現代的な FPGA に載せれば、このような最下位クラスの低消費電力 Lattice 部品でなければ、より強力なマイクロアーキテクチャで 250MHz 以上も十分可能
ただし安くも簡単でもないので、趣味の領域ではあまり見かけない
また、より優れた FPGA には自由・オープンソースのツールチェーンがないことが多く、自由ソフトウェアの精神にもあまり合わない
それでも 250MHz でも、ソフトコア上で Chipyard を動かすのは忍耐力の訓練になるだろう
ただ、欲しいものを全部コンパイルしようとすると 1 週間かかるかもしれない、という点には同意する
もちろんクロスコンパイルという方法もある
それほど昔のことでもない
最初に使ったコンピューターはだいたい 1MHz で動作していた
遅いマシンではコンパイルにより時間がかかるだろうが、それ自体は大きな問題ではない
コンピューターが安定していてビルドスクリプトが正しければ、数日でも数週間でもそのまま走らせておけばよい
人生で数日や数週間かかるジョブはたくさん走らせてきた
“compiling” 参照: https://xkcd.com/303/
本当の問題は デバッグだ
遅いシステムでデバッグすると反復サイクルが長くなり、つらくなりうる
歴史的には、工程を分けて複数の地点から再開できるようにし、毎回全体のプロセスを繰り返さないようにすることで解決してきた
ここでも同じ方法が通用する
さらに、より速いが信頼性の低いシステムでスクリプトをデバッグしてから、動作が確認できたら遅いシステムで実行するという選択肢もある