開発ツール開発と、独自命令セット
この記事は
アセンブラ Advent Calendar 2019 - Qiita
https://qiita.com/advent-calendar/2019/asm
の9日目のために書いた。
しかし、カテゴリが「OS」になっていて、他のカレンダーはWindows Subsystem for Linuxとか何とかBSDとかPlan 9とかを題材にしている。
それらに並んでアセンブラとは、どういうことだ?
既存のOSや開発ツールなどを使うな、ということか!
Thompson hackで示されたように、ある種のワームを最初の開発ツールに仕込んでおけば、以後の開発ツールをワームの書かれていないソースコードから構築してもワームが感染し、ワームを取り除くことができない。
勿論、ワームの感染していない開発ツールを使えばいいのだが、何メガバイトもある既存の開発ツールのバイナリを調べて、ワームの有無を判別するのは絶望的だ。
現実的な方法として、異なる二つの開発ツールの出力を比較する方法もあるのだが、二つのツールともに同一のワームに感染している場合に対応できない。
そこで究極の方法が、バイナリの調査が絶望的な既存の開発ツールは一切使わず、何バイトもないショボい開発ツールから出発するものだ。
ショボい開発ツールを使って、もう少しマシな開発ツールを作る。
これを繰り返し、最終的には十分な機能を持った開発ツールを作成することで、ワームに感染していないそれを使い、ソースコードから既存の開発ツールを再構築する。
bcompiler - Bootstrapping a simple compiler from nothing
https://github.com/certik/bcompiler
bcompilerでは、16進数で表記されたバイト列のテキストファイルを、そのバイト列通りのバイナリファイルに変換するだけのコンバータが、出発用の開発ツールだ。
コンバータのサイズは、たったの191バイト。
ワームの有無の判別どころか逆アセンブルまで、人力で何とかできそうな小ささだ。
問題は、bcompilerには移植性が全くないこと。
古き良き32bitのx86のlinuxにベッタリ。
しかも近年の物理マシンには、Intel Management EngineやPlatform Security Processorなどのバックドアがハードウェアで実装されている。
この移植性と物理バックドアの問題に対応したのがstage0だ。
Stage0 - Bootstrap for the Free Software
https://savannah.nongnu.org/projects/stage0/
https://github.com/oriansj/stage0
開発ツールの構築を、物理マシンではなく仮想マシン上で行なっている。
仮想マシンをC言語で記述することによって、移植性を確保しているわけだ。
そして、仮想マシンは必ずしも、ソフトウェアで実装する必要はない。
stage0では仮想マシンの仕様を定めているので、その仕様を満たすようにトランジスタを並べるなりして、自分で物理マシンを用意すれば、stage0のコードがそのまま流用できる。
自作の物理マシンによって、既存の物理マシンに仕込まれているバックドアの問題を回避するわけだ。
ただし、stage0の仮想マシン命令セットは単純なものではない。
殆どの命令は4バイトだが、即値を使う命令は6バイトであり、固定長命令セットではない。
4個の汎用レジスタに同時にアクセスする命令もあり、加算命令と減算命令にそれぞれ6個のバリエーションがある。
物理マシンやFPGAによるソフトコアプロセッサどころか、インタプリタの構築も大変ではないか?
そこで私は、RISC風の仮想マシンを作ってみた。
stage0risc
https://github.com/abo-junghichi/stage0risc
命令の種類は27個しかないし、全ての命令が4バイトの固定長。
その他にも、インタプリタやソフトコアプロセッサを作り易くする工夫を加えたつもりだ。
問題は、肝心の開発ツールは未だ作っていないことだ。
さて、独自命令セットのstage0riscは冗談として、bcompilerとstage0、どちらに見込みがあるだろうか?
bcompilerの方は、現実に存在する物理マシン上で直接動作する。
対してstage0は、独自命令セットを使っているので仮想マシンを介さねばならない。
動作速度の上でbcompilerの方が圧倒的に有利だ。
しかし実際は、stage0の方がbcompilerの先を行っている。
いや、見込みではなく既に、ゴールテープを切っている。
stage0から最新のGNUツールチェーンへ至る道が出来上がっているのだ。
Mes - bootstrapping
https://bootstrapping.miraheze.org/wiki/Mes
開発のし易さの点では、後方互換性が積み重なってグチャグチャになった物理マシンの命令セットより、開発者自身謹製の独自命令セットの方が有利ということなのだろう。
