5月版 Firefoxのプチフリーズ問題から始まった大論争


小崎資広
2009/6/1


さらばorderedモード、ext3のデフォルトがwritebackモードに変更

 最後に話題に上ったのがordered mode自体の仕様についてです。

 Linusいわく、「上述のブロックレイヤの改善でだいぶ速くなったけれど、まだ足りない。そもそも現代において、ordered modeは適切なデフォルト値なのか」と問い掛けました。

 従来ordered modeは、クラッシュ時にinodeが不正なブロックを参照していることがないことが保証されているため、セキュリティ上好ましいとされていました。writebackでは、消したデータがなぜか復活してしまい、第三者に閲覧可能になってしまう事態が起こり得るからです。

 しかし、ハードウェアの値段が下がった結果、世の中のLinuxシステムの99%はマルチユーザーでは運用されていません。自分のデータが自分から見えるだけならば、セキュリティリスクではない、というわけです。

 この提案にはさすがに賛否両論巻き起こりましたが、「マルチユーザーを想定する必要があるエンタープライズ系ディストリは、自分でデフォルト設定を変えたらいいだろう」ということになり、コミュニティカーネルとしてはext3のデフォルトはwritebackに変更されました(注3)。

 これで、fsync()で関係ないファイルの書き込みまでも待ってしまうという上述の問題は起こらなくなります。

 個人的見解では、Ted Tsoがこの提案を行うに至った背景には、ext4への移行支援という側面があると思っています。ext4ではdelayed allocationがあるため、fsync()を適切に使わない場合のデータロストリスクが上がっています。しかし、ext3のfsync()が遅過ぎるのでfsync()をサボっているアプリケーションがなくなりません(注4)。これではext4の移行ストーリーが崩れてしまいます。

 もちろん理想は、「アプリケーションは正しくfdatasync()を使う、カーネルはカーネルで最大限信頼性を確保する」ということなのでしょうが、fsync()/fdatasync()/sync_file_range()の正しい使用を啓蒙(けいもう)するには、このぐらいの荒療治が必要なのかもしれません。

注3:ext4のデフォルトはordered modeのままなのでご注意を
注4:fdatasync()もしくはsync_file_range()を適切に使うことでほぼ回避できるのですが、fsyncとfdatasyncの速度差は一般にはあまり知られておらず、fdatasyncの利用はとても少ないのです

お前のページを共有する、抵抗は無意味だ――KSM

 KVMなどの仮想化環境において、ゲストの使用メモリを劇的に節約する新機能が、KVMデベロッパーたちにより提案されました。その名も「KSM(Kernel Shared Memory)」。Xen対抗の切り札です。

 この機能は、複数のゲストOSのうち内容が同じメモリを(半ば無理やり)共有使用してメモリを節約するという、OSの根幹動作を変えてしまう無茶なドライバです。

 従来のカーネルでは、fork時には親子でページの共有がされますし(COW)、同じファイルを複数のプロセスがmmapしたときも共有されています。しかし、まったく関係ないプロセスがまったく関係ないファイルを開いていた場合は共有されていませんでした(まあ、当たり前ですね)。

 ところが、多数のゲストOSを起動した場合、OSイメージは全部違うファイルを使うにもかかわらず、実際に起動するOSは全部同じバージョンということがよくあります。そんな場合は実は、よくよく調べると同じ内容のページがいっぱいある、というわけです。

 では、このパッチがどのように動くのかを説明しましょう。提供するインターフェイスは極めて簡素で、/dev/ksmという仮想デバイスが1つと、そのデバイス用のioctlが4つほどあるだけです。

 ゲストOSとして起動したQEMUは、最初に自身のメモリを共有可能であると/dev/ksmに登録します。すると、ksmスレッドがバックグラウンドで定期的にページをスキャンし、それぞれのページのハッシュ値を計算していきます。ハッシュ値が同じものが見つかったらmemcmpで内容が一致するかを確認し、本当に一致していたら、両方の参照元のpteが同じpageを指すよう書き換えかつリードオンリーにしてしまいます。

 これで、参照元プロセスがページの内容を変更しようとしたタイミングでページフォルトが発生し、通常のfork時のCOWと同じように共有解除がされるというわけです。

 Izik Eidusによれば、16GBのメモリを持つサーバ上に、それぞれ1Gbytesのメモリを使用するWindows XPが52インスタンスも同時稼働可能とのこと。つまり、実メモリの3倍のメモリサイズのゲストを走らせることができるわけで、これは大きな魅力です。

 彼によれば、Windowsではゼロページスレッドがフリーメモリを積極的にゼロクリアするため、大量のゼロページが発生する傾向があり、それも共有率を上げているのだそうです。

 このパッチはゴールデンウイーク前後に-mmツリーにマージされ、現在テストされています。順調に行けば、2.6.31でお目見えするはずです。

-stableの進ちょく

 2.6.29.3ではいくつかのセキュリティ問題が修正されています。特に強い理由がない限りは適用するべきと思われます。

 面白かったネタとしては、POSIX capabilityのFSMASKの定義を修正した際、「Linux 2.1でケーパビリティを入れたときのregressionで……」と説明されたので、周りから「えー、何でいままで分からなかったの?」とどよめきが発生したことでしょうか。Linusが「誰もケーパビリティを使っていなかったからじゃね?」とちゃかす一幕もありました。

■2.6.29.y:

  • 2.6.29.2(4月28日):Chris Wright
    ・alloc_cpumask_var_node()によるslabのメモリ破壊を修正
    ・hrtimer:rq->lockの逆転を修正
    ・POSIX capabilityのFSMASKの定義にCAP_MKNOD、CAP_LINUX_IMMUTABLEが含まれておらず、例えばNFS上でmknodしたときにおかしな結果になることがある問題を修正
    ・ext4:ソフトロックアップハングを招くtypoを修正
    ・/proc/sys/vm/drop_cachesのキャッシュ破棄とprune_icache()がレースすることにより、カーネルがパニックする問題を修正
    ほか、100パッチ
  • 2.6.29.3(5月9日):Greg K-H
    ・compat_net=1のとき、selinux_ip_postroute_iptables_compat()がnode、portのチェックをしておらず、ローカルユーザーがネットワークのセキュリティ設定をバイパスできる問題を修正(CVE-2009-1184)
    ・bio_copy_user_iov()のメモリ破壊を修正 ・clone(CLONE_FILES)によって共有されたfile_structはexec()時に解除されなければならないが、32bitプロセスを64bitカーネルで動かしたときのexec()で、それを行っていなかった問題を修正
    ・setuidプログラムがroot euidを取得できないことがある問題を修正
    ・非特権ユーザーが/procから他プロセスのEIP、ESP、WCHANを読み取り可能なため、アタッカーがアドレス・ランダマイゼーション(ASLR)を迂回(うかい)できてしまう問題を修正
    ・/proc/meminfoのCommitted_ASフィールドがアンダーフローすることがある問題を修正
    ・hugepageに対するmadvise(MADV_WILLNEED)を無視する
    ・プロセスがCAP_KILLケーパビリティを持っていた場合に、exit_notify()がシグナル送信のサニティチェックを迂回するため、ローカルユーザーがtask->exit_signalフィールドを書き換えた後setuidアプリケーションを起動することにより、任意のシグナルを送信可能な問題を修正(CVE-2009-1337)
    ・2つのexec()のレースにより、fs->in_execが不正にクリアされてしまう問題を修正
    ・x86_64:シグナル配送パスにおいて、FPUが壊れてしまう可能性がある問題を修正
    ほか、59パッチ
  • 2.6.29.4(5月20日):Greg K-H
    ・epoll_create()のsize引数チェックの修正
    ・dup2のoldfdとnewfdに同じfdを渡したときに正しく-EBADFを返さない問題を修正
    ・デバイスサイズが2Tbytesを超えたときに発生するビットマップ管理の障害を修正
    ・btrfsでpage_mkwrite()とtruncateのレースが起きるとSIGBUSが発生する可能性があった問題を修正
    ほか、51パッチ
2/2

Index
Linux Kernel Watch 5月版
 Firefoxのプチフリーズ問題から始まった大論争
  Page 1
 それはFirefoxのプチフリーズ問題から始まった
Page 2
 お前のページを共有する、抵抗は無意味だ――KSM
  -stableの進ちょく

連載 Linux Kernel Watch


 Linux Squareフォーラム Linuxカーネル関連記事
連載:Linux Kernel Watch(連載中)
Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
連載:Linuxファイルシステム技術解説
ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
特集:全貌を現したLinuxカーネル2.6[第1章]
エンタープライズ向けに刷新されたカーネル・コア
ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
特集:/procによるLinuxチューニング[前編]
/procで理解するOSの状態

Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
特集:仮想OS「User Mode Linux」活用法
Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール/管理方法やIPv6などに対応させるカーネル構築までを徹底解説
Linuxのカーネルメンテナは柔軟なシステム
カーネルメンテナが語るコミュニティとIA-64 Linux
IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します


Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Linux & OSS 記事ランキング

本日 月間