VirtualBox でゲストからホストの生ディスクを使うには

VirtualBox では生のパーティションも扱えると聞いていたので，そっちを試してみることにする．参考にしたのは
 - 物理パーティションにインストールしたOSをVirtual Boxで使う
 - Windows 上の VirtualBox で実パーティション上の Linux を起動する
 - Using a raw host hard disk from a guest
あたり．

Step 1. 仮想ディスクの作成

 まず，vmdk 形式の仮想ディスクを作成する必要がある．VirtualBox 付属の VBoxManage コマンドを使うのだが，Linux で作成したディスクを Windows で使ったりは出来ないようだ．(出来れば楽だったんだが．もしかすると VirtualBox のバージョンが違ってたかも)

VBoxManage internalcommands createrawvmdk -filename FILE.vmdk -rawdisk /dev/sda

にて作成するが (この時はディスクにアクセスするため，root or 管理者権限が必要になる)，デバイス名は Win -> "\\.\PhysicalDrive0", Mac -> "/dev/disk1" 等に読み変える．基本的にはこれで終了だが，この仮想ディスクを使っているゲスト OS から，ホスト OS で使っているパーティションにアクセスすると VirtualBox が落ちてしまうので，アクセス禁止にしておくのが無難だ．それには作成時にアクセスを許可するパーティションを指定してやればいい．今回の場合，

VBoxManage internalcommands createrawvmdk -filename FILE.vmdk -rawdisk \\.\PhysicalDrive0 -partitions 3,5,6,7,8

とやって Linux 方面にのみアクセスするようにした．この状態で起動した場合でも，p1，p2 は見えなくなるわけではなく，単にアクセスエラーになる．従って fstab を書き換える等の手間は不要だ．
パーティションを限って .vmdk を作成すると，FILE.vmdk と FILE-pt.vmdk の 2 つのファイルが出来る．多分両方必要なのだと思うが，仮想ディスクとして指定するのは FILE.vmdk のほうだ．(両ファイルを同じ場所に置くことを推奨したい)

Step 2. 新規仮想マシンの作成

 ディスクが出来たら VirtualBox を起動する．この時もディスクにアクセスするので root or 管理者権限が必要だ．新しい設定を作っていく途中で仮想ディスクとして上で作成した FILE.vmdk を指定してやれば OK．
（もっとも今回は，生 Arch が amd64 バイナリだったため，起動に失敗した．やれやれ）
 (64bit ゲストを動かすためには，設定で 64bit を選択する必要がある)

Step 3. 起動

 その状態で起動すると，不思議なことに生パーティションを使って起動できる．MBR は，/dev/sda のものが FILE.vmdk にコピーされているようだ．他サイトで説明されているように，ディスク作成時に指定してやることで好きな MBR を使うこともできる．また，読み書きするのに "-relative" オプションも不要．(ホストが Linux の時には必要？)

 速度は，仮想ディスクを使う時よりもわずかに遅いようだ．他は変るところはないと思う．

VirtualBox

Win でしか使えないハードを使う機会が増えてきたので、何度も再起動するハメになり面倒だ。そのへんをなんとかしてみようかと Virtualbox を試してみることにした。ホストは Win7 でゲストには ArchLinux と debian。
VirtualBox のインストールは簡単。インストール後はウィザードに従って設定、起動には USB CD を使ってもいいし CD-image を使ってもいい。どちらも試したが、まあ image のほうが楽かな。静かだし。

最初の難関は xorg。単に入れただけだと 800x600 (しかも遅い) で動く。メニューから "Guest Addition のインストール" を選ぶことで /dev/sr0 あたりにゲスト OS 用ツールの cd-image がセットされる。それをマウントして OS に合致したものを導入する (shell script)。Linux の場合は、カーネルモジュールをコンパイルするので、arch なら base-devel と kernel26-headers、debian なら build-essential あたりをあらかじめ入れておく。
スクリプトを動かすと、カーネルモジュールとツールがインストールされる。場所は /opt あたり。リンクも作成してくれる。vboxvideo あたりが上っている状態で xorg を動かすと、好きな解像度で GUI を使える。私の好みはフルスクリーンかな。

debian は問題なかったのだが、arch のほうは一般ユーザで xorg を起動しようとしても失敗する現象が発生．root では問題ないのでパーミッションかな？と思うがよく判らない。結局、/etc/skel に入っていた .xsession が「何もしない」設定になっていたためと判明。"exec openbox" を記載してやることで動くようになった。(まったくこんなことで時間を取られるなんざ... )

 使ってみたがなかなか速い。例の pdftoppm ベンチにしても、2 割ほど遅いぐらいで済んでいる。描画のほうも問題ないようだ。1280x764 とかの flv でもスムーズに再生する．

ところが usb メモリを読もうとしたら反応しなくなった．usb cdrom は問題ないのになあ．起動から終了まで付けていたからかな？
ファイルのやりとりには共有フォルダを使うのが良いようだ．Virtualbox の方で設定して，ゲストの Linux に入った後は "mount -t vboxsf DIRNAME /MOUNTPOINT" でマウントできる．

 後，気付いたのは，ネットの接続が遅いことか．速度が出ないというわけではなく，最初の接続に時間がかかる印象．これは設定が NAT になっているからかもしない．bridged にしてみるべきかも．

別にある Linux ホスト w2k ゲストの環境で共有フォルダを使ってみる．ホストのマネージャのほうを設定して，ゲストのほうでは「ネットワークドライブの設定」あたりで "\\vboxsrv\SHARE_NAME" みたいなかんじで割り付けしてやると使えるようになる．今迄は smbmount していたが，ずいぶん簡単だ．それに "smb 共有を解除する前に VirtulaBox を終了してしまったぁ" なんてこともおこらないし．

パスワード定期変更考察．

(「パスワード定期変更云々」を読んで の続き)

 関連のところをちょっと辿って 続パスワードの定期変更は神話なのか に到達．こちらの計算は私が考えたのと同じ．このような観点からパスワードの定期変更を考えたことはなかったのだが．なかなかにおもしろい．
例えば，全数アタックするのに「入社から退職までの」40 年 (=365*40+10 = 14610日) を必要とする強度のパスワードがあったとして，毎日パスワードを変更した場合，破られない確率は
( 1 - 1/14610 ) ^ 14610 = 0.36786685... = 36.8%
となる (これは理想値である 1/e = 0.36787944... にかなり近い)．でも結局 63.2% の確率で破られるわけだ．

次に鍵空間を全部チェックできる時間と，パスワードの定期変更による破られる確率の変化について考えてみる．鍵空間を全部チェックできるだけの時間パス ワードを変更しなかった場合，破られる確率は当然 1 だ．1/2 の時間で変更した場合は 0.75．大幅に上昇する．その先は...

変更回数(探索終了までに)	突破確率	グラフ
1 回 (最初だけ)	1.000
2 回	0.750
3 回	0.704
4 回	0.684
5 回	0.672
6 回	0.665
7 回	0.660
8 回	0.656
...
∞ 回	0.632

と，5回あたりからサチってくる．そしてどんなに頑張っても 63.2% までしか下がらない．
前提のように，パスワードをチェックし終るまでに 40 年かかる場合であれば，
8 年毎に変更すれば毎日変更するのとそう変わらない強度を保てる
ことになる．(逆にいえばそれ以上の頻度で変更しても無駄．コストに合わない)

 対して，パスワードを英数 1 文字 (= 62種類) 分増やしていたとすると鍵空間も探索時間も 62 倍になるので退職日までにチェックできるパスワードも全鍵空間の 1/62，すなわち破られる確率は 1.6% にすぎない．
しかもこの数字は，
40 年間一度もパスワードを変更しなくても達成できる
のである．
 計算機力の増加を勘案してない，とか，単に長くても辞書攻撃にやられるようなパスワードではダメ，とかいろいろあるが，基本はそんなところだ．さらに言えばこれは計算機力だけを元にしているので，/etc/passwd が可視だろうが，ログイン再試行までに wait が入るまいが関係ない．


 パスワード強度を教えてくれるサイト How Secure Is My Password? によれば，9 文字で英数のパスワードだと解析までに 42 年かかるそうなのでなかなか近い．でもここって別に文字数と文字種ばっかり見てるわけじゃないんだなあ．"50% mathematics, 51% witchcraft." で予測していると書いてあるや．
IPA による試算 (2008) によれば，8 文字英数を突破するまでに 50 年とある．そんなもんかね．

計算機力は毎年上がっていくので，その時点で有効なパスワードの桁数を求めるのはなかなかやっかいだが，ちょっとだけ試算．
ムーアの法則に習って，計算機力は 1.5 年毎に倍増していくと考える．年あたりに直すと... 1.59 倍だ．対してパスワードのほうは，英数一文字 (62種類) 増やす毎に 62 倍になる．英数一文字を増やした場合，それに計算機力が追いつくには... 8.93 年かかるのか．9 年に一文字増やせば同じ強度を保っておける，と推測できる (楽観的には)．
まあ計算機力の向上は単純に CPU の性能ばかりではなく，どれだけの資源を用意できるかという問題もある．最近 (？) の流行は クラウドによるパスワード解析 のようだが，こういう手法は計算機力を一気に向上させる可能性を持つ．この記事のように，パスワード n 文字を解析するのにいくら，という考え方はなかなか新鮮だ．


 うちの会社の例でいえば，パスワードの条件は「英数記号で 8 文字以上，辞書の単語は駄目」だ．IPA の試算で言えば，突破までに約 1000 年．今は半年毎に変更させられているが，この条件なら
200年毎に変更
とか
10 年毎に変更で最小文字数を一文字づつ増やす
でいいかも．

pdftoppm ベンチ．64bit と 32bit の違い他．

pdftoppm ベンチ．64bit と 32bit の違い他．

Model	CPU	Speed(GHz)	OS	binary	time(sec)	rate
HP Z400	C2Q	3.06	openSUSE	x86_64	135.3	116.3
	C2Q	3.06	ubuntu	i386	157.4	100
Lenovo X200	C2D	2.67	ubuntu (wubi)	x86_64	149.0	194.3
	C2D	2.67	arch	x86_64	169.0	171.3
	C2D	2.67	debian	amd64	179.3	161.5
	C2D	2.67	debian	i386	289.5	100
HP dc7700	C2D	2.4	ubuntu (wubi)	x86_64	169.0	147.5
	C2D	2.4	ubuntu (wubi)	i386	249.3	100
HPC (HDAMD)	Opteron	2	ubuntu	x86_64	310.6	139.6
	Opteron	2	arch	i686	447.5	100
Lenovo A61e	Athlon X2	2	debian	i386	512.6	-

ubuntu が多いのは wubi を使うと (アン) インストールが簡単だから．ちょっと試すのに最適．

懸案の 32/64 bit 比較だが，確実に 64bit のほうが速い．OS の条件も揃った HP dc7700 の場合 1.5 倍，X200 に至っては 2 倍速くなっている．これだけはっきり差が出るとはなあ．64 を使わんわけにはいかんやんけ．
もひとつ心配していた X200 の速度だが，64bit の場合，Core2 系はほぼ周波数通りだった．綺麗な結果になっている．

ちなみに，windows 系だと 64bit と 32bit の速度差は 5% 程度らしい．特に乗り換えたくなる程ではないね．

※ 2010/12/31: X200 Debian amd64 と arch x86_64 の結果を追加．Ubuntu x86_64 との速度差の理由は不明．(pdftoppm のバージョンは deb: 0.12, arch: 0.14, ubu: 0.14)

「パスワード定期変更云々」を読んで

元はセキュリティホールめもの記事．

パスワード定期変更云々 を見た．

うーん... 100 日で全部試行できるとして，50 日で変更した場合，最初の 50日でクラックされない確率が 1/2．そこで変更するが，変更したパスワードが既に試したところに入る確率が 1/2．従って 100 日後に無事な確率ってのは 1/2*1/2 (=25%) なんじゃないかなあ？
一般的に言えば総当たりにかかる時間の 1/n の時間で変更するとした時，最初のターンで無事な確率は 1-1/n，次のターンで無事な確率は (1-1/n)^2... と来て，全試行時間後も無事な確率は (1-1/n)^n と．具体的に言えば，毎日変更した場合クラックされる確率は 1% = 安全な確率は 99% と．次の日も無事でいられる確率は 99% * 99% で以下同文，みたいな．

ということは複利計算なので，無限に短くパスワードを変更したとしても，1/e (約 36.8%) 以上に安全にはできない，のかな？
対してパスワードを [A-Za-z0-9] の中の一文字増やしたとすると，破られる確率が同じになるまでの時間が 62 倍になるわけだ．2 文字増やせば 3844 倍．どっちが良いか考えるまでもない．

X200, cpufreq あたり

Thinkpad X200 を Linux で使っている時，AC を繋いでいてもバッテリが外してあると CPU の周波数が最大まで上がり切らない．(P8800 の場合，1600MHz まで)

でも Windows なら OK．