Ottawa Linux Symposium 2日目レポート
午前中のセッション
朝は、「トラステッドコンピューティングとLinux」というセッションに参加した。プレゼンタは、IBM Linux Technology CentreのEmily RatcliffとTom Lendackyの2人。頻繁に交代しながらプレゼンテーションを進めていた。
Ratcliffによると、トラステッドコンピューティングは業界のハードウェア標準である。たとえば、ピアツーピアネットワーキングでファイルを共有する場合には、ファイル汚染攻撃が起こりうる。つまり、共有されるファイルに偽のファイルを混在させ、ダウンロードを邪魔したり、使えなくしたりする攻撃が起こりうる。だが、トラステッドコンピューティングなら、理論上、これが防げる。
ユーザがローカル端末にログインするとき、事前にそのチェックをリモートコンピュータに依頼するようなことも、同じ考え方の延長線上にある。
Lendackyからは、TPM（Trusted Platform Module）の紹介があった。これは、保護機能を備えた物理デバイス（一般には暗号化コプロセッサと呼ばれるハードウェアチップ）であり、暗号鍵と署名鍵を保護する。保証鍵、ストレージルート鍵、データ保全鍵の格納には不揮発性メモリを使用し、プラットフォーム設定レジスタの格納には揮発性メモリを使用する。
再びRatcliffが立ち、TPMは一連の判定によって動作する、とその仕組みを説明した。BIOSがブートローダを判定し、ブートローダがオペレーティングシステムカーネルを判定する。オペレーティングシステムカーネルは、ソフトウェアスタックによってアプリケーションを管理する。どのレベルでも、必ず次のステップがTPMで検査され、その完全性が確認される。
ブートローダは、まずカーネルと設定ファイルを判定してから、カーネルにコントロールを引き渡すことになる。Linuxブートローダとして広く使われているgrubとliloは、現在、ともにこの機能を備えている。
Lendackyによると、カーネル2.6.12にはTPMチップサポートが組み込まれている。TPMを使用する方法は限られていて、ソフトウェアスタックを経由する方法しかない。
RatcliffからTrouSerSの紹介があった。TrouSerSとは、TPMソフトウェアスタックのコード名である。アクセス制御リストを含んでおり、管理者はこれによって、リモートユーザによるシステムAPIへのアクセスを許可/拒否できる。
プレゼンテーション後に、会場からいくつかの質問があった。最初の質問は、「TPM鍵の有効性はどう確認するのか」だった。
プレゼンタからの答えは、「ユーザがパスワードを入力する」である。だが、パスワード入力はあまり安全な方法ではない。当然、「もっと安全な方法はないのか」という質問が出た。
Ratcliffから、アテステーションと呼ばれる認証システムへの言及があった。TPMチップにはTPMチップメーカによってクレデンシャルが与えられ、システムにはプラットフォームクレデンシャルが与えられる。理論上は、その2つからアテステーションIDが得られることになるが、実際は、メーカはTPM鍵の公開側を持っておらず、そのためシステムは必ずしも意図どおりに働かない。
TPM鍵には、メーカレベルでの検証が必要である。銀行ATMや自動投票機などのトラステッドシステムでは、これが非常に重要な意味を持つ。
ext3ファイルシステム
昼食後に出席した最初のセッションは、「最新情報：ext3ファイルシステムの現状」だった。プレゼンタはMingming CaoとAlexander Dilgerの2人。
CaoがLinux/extended 3ジャーナリングファイルシステムについて語った。まだ若いファイルシステムだが、しだいに普及しつつある。ext3ファイルシステムに対しては、現在、高速化とスケーラビリティの向上を目指す作業が行われている。
2.6カーネルでext3に追加されたいくつかの新機能が紹介された。たとえば、オンラインリサイズ（ドライブを取り外さずにパーティションサイズを変更する機能）や拡張属性がある。
ファイルシステムの断片化という問題に対しては、ブロックプリアロケーションという対処方法がCaoから紹介された。この方法では、各ファイルの最終的な大きさが予測され、それに見合うスペースが事前に割り振られる。これで、ディスク上のファイルの断片化が防げる。
エクステントとその関連諸作業についても、かなりの時間が費やされた。エクステントを使えば、十分な情報が得られるまでファイルアロケーションを遅らせることができ、結果的にファイルの連続性を高められる。一時ファイルにはとくに有用な方法である。
ext3チームはext3ファイルシステムの改良を望んでいるが、Caoによると、そのためにはファイルシステムにいくつかのフォーマット変更が必要になるようだ。ファイルシステムというものの性格から、いずれそうした変更を取り入れていくとしても、変更のスピードはゆっくりとしたものにならざるをえない。
現在進行中の作業のなかには、ファイルのアンリンク/トランケートにかかる時間の削減がある。Caoが指摘するとおり、間接マッピングされた大きなファイルのトランケートは同期的な作業であり、時間がかかる。
ext3でのタイムスタンプは、最近まで毎秒約1回という頻度で更新されていて、それ以上の高精度タイムスタンプを格納する方法がなかった。カーネルは、拡張iノードにはナノ秒単位のタイムスタンプを格納できるが、通常のiノードには秒単位のタイムスタンプしか格納できない。
この問題の解決策としては、ディレクトリ操作の並列化と、個々のディレクトリにおける並行的ファイル操作の直列化が提案されている。
将来的には、最大64テラバイトというパーティションが、メインラインカーネルディストリビューションでサポートされるようになる。ext3にも大幅な改善が見込めるだろう。
Caoのプレゼンテーションは、ext2プロジェクトWebサイトにアップロードされる予定である。プレゼンテーション後にいくつかの質問があり、Alexander Dilgerがこれに答えた。たとえば、ext2とext3は実質的にまったく同じファイルシステムだそうだ。したがって、Linuxカーネル1.2には、ext3ファイルシステムをext2としてマウントできる。もちろん、ジャーナリング機能は使用できないが、ファイルサイズとパーティションサイズが通常のext2パラメータを超えないかぎりマウントに支障はない。
参加者から、12ビット→16ビット→32ビット→64ビットというファイルシステムの変遷を見てきた目には、なぜ1024ビットファイルシステムに直行しないのか不思議に映る、という声も出た。そんな巨大なファイルシステムはfsckだけで何週間もかかり、管理不能だ、というのがDilgerの答えである。
e1000はいかが
Intel社のJohn A. Ronciakが、「ネットワークドライバのパフォーマンスと測定：e1000の事例研究」という題で講演をした。
この事例研究でRonciakが目指したものは、カーネル2.6のもとでe1000ギガビットイーサネットチップのパフォーマンスを向上させることである。
調べてみると、カーネル2.4でのチップパフォーマンスのほうがカーネル2.6でのパフォーマンスより高い。設定を変えながら何度テストしても、結果は同じだった。カーネル2.6には改良の余地がある、というのがRonciakの結論である。
かつて、32ビットの33MHz PCIバスに10/100ネットワークインタフェースカードを差すだけで、入出力の過負荷が起こり、システムがダウンすることがあった。今日、最新のマザーボードで同じことをやろうとすれば、10ギガビットのイーサネットデバイスがいる、とRonciakは言う。
Linuxには、プラットフォームやオペレーティングシステムを問わずに使えるまともなパフォーマンスデータ生成ユーティリティがない。「リンゴをリンゴと比べられない」のが難点だ、とRonciakは言う。とりあえず、IXIA社のChariotというプログラムをテストツールとして使い、それで集めたというデータが出席者に示された。
それによると、データスループットパフォーマンスでは常にカーネル2.4が2.6を上回っていた。同じカーネル内では（2.4でも2.6でも）、バージョンによってパフォーマンスに大きなばらつきがあった。また、カーネルの設定オプションがNAPIかUPかでも大きな変化が見られた。
Ronciakによると、NAPIはネットワークパフォーマンス改善のためによく使われるインタフェースで、カーネル2.4でNAPIを使用すると、小さなCPU使用量で同じスループットを実現できる、と言う。ところが、Ronciakの得たデータでは、同カーネル・同スループットという条件なのに、NAPI使用時のCPU使用量のほうがNAPI不使用時のCPU使用量より大きくなった。
パフォーマンスの測定ではフレームサイズが重要だ、とRonciakは言う。フレームが大きければ、パケットで出ていくデータは十分に測定可能な量になる。だが、パケットが小さいときは、接続を通過するデータの実際量よりパケット数を測定したほうがよいかもしれない。Ronciakの映写したスライドでは、この点がわかりやすく示されていた。
Ronciakが行った初期のテストでは、NAPIを使用することでパケット損がむしろ増えたが、NAPI加重値を加減することでパケット損を減らすことができた。問題は、入力バッファのクリア速度がデータの着信速度に追いつかないことだ、とRonciakは説明する。そのために発生するパケット損であり、この問題を解決するにはドライバの変更が必要だろう。場合によっては修正可能なNAPI加重システムなどが有効だろうが、この問題についてはさらに検討が必要である。
Ronciakが発見したNAPIの問題点はほかにもある。たとえば、NAPIによるインタフェースポーリング（新しいデータがカーネルを待っているかどうかの調査）の速度が、インタフェースによる着信要求処理の速度を超えることである。このためシステムリソースの無駄遣いが生じ、動作効率が低下する。この問題の解決方法としてRonciakが提案するのは、ネットワークインタフェースの速度に合わせた最小限のポーリング遅延である。
今回の調査で1つ学んだことは、怖がらず、コミュニティにどんどん助けを求めることだ、とRonciakは言う。コミュニティに呼びかけることで、テスト自体が簡単に運んだし、バグ修正やパッチや改良点のコーディングも容易だった。これだけは声を大にして伝えておきたい、と言っていた。
これからもLinuxにおけるネットワークパフォーマンスの向上に取り組んでいきたいし、NAPIの改善にも努力したい、とRonciakは結び、ぜひ協力を、と呼びかけていた。
プレゼンテーションの最後にRonciakが繰り返したことは、プラットフォームを選ばないフリーで標準的な測定ツールの必要性である。ネットワークパフォーマンスのボトルネックを新しいハードウェア機能で解決できないか、とも考えているので、ぜひ手助けを、と言っていた。
夜のBOFセッションで
夜のBOFセッションでは、国家安全保障局（NSA）のStephen SmalleyがNSAのSELinuxカーネルについてその現状などを語った。
SELinuxにとって昨年は重要な年だった、とSmalleyは言う。SELinux自体は、1年前のFedora Core 2リリースにすでに含まれていたが、デフォルトでは有効になっていなかった。だが、Fedora Core 3とFedora Core 4では、SELinuxが含まれるだけでなく、デフォルトで有効に（有効状態で出荷されるように）なった。
また、スケーラブルになり、大規模なマルチプロセッサシステムにも適合するようになった。現在、IBM社がSELinuxの評価を進めており、いずれ米国政府による使用も正式に認められるかもしれない。
SELinuxでは、複数カテゴリにまたがるセキュリティシステムの可能性が探られていて、システムのセキュリティポリシーに対するユーザの参加度が高まる、とSmalleyは言う。
2006年3月に、メリーランド州ボルチモアでSELinuxシンポジウムが開かれる。SELinuxの実像を探るにはよい機会となるだろう。
原文
