読みたい論文リスト

だいぶ遅くなってしまったけど，2014年2月に開催されたNDSS2014の読みたい論文リスト．そのうち読む．

• Session 1: Network Security
• CyberProbe: Towards Internet-Scale Active Detection of Malicious Servers
• Amplification Hell: Revisiting Network Protocols for DDoS Abuse
• Session 2: Software and System Security
• ROPecker: A Generic and Practical Approach For Defending Against ROP Attacks
• Hybrid-Bridge: Efficiently Bridging the Semantic-Gap in VMI via Decoupled Execution and Training Memoization
• Session 5: Privacy
• Session 9: New Applications, Attacks, and Security Economics
• Power Attack: An Increasing Threat to Data Centers
• Session 11: Malware
• Persistent Data-only Malware: Function Hooks without Code

ASPLOS2014 もまだチェックできていない．こちらは2014年3月開催．ASPLOS2014の読みたい論文リスト．

• Session 2A: Security
• Using ARM TrustZone to Build a Trusted Language Runtime for Mobile Applications
• Virtual Ghost: Protecting Applications from Hostile Operating Systems
• Sapper: A Language for Hardware-Level Security Policy Enforcement
• Finding Trojan Message Vulnerabilities in Distributed Systems
• Session 3A: Software reliability and testing I
• RelaxReplay: Record and Replay for Relaxed-Consistency Multiprocessors
• Prototyping Symbolic Execution Engines for Interpreted Languages
• Session 4A: Virtualization
• I/O Paravirtualization at the Device File Boundary
• KVM/ARM: The Design and Implementation of the Linux ARM Hypervisor
• VSwapper: A Memory Swapper for Virtualized Environments
• Cider: Native Execution of iOS Apps on Android

Virtual Ghost はざっと読んだ．Linuxカーネルのアセンブリ部分をLLVM IRに書き換えてIRを解釈するプログラム側でアクセス先メモリをポリシベースでアクセス制御している．アクセス可能な領域を制御することで，カーネルから見えないメモリ領域（これがVirtual Ghostという名前の由来）を作り出す．すごいけど，カーネルの改修コストが高すぎる．著者の自己引用が3編もあり，2009年から似たような研究をしているみたい．

まだ読んでないけど，Virtualizationセッションは結構面白そう．

環境整備: i3-wm, xmodmap, xrandr

備忘録として．

環境

• Debian Wheezy (Debian 7.4), Linux 3.2.0-amd64

i3-wm

• Window Manager としてタイル型 Window Manager の i3-wm を利用
• % sudo apt-get install i3-wm
• ランチャ
• % sudo apt-get install suckless-tools
• mod4 + d でコマンド名を入力するタイプのランチャが起動
• i3-wmの設定ファイルは，~/.i3/config

xmodmap

• capslock -> ctrl したかった
• 以下を~/.xmodmaprcに追記
• remove Lock = Caps_Lock
• keycode 66 = Control_R
• add Control = COntrol_R
• 以下を~/.i3/configに追記
• exec xmodmap ~/.xmodmaprc

xrandr

• ディスプレイを時計回りに90℃回転したかった
• 以下を~/.i3/configに追記
• exec xrandr --output HDMI1 --rotate left
• --output で指定するディスプレイはxrandr --currentすれば見える
• --rotate left で反時計回りに回転（ディスプレイを時計回りに回転させたので）

stirlingのビットイメージの色付けについて

そういう方面の人にとっては有名なバイナリエディタ stirling には，ファイルをバイナリ列としてとらえて，一バイトずつ色分けして表示するビットイメージ機能がある．この色の定義がどうなってるのか調べたので，メモ．

strling に同梱されているヘルプファイルを読むと，以下のように書いてあった．

「ビットイメージに指定色を反映させる」チェックボックス

この項目をチェックするとビットイメージにデータ文字色、データ背景色、強調表示コード及び色が反映されます。チェックしない場合には以下のデフォルト色でビットイメージが表示されます。

00h 白

01h～19h 水色

20h～7Fh 赤

80h～FFh 黒

メインウィンドウのメニューから「設定」→「拡張子別設定」→「（ファイル種別）」→設定→「色・フォント」からビットイメージの指定色を変更できるようだ．

Windows 8.1 であるウィンドウだけがぼやける問題

どう表現すればいいのかわからないけど，ぼやける．あるウィンドウだけが拡大したようにぼやける．スケーリングの問題とのことなんだけど，原因がよく理解できない．

とりあえず，対処としては，「コントロールパネル」→「ディスプレイ」と選択して，「すべてのディスプレイで同じ拡大率を使用する」にチェックを入れると，解決する．

MSDNを見ると，高DPIディスプレイで正しい解像度でアプリケーションを表示させるには，アプリケーション側で，「1: システムDPIを使用すること」と「2: 高DPI対応であることを宣言すること」が必要とのこと．

• 高 DPI ディスプレイでアプリケーションが正しく表示されるようにする方法

多分，全体的にぼやけるようなアプリケーションは，この二つの条件のうち，どちらかを満たしていないのだろう． 私の環境だと，TeraTermでこの問題が起こった．ということで，Windows 8.1 の問題じゃなくて，Direct 2D + 高解像度ディスプレイの問題みたいだ．

追記
この記事を読むかぎり，Windows 8.1 の問題のようだ． （【特別編】Windows 8.1のグラフィックス、その期待と懸念 ）

Xenのコンパイルでbits/predefs.hがみつからないと言われたときは

Xen をコンパイルしていると、 tcgbios.c のコンパイル時にエラーが出力される。ビルドに失敗したときのソースが手元になりのでエラーメッセージを掲載できないが、同様の問題で困っている人がいた。 xen-devel の ML に投稿があった。

どうも 、 tcgbios のコンパイルには、32bit 版の libc が必要らしい。Debian の場合、以下のコマンドで 32bit 版の libc をインストールできる。

• sudo apt-get install libc6-dev-i386

ML への投稿だと、Xen のソースの中に README があって、そこに Xen をビルドするのに必要なパッケージが書かれているので、そこに、 lib-dev-i386 を追加してくれないか？という提案らしい。ただ、この記事を書いた時点では、まだ追加されている様子はない。（tcgbios はなんで libc6 の 32bit 版に依存するんだろう？という疑問はある。）

zshのサブシェル実行がわからない

Software Design 1月号の第1特集第2章で、サブシェルについての解説があった。紙面のコマンド例ではプロンプトが%だったので、zshかなーと思って、サブシェルの解説で示されていたコマンド例と同じことをやってみたら、結果が異なった。結論から言うと、解説にも書いてあったけど、想定してるのはashまたはdashだった。あと、サブシェルの生成の契機がdashとzshだと違った。

紙面だと、dash で

• $ (sleep 200 | sleep 200) &

したら、サブシェルが生成されていた。
zshで試すと、以下のようになっていた。

なぜ違うのだろうか。ていうか、そもそも、dashだと、パイプで繋いだプロセスがそれぞれ独立したプロセスとして起動されているのに対して、zshは、パイプの前にあるプロセスの子プロセスとしてパイプの後のプロセスが起動されている。

サブシェルを実行してその中でプロセスを二つ起動するのと、サブシェルを起動せずに、子プロセスとして二つ目のコマンドを実行するのだと、後者の方が高速な気がする。ただ、zshは結構大きいので、起動が遅い。なので、無駄にサブシェルを起動しないようにしているのではないかと思う。

実際に、シェルの起動と終了にかかる時間を測定してみた。dashもzshも、起動時に-cオプションでコマンドを渡せるので、*sh -c exitをtimeコマンドで10回測定した平均を計算した。ちなみに、どちらのコマンドもzshから起動している。dashから起動したら、また違う結果になると思う。

• dash: 0.0026 s
• bash: 0.0047 s
• zsh: 0.0062 s

やっぱりdashが速い。

とここまできて、やっとA User's Guide to the Z-Shellの3.2.3項を読んだのだけど、

In zsh, all but the last portion of the `pipeline' thus created is run in different processes.

らしい。つまり、パイプの最右のコマンド以外は新しいプロセスを生成するらしい。で、() で括ったときにどうなるかというと、どうも、ps コマンドで眺めている感じだと、パイプの最右のプロセスが子プロセスとして生成されて、最右以外のプロセスは最右のプロセスの子プロセスとして生成されるっぽい。謎だ。

3.8.3項, 3.8.4項 あたりをちゃんと読まないと。

とりあえずvagrant使ってみた

Linux Mint 15 で vagrant を入れて、作成したVMにログインできるところまで確認した。ちなみに、vagrant は「放浪者」とかそんな意味だった（alc）。vagrant の公式サイトを参考にした。

• sudo apt-get install vagrant

ログ見てたら一緒にvirtualboxも入ってた。vagrantは、virtualboxでVM作成するところを自動でやってくれる。

• vagrant init precise32 http://files.vagrantup.com/precise32.box

vagrant の初期化。カレントディレクトリにVagrantfileを作成する。このファイルはrubyで書かれていて、第一引数は、生成するVMのインスタンス名を指定し、第二引数は、ユーザのシステムに.boxなファイルが無いときに取得しに行くURLを指している。ちなみに、このURLをブラウザに突っ込んだら、website-unavailable.com に飛ばされた。vagrant init 自体は、設定ファイルを生成するだけなので、すぐに終わる。

• vagrant up

VMを起動する。最初は、VMイメージが手元にないので、vagrant init の第二引数で指定したURLに取りにいってるみたい。二つ目のインスタンスを作ろうとしたら、ダウンロードは起こらなかったけど、Thinkpad X220i (Core i3-2310M@2.10 GHz, 4GB RAM, SSD) な環境で34秒かかった。結構遅い。この処理の内訳も気になる。VMの起動とゲストOSの起動処理の比率で、この34秒が遅いのか否か分かれる。vagrant up したら、/usr/lib/virtualbox/VBoxHeadless とかいうプロセスが起動してた。

• vagrant ssh

起動したVMにsshでログインできる。パスワードとかはかかってない。あと、コマンドのヒストリを見ると、update-locale とか locale-gen とかしてた。ちなみに、uname -aしたら、Ubuntu 32-bit で Linux 3.2.0-23-generic-pae だった。

• vagrant suspend

vagrant suspend でVMを停止できる。4.557 秒かかった。

• vagrant resume

vagrant suspend したVMを再開できる。19秒かかった。ちなみに、vagrant up でも再開できる。

• vagrant status

vagrant で作成したVMの状態を確認できる。また、VM名を指定することで、各VMごとの状態を確認できるらしい。今回は、一つしかインスタンスを起動していなかったためか、「A multi-vm environment is required for name specification to this command.」と怒られた。

• vagrant halt

vagrant suspend はサスペンドなので、状態を保持して停止させるけど、vagrant halt は、シャットダウンするみたい。

• vagrant destroy

停止させる。所謂強制終了と捉えれば良いのか？

とりあえず、ps -ef してみたら、以下のプロセスが起動してた。

1. /usr/lib/virtualbox/VBoxXPCOMIPCD
2. /usr/lib/virtualbox/VBoxSVC
3. /usr/lib/virtualbox/VBoxHeadless

最初のはIPCだから、vagrantコマンドでvirtualboxを制御するためにコマンドを送るインタフェースかな？VBoxSVCは、ここを見ると、SMF Service Wrapperとのこと。書いてあることを素直に解釈すると、「非特権ユーザの所有するvirtualboxインスタンスをSolarisのSMFサービスとして制御する。」とか、「VBoxHeadless VMを起動した後にSMFサービスとしてresumeして、VMへのシリアルコンソールヘ接続する。」とのこと。色々書いてあるけど、要は、virtualboxのインスタンスの管理を便利にするためのものらしい。引数には、「--auto-shutdown」が指定されている。VBoxHeadlessは、man vboxheadlessを読むと、virtualboxのVMを起動したり、起動したVMの画面をキャプチャできるらしい。とにかく、vagrantでは、VMの起動にvboxheadlessを利用している。引数は色々指定されている。--comment でVMのインタンス名を指定しているようだ。--startvmも渡されているようなので、やはり、vboxheadlessでVMを起動している。また、--vrde config も渡されている。これは、よくわからない。

ホスト側から見た環境は、大体、これくらい。次にゲストから見てみる。topを実行すると、「Mem: 378000k total」と表示されるので、378 MBメモリが割り当てられているようだ。cat /proc/cpuinfo すると、processor: 0 の状態しか表示されないので、1コアしか割り当てられていない。gccやmakeは最初から入っているみたい。このあたりのスペックに関しては、vagrant init したときに指定したURLで配布されているイメージの仕様だろうから、どこかに書いてあるだろう。

ざっと見るとこんな感じだった。vagrant -h すると、以下のようなコマンドが利用できるらしい。

1. box
2. destroy
3. gem
4. halt
5. init
6. package
7. provision
8. reload
9. resume
10. ssh
11. ssh-config
12. status
13. suspend
14. up

今回書いていない、package, provision, reload あたりがとても気になる。vagrant gem は、vagrantのプラグインをgemを使ってインストールするコマンドらしい。どのコマンドも、vagrant [command name] -h で使い方が表示される。ただし、-h オプションで参照できる情報が異様に少ないので、あまり参考にはならない。

今後は、今回書かなかった（試していないので書けなかった）コマンドや設定ファイルの中身を見ていきたい。

追記（2013/12/29 00:57）：SMFはService Management Facility の略らしい。ここに書いてあった。