パーティション暗号化機構gbdeとgeliの比較

moodleサーバの個人情報保護用にファイルシステムの暗号化を導入する目的で、性能比較を行った。

gbdeの基本的な使い方

まず、5.xまででも実装されているgbdeについては、次のようにすると利用することができる。ここでは、SATAの320GBハードディスク/dev/ad12をまるまる使うことを前提に作業。

ロックファイル用の場所を用意しておき、次のコマンドでロックファイルとデバイス内のロックセクタの作成。ロックセクタというのは暗号化したマスターキーを分散配置したもので、その位置情報を暗号化したものがロックファイル（gbde(4)を読んだ理解が正しければ）。

# gbde init ad12 -i -L /etc/gbde/ad12

手動でやるだけならgeom_bde.koを明示的にロードする必要はない。-iでパラメータをファイルではなくインタラクティブに（というかエディタでいじって）与える。sector_sizeの初期値は512になっているが、これをフラグメントサイズ（通常は2048）にする方が性能劣化が多少まし。エディタを終了すると、パスフレーズを聞かれるので与える。3文字未満は不可らしい。

次に暗号化パーティションをデバイスとして認識させるためにアタッチ。

# gbde attach ad12 -l /etc/gbde/ad12

パスフレーズを聞かれるので、作成したロックファイルのパスフレーズを入力。間違えても文句を言わずに成功してしまうので注意。正しければ、/dev/ad12.bdeができる。もう一回アタッチしようとすると、今度は文句を言われる。あとは、/dev/ad12.bdeをnewfsしたり、mountしたり、やりたいほうだい。再起動したらattachをやりなおす必要がある。用が済んで、デタッチすれば、パスフレーズを知っている人しか使えない。

# gbde detach ad12

ちなみに、このad12.bdeをさらにgbdeでinit, attachすると、/dev/ad12.bde.bdeとかができあがり、2重に暗号化することもできる（が、たぶん遅くなる以上の意味はない）。setkeyを使えばパスフレーズを変更してロックファイルとロックセクタの暗号化をやり直せる。

パスフレーズを知らない、あるいはロックファイルがない状態では、ディスクを解読するのは不可能に近いが、絶対に安全なわけではない。destroyはパスフレーズを有効に保ったままマスターキーを塗り潰してしまう。nukeはマスターキーを破壊するっぽい（あやふや）。

geliの基本的な使い方

次に6.xから使えるようになったgeli。まず、乱数の鍵ファイルを作成する。

# dd if=/dev/random of=/etc/geli/ad12.key bs=64 count=1 

そして、パスフレーズを設定してパーティション内を初期化。1文字でも受け付ける。

# geli init -s 4096 -K /etc/geli/ad12.key ad12

アタッチ。

# geli attach -k /etc/geli/ad12.key ad12

パスフレーズを入力するが、間違えればエラーで教えてくれる。アタッチした時点でgeom_eli.koその他が自動的にロードされる。あとは、newfs, mountすればよい。デタッチはgbdeと同様。

比較

まず、必要な領域のオーバヘッドが違う。gbdeでは領域全体の0.8%ほどが消費されてしまうが、geliでは2KBしか消費しない。

Filesystem        1K-blocks Used     Avail Capacity  Mounted on
/dev/ad12         302732078    4 278513508     0%    /mnt
/dev/ad12.bde     300385910    4 276355034     0%    /mnt
/dev/ad12.bde.bde 298058518    4 274213834     0%    /mnt
/dev/ad12.eli     302732076    4 278513506     0%    /mnt

次に速度。暗号化なし、gbdeで2048バイトセクタ、512バイトセクタ、geliで4096バイトセクタ、2048バイトセクタのそれぞれの場合について、soft updatesなしとありで、bonnie++-1.93.03_1（bonnie++ -s 1024 -n 128 -x 3）で測定した。下の表がその結果。%CPUが99とかにはりついてI/O性能と実質無関係な列（read系やputc/getc系）は除外。Latencyも特にsoft updatesありで変動が大きいので除外。

	Sequential Output		Random Seeks	Sequential Create		Random Create
	Block	Rewrite		Create	Delete	Create	Delete
	K/sec	K/sec	/sec	/sec	/sec	/sec	/sec
normal	69588	58492	3902	2022	4458	1960	491
	64861	57344	3938	1961	4364	1987	582
	64223	57353	3939	1988	4390	1980	563
normal /soft	70279	57874	4080	26168	53044	22840	57746
	64084	57227	4081	26206	53507	23031	57089
	64229	57951	4042	26269	53261	22732	57586
bde2048	18388	24733	1233	537	1213	544	265
	20762	26431	1160	539	1227	542	290
	20208	25420	1118	536	1226	544	256
bde2048 /soft	19823	25618	1174	12536	46733	8146	52938
	17626	25727	1076	14287	41221	9214	52761
	15981	22313	1059	15025	43788	9521	51912
bde512	19234	17413	1296	421	1133	452	148
	19008	17464	1296	447	1156	448	145
	19099	17020	1300	454	1167	451	141
bde512 /soft	19094	16960	1186	11499	45933	8268	52772
	18647	17138	1178	12016	46305	10008	53334
	18872	17384	1185	12041	45969	9857	53266
eli4096	63671	56802	3829	753	1582	760	353
	62638	57836	3828	753	1581	760	497
	62221	57605	3770	754	1573	759	521
eli4096 /soft	66899	58708	3728	20798	53462	18126	56330
	59801	57577	3683	21123	53421	18530	57748
	59069	57151	3652	21010	51503	17918	57765
eli2048	65228	56823	4060	750	1580	749	576
	64113	58724	4182	752	1567	755	590
	61895	57829	4063	756	1578	753	572
eli2048 /soft	66406	58087	4036	21286	52358	18267	57784
	58373	57774	4090	21119	52487	17884	57678
	59135	57429	4071	21257	53561	17592	57969

これを見ると、gbdeでは暗号化なしに比べてスループットが3分の1以下に低下し、2048と512にも有意な差があることがわかる。これに対して、geliではcreateやdeleteで差が出るものの、writeは遜色ない速度。4096と2048にも有意な差はない。

というわけで、gbdeは忘れることにする。ただし、geliの方はgbde(4)のようなドキュメントが用意されていないので、メカニズムがよくわからないのは一つの問題。