セキュリティキャンプフォーラム 2015 でローレイヤーな話をした

ローレイヤー勉強会は、、、、CPUを自作するとかレイヤーが低すぎる内容です！ｗ #spcamp #seccamp pic.twitter.com/sIwqkDTTzc

— security_camp (@security_camp) February 14, 2015

セキュリティキャンプフォーラム 2015 に行ってきました。

セキュリティ・プログラミングキャンプ界隈は、最近老害かなと思いつつ参加を自粛していたのだが、久しぶりに発表のお誘いをもらったので参加してきた。

今年のキャンプフォーラムは2部構成で、後半のテクニカルセッションのうち愛甲先生が主催のローレイヤー勉強会で発表する機会を頂いた。

話す内容は、ローレイヤーな話だったら何でも良いということなので、最近自分がやっている研究の OS の話でも良いのだが、せっかく若い人が大量にいるのでローレイヤーの層を厚くする活動をしようと思い、Open Design Computer Project に絡めてこちら側に引き込む系の話をした。

ゼロから始める自作 CPU 入門 from Hirotaka Kawata

時間がなかなか足りなくて、話したいことをちゃんと伝えられたかどうかはわからない。
ちなみに、これに興味を持ったならぜひこちらのスライドも読んでみて欲しい。

そろそろ、自作 CPU 関連のネタは賞味期限も尽きてきた感があるし、どうしても万人受けする内容を作るとすごい薄い話になってしまうのが辛い。発表が下手くそなだけなのだが。

久しぶりにいろいろな人に会えて、とても良かった。研究もなかなか停滞していて、クズっている場合ではない。

今年は、SECCON も最後のオンライン予選一発にかけていたのだが撃沈して本戦出れなかったし、学生最後の年なのでやれること存分をやっていきたい。

xv6 を自作 CPU に移植して mruby を動かした話をした #kernelvm

先日の日曜日、第十回 カーネル／VM探検隊＆懇親会 (#kernelvm) に参加してきました。
相変わらず、カーネルVMは濃かった。僕の低レイヤー欲が非常に満たされる感じでした。
何故か、PDP-11 が熱かったです。勿論、美しいアーキテクチャですが、かと言って今の時代に PDP-11 というのも変な話ですが。

その前の週に LinuxCon Japan 2014 も学生無料枠 (first50) 参加したのでで、非常に濃い1週間でしたね。各所で話題になっていた、"ワタシハリナックスチョットデキル" Tシャツも頂きました、大切に使います。

ところで、僕はどんな LT をしたかというと、卒論ネタに少し絡めて発表しました。
卒論は主に SSDAlloc という、ハイブリッドメモリアーキテクチャ？を元に mist32 プロセッサの MMU を改造してフラッシュメモリをメモリの一部のように利用できる MMU を提案してみる、みたいな研究でした。
そこで、mist32 プロセッサ向けに OS を何か移植する必要があって、更に何かアプリケーションも動かす必要があったので、その時の話をちょっと。

具体的には、xv6 という UNIX V6 を参考に作られた x86 向けの MIT で使われている教育用 OS を、mist32 に移植して、更にその上で mruby を走らせられるようにポートしました。

xv6 移植については少し wiki の方にまとめました。
http://open-arch.org/software/porting_xv6

スライドは以下に乗せておきます。
もっと詳しく書きたいのですが、時間もないので聞きたいことがあったら気軽に @hktechno に聞いてください。

# しかし、自作プロセッサを作って OS を移植した程度では、#kernelvm 的には何の驚きも提供出来ないことがわかったので、さらなる高みを目指す必要がある。

xv6 + mist32 + mruby from Hirotaka Kawata

glibc の関数の引数の数について調べてみた

Open Design Computer Project で作っている mist32 プロセッサの、関数呼び出し規則と割り込みについて考えてる間に、あるひとつの疑問が...

ふつうの関数は、どれぐらいの引数を使うのか

平均と言うよりは、最大でどれぐらいまでの引数が使われることが普通なのか。

何故こんなデータが欲しいかというと、関数呼び出し規則 (Calling conventions) でレジスタに引数を乗せることは確定だが、どの程度引数レジスタを用意すればいいのか、という事を決めたい。

関数呼び出し規則では、レジスタに呼び出し元か呼び出し先か、どちらで保存するかを定義しなければならない。基本的には、呼び出し先保存 (caller-saved) なレジスタの方が、効率が良いのである。実際に使われたレジスタしか退避することがないから。

全部引数に載せればいいじゃん？って思うかもしれないけど、レジスタが許す限り全部引数をレジスタに乗せることに決めた場合、すべてのレジスタが呼び出し元保存 (callee saved) なレジスタになるので、問題が起きる。呼び出した先の関数がどのレジスタを使ってるのかなどわからないので、呼び出し元の関数で使ってる変数レジスタをすべて退避する必要がある。その先の関数でそれを使っていないかもしれないのに。また、割り込みの際にも、呼び出し元保存のレジスタは、基本的に割り込みハンドラで保存しなければいけないし、多すぎるといいことはない。

つまり、どの程度の数の引数が一般的に使われるかがわかれば、ほとんどの数の引数をレジスタ渡しで実現しつつ、無駄なレジスタ退避を少なくすることができる、理想の引数レジスタの個数をなんとなく予測することができる。

エンディアン変換とバイトアクセス

最近、Open Design Computer Project で mist32 プロセッサのシミュレーターを作っています。I/O のエミュレーションにもある程度対応してます。
https://github.com/techno/mist32-simulator

そこで気づいたことをひとつ書こうかなと。あたりまえのことなのですが。

ビッグエンディアンとリトルエンディアン

ご存知の通り、この世のコンピューターは内部的にエンディアンやバイトオーダーと言われるような、1ワードのバイト列をどのようにメモリ上に配置するか、という手法が大きく分けると2つあります。

Data: 0x1234ABCD

                0  1  2  3
Big Endian:    12 34 AB CD
Little Endian: CD AB 34 12

上記が、ビッグエンディアンとリトルエンディアンの概要です。ビッグエンディアンの方が人間には自然に見えますが、コンピューター的にはそうでない面もあり、一長一短です。一般的に使われている x86 はリトルエンディアンを使っています。

ファイルシステムや、ネットワークプロトコルなどによって、エンディアンは普通は規定されています。(FAT はリトルエンディアン、ネットワークはビッグエンディアン) しかしながら、ELF のようなメモリイメージのようなフォーマットは、そう簡単に行きません。