BitVisor Summit 8

1. BitVisorに移植する (2)
東京農工大学 市川 遼
2019/12/12 BitVisor Summit 9

2. 自己紹介
● 東京農工大学 工学府情報工学専攻 2年
○ 留学していたので卒業が一年伸びた
● 興味
○ Web security, Forensics, etc.
● 研究
○ VMM

3. 前回お話したこと
● BitVisorにLuaやLibVMIを移植する方法
● 依存ライブラリ (libc, GLib) はどうする？
○ 通常のMakeでビルド
○ *.o を探し出してobjs-1に追加
○ BitVisorに対応するためにmuslは部分的に修正する
● BitVisorのどこに追加する？
○ 保護ドメイン (process) で動かす
● Lua用のパッチが必要
○ lua.cをBitVisorのprocess向けに編集した
○ SSEを使うためにCR0, CR4を設定

4. 今回お話すること
● 文字通りLuaのソースコードに一切手を加えず移植する方法を考案した
○ main関数を直接呼び出せる
● musl から newlib への変更とその理由
● 実際に Lua を今回の方法で移植する手順を紹介

5. ディレクトリ構成
● 新しく追加するアプリケーションを app に配置すると仮定
● app/third_party
○ 依存ライブラリのビルド用 (BitVisorのビルドには使わない )
○ Luaはlibc以外に依存しないので今回は不要
● app/lua
○ Lua本体のプログラム
● app/process/lua.c
○ アプリケーションのエントリポイント
○ ここから目的のプログラムの mainを呼び出す

6. app/process/lua.c
● 本来のmain関数をライブラリのように扱う
○ argc, argv を設定しておく
● exitprocessを忘れない
○ return 0では終了しない
○ 無限にプロセスが増える
● app/process/Makefile でリンク対象を指定
○ lua-objs = lua.o ../../third_party/lua/lua-5.3.5/src/lua.o
○ lua-libs = third_party/lua/$(outa)
● これでLua本体には変更を加えず起動可能
int
_start (int a1, int a2)
{
// app/lib/lua/lua/src/lua.c:main
int main(int, char *[]);
const int stacksize = 16*1024;
if (setlimit (stacksize, 8*stacksize)) {
printf("lua restrict failedn");
exitprocess(1);
}
int argc = 1;
char *argv[] = {"lua", 0};
main(argc, argv);
exitprocess(0);
return 0;
}

7. 移植の際に発生する問題点を整理する
● システムコールが全く違う
○ process用に用意されたもののみ (core/process.c)
■ msg*, {new,exit}process, setlimit
○ 多くのプログラムはlibc経由でLinuxのシステムコールを呼び出す
● リンク時の名前衝突
○ libcをそのままコンパイルすると BitVisorで独自実装されているものとぶつかる
● ライブラリの静的リンク
○ BitVisorのビルドシステムはちょっと特殊である

8. 解決策
● システムコールが全く違う、リンク時の名前衝突
○ バイナリをビルドした時点で BitVisor用の命令セットであれば良い
→ BitVisor用のコンパイラを作れば良いのでは？
● ライブラリの静的リンク
○ いままではBitVisorのobjs-1に追加する方法を取っていた
■ 追加するライブラリが多くなってくると面倒
○ GCCのstatic linkだけで片付けたい
● → BitVisor用のコンパイル環境があればよいのでは？

9. x86_64-bitvisor-gccのビルド
● toolchain (Binutils, GCC, newlib) のBitVisor対応
○ https://wiki.osdev.org/OS_Specific_Toolchain
○ https://wiki.osdev.org/GCC_Cross-Compiler
○ https://wiki.osdev.org/Porting_Newlib
○ https://sourceware.org/newlib/libc.html#Syscalls
○ OSDev Wikiがnewlibにしか対応していなかったので muslから変更
■ newlibは変更すべきファイルがまとまっていて扱いやすい
○
● ホストの名前空間を汚したくないのでDocker上で構築する
○ x86_64-bitvisor-gcc という保護ドメイン用コンパイルが出来上がる
○ 当然このコンパイラでコンパイルされたバイナリは Linuxで実行できない

10. BitVisorサブシステム
● newlib/libc/sys/bitvisor にシステムコール部分を実装
○ いくつかの関数をBitVisorの機能へリンクする
● syscall:sbrk -> bitvisor:lib_mm:alloc
● syscall:_exit -> bitvisor:lib_syscall:exitprocess
● stdio:fgets -> bitvisor:lib_lineinput:lineinput
○ readを msgsendint(0,0) にしてもうまく動かない
● syscall:write -> msgsendint(1, c)
● あとはstubでとりあえず十分

11. newlibベースtoolchainのビルド
● binutils
○ 8 files
● gcc
○ 6 files
● newlib
○ 19 files
■ 4 files: newlib本体
■ 15 files: bitvisorサブシステム (syscall実装含む)
● diff: 2033行
● dockerでビルドする

12. ビルドシステム側の修正
● process-binを吐き出すときにx86_64-bitvisor-gccに差し替える
○ Makefile.buildの $(bins) セクション
● コンパイラフラグ
○ -static
○ -l$(lib)
● 後は普通にビルドするだけ
○ 必要なライブラリをあらかじめ docker内でビルド、インストールしておく
○ *-objs, *-libs でやってた依存関係解決を GCCで代わりにやってしまう

13. processに追加する
● process に追加するとlibがせっかく実装したbitvisorサブシステムと衝突
→ 新しくprocessディレクトリを作る (app/process)
○ psubdirs に追加
○ process-depends を忘れない (並列ビルドすると依存関係で落ちる )
■ Makefile:
● $(dir)app/process/$(outp_p) : $(app-depends-1)
● process/lib を用いずにビルド可能に
● 依存ライブラリはコンテナ内からリンクされる
○ *-libs に追加する必要がない

14. 欠点
● ビルドシステムがsanity checkを持っていると走らない
○ コンパイルされたバイナリが実行可能かどうか
○ syscallが違うのでそれはそう
● GLibのビルドシステムが meson + ninja に変わった
○ LibVMIで必要
○ x86_64-bitvisor-gcc でビルドすると途中で落ちる
○ 現在はGLibだけ x86_64-linux-gcc でビルドしている

15. まとめ
● DockerでBitVisor用のビルド環境を作った
○ 依存ライブラリなどの問題が解決された
● 真の意味であらゆるプログラムを移植可能になった
○ newlibは最低限しか実装していない (read, write gettimeofday
○ 必要なsyscallは実装する必要がある
● newlibを用いて容易に拡張できる
○ 必要なsyscallは newlib/libc/sys/bitvisor で追加
○ mprotectなどを実装すればJITも動くかも？ (今後の展望)