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 |
|
|
||||
|
連載 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カーネルの開発体制などについて伺った |
|
|
- 【 pidof 】コマンド――コマンド名からプロセスIDを探す (2017/7/27)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。 - Linuxの「ジョブコントロール」をマスターしよう (2017/7/21)
今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です - 【 pidstat 】コマンド――プロセスのリソース使用量を表示する (2017/7/21)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。 - 【 iostat 】コマンド――I/Oデバイスの使用状況を表示する (2017/7/20)
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。
|
|