6月版 怒りのLinus、「カーネル開発者のふりはやめろ」


上川純一
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
2006/6/28

カーネルメモリリーク検出パッチは有用?

 Catalin Marinasは、Linuxカーネル内部でのメモリリークを検出するデバッグオプションを追加するパッチを提案しました。このパッチは、ガベージコレクションの仕組みを利用して、メモリリークを検出します。valgrindのmemcheck --leak-checkツールと同様の機能を提供することを目標としているようです。

 しかし、Andi Kleenはこのパッチの有用性に疑問を呈しました。これに対してIngo Molnarは、「簡単に見つかる問題は、すでに非公開のツール(Coverity)によって発見されて修正済みなので、Catalin Marinasのパッチの有用性が必要以上に少なく見えてしまう。しかし、Coverityが調査対象としていない各自が持っている開発用のツリーや特殊なアーキテクチャ、ドライバには有用だよ」と擁護しました。

 このパッチは急速に改良を重ね、実際にいくつかのメモリリークを検出しているようです。ただ、一部のパターンについてはメモリリークを誤検出するという報告があります。Catalin Marinasは、その対策も提案しています。

 メモリリークを検出するデバッグオプションがカーネルに入ることで、今後のカーネルの品質が向上するとよいですね。

vsyscall領域の固定がセキュリティリスクを高める?

 Gerd Hoffmannは、「vsyscall領域を移動する」というパッチをLKMLに投げました。

 Linuxカーネルでは、システムコール(int $80)やsysenter()の発行を通常のライブラリ関数呼び出しで実現します。この関数呼び出しをvsyscallと呼び、vsyscallに必要な関数群をユーザー空間のアプリケーションに提供する仕組みをVDSO(Dynamic Shared Object)と呼びます。一部のアーキテクチャの時間関数などは、高速化のためカーネル空間に切り替わらず、vsyscallのみで実現しています。

注:従来はglibcがint $80を発行していましたが、Pentium 4ではint $80よりもsysenterを使う方法が高速でした。ただし、ほかのCPUでは逆に遅かったり、実装されていなかったりします。

 なぜvsyscall領域を移動する必要があるかというと、XenなどのHypervisorが仮想メモリ空間上の固定したアドレスにメモリ領域を確保しようとすると、vsyscallが固定的に利用している領域と衝突してしまうからです。

 この議論が盛り上がったのには別の理由もありました。vsyscallが確保するメモリ領域のアドレスはすでに知られており、セキュリティ攻撃の対象の1つになっているようなのです。そのため、vsyscallを移動できるようにすることでアドレスを予測不可能にしたいというわけです。

 カーネルに変更を加えることでvsyscallのロードアドレスをランダムに変更することは可能なのですが、その結果「Fedora Core 1が起動しなくなる」とAndrew Mortonが報告しました。glibc 2.3.2のld.soは、VDSOがリロケーション可能な場合に対応できないらしいのです。「Fedora Core 1は古いし、ユーザー空間のバグなのだから無視してもよいだろう」という意見も出ましたが、Linus Torvaldsはそうした意見に対して「ユーザー空間の互換性が重要だというのが分からないのであれば、カーネル開発者のふりをするのはやめて、例えばHurdみたいなおもちゃシステムの開発者になった方がよい」と制しました。

sched_clock()による時間計測に注意

 短期間の処理に要した時間を計りたいという場合はよくあります。細かい時間で更新される時間カウンタとしては、sched_clock()という関数が使えます。例えば、以下のような用途が考えられるでしょう。

        unsigned long long t0, t1, time_passed_ns;

        t0 = sched_clock();
    /* 時間を計りたい処理 */
        t1 = sched_clock();

        time_passed_ns = t1 - t0;

 実は、上のコードは間違っているとRussell Kingは指摘しました。例えば、x86ではTSCレジスタを利用しており、TSCレジスタの値は64bitです。sched_clock()はその値を加工してナノ秒に変換しているのですが、結果として精度は54bitになります。また、ARMではこれが32bitしかありません。これは何を意味するでしょうか?

 時間の経過とともに数字が増えるわけですが、ある時点で「0」に戻ります。それを64bitの変数の演算として見ると、突然長い時間が過ぎてしまったように見えます。この解決策の1つとして、彼は差分を計算する専用の関数sched_clock_diff()を定義することを提案しました。すると、そもそもsched_clock()をナノ秒で提供するように加工する必要がなくなります。また、SMPでは同期していない場合もあるので、TSCレジスタを汎用として利用するのは好ましくない、とNick Pigginがコメントしました。

 この状況はあまり良くないことではありますが、あまり文句も出ていないため「このコードを利用している部分はあまり存在しないのだね」という結論に達して、結局何も修正はなされていないようです。

 sched_clock()を利用する場合はご注意を。

-stableリリース、今月も大忙し

 5月は合計で8つの安定版リリースが出ました。4月ほど多くはありませんでしたが、セキュリティ対応のために緊急リリースされたものもいくつか見られました。順調にリリースされているということで、安定版が安心して利用できるのはよいことですね。

 頻繁なリリースについての意見もありました。「本当は2.7ツリーが必要なのだろう」(Nigel Cunningham)、「LinuxにPR部門があったなら、火曜日までリリースは待っただろう」(Ioan Ionita)といった冗談が飛ぶ場面も。一方、Willy Tarreauはまじめな意見として、「2.4のツリーではまだホットフィックスが追い付いていないが、それに比べて安定版のツリーには数日遅れでセキュリティホールへの修正がなされており、良いことだ」とコメントしました。

  • 2.6.16.12(5月1日)
      ・浮動小数点用レジスタのプロセス間での情報漏えいの問題修正時の間違いの修正
      ・MIPS向けのいくつかの修正
      ・PAEの場合のpte_clearの修正
    など、25パッチ
  • 2.6.16.13(5月2日)
      ・Netfilter SCTP connection trackingのセキュリティフィックス(CVE-2006-1527)
  • 2.6.16.14(5月5日)
      ・smbfs上でのchrootに関するセキュリティフィックス(CVE-2006-1864)
  • 2.6.11.15(5月9日)
      ・SCTPのセキュリティフィックス(CVE-2006-2274)(CVE-2006-2275)(CVE-2006-2271)(CVE-2006-2272)
    など、4パッチ
  • 2.6.11.16(5月11日)
      ・ファイルロック関連のロックアップの修正(CVE-2006-1860)
  • 2.6.11.17(5月20日)
      ・SCTPのセキュリティフィックス(CVE-2006-1857)
      ・SCTPのセキュリティフィックス(CVE-2006-1858)
      ・Netfilterのセキュリティフィックス(CVE-2006-0039)
      ・ptraceのデッドロックの修正
    など、23パッチ
  • 2.6.11.18(5月22日)
      ・NetfilterのSNMPのNATのセキュリティフィックス(CVE-2006-2444)
  • 2.6.11.19(5月31日)
      ・NetfilterのIPコネクションとラッキングのセキュリティフィックス(CVE-2006-1343)

(以上、敬称略)

2/2

Index
Linux Kernel Watch 6月版
 怒りのLinus、「カーネル開発者のふりはやめろ」
  Page 1
 LILOに潜む「255文字制限」のナゾ
 デッドロックを探せ!
Page 2
 カーネルメモリリーク検出パッチは有用?
 vsyscall領域の固定がセキュリティリスクを高める?
 sched_clock()による時間計測に注意
 -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 記事ランキング

本日 月間