CPUに脆弱性?

翻訳が公開されたのが今朝(土曜日朝)7時ですので緊急度は高そうです。しかし、まじですか。めちゃめちゃ深刻な話ですよ。
この記事を読む限りはシングルユーザーで使っている人には危険はないですが、サーバーの処理能力が落ちるような対策が必要となると、Opteronの脅威が増大している市場で痛恨の一撃を食らうことになります。
原因は何でしょうか。異なるプロセス空間のスレッドが同時実行されたときに互いのスレッドの情報を読める脆弱性が存在するのかもしれません。Intelのプロセッサには限定的ながらパッチを当てることが出来ます。その辺で回避できる問題なのかどうか、興味があります*1

論文を読んでみた

帰宅してお隣日記にあがっていたhttp://d.hatena.ne.jp/yukitomo05/20050513元論文へのリンクがあったので、読んでみました(上のitmediaのリンクからもたどって行けます)。要約すると、SSLのキーのような情報を元に計算を行うスレッドは、そのメモリアクセスの癖から、他のスレッドに盗聴される可能性があるというものです。直接データを盗まれる脆弱性ではありません。
Intel Pentium4Hyper Threading実装では、コア上の二つのスレッドがL1データキャッシュを共用します。これは、必ずしも二つのスレッドがキャッシュ上のデータを共有するということではありません。たとえばプロセスAのスレッドとプロセスBのスレッドが同じキャッシュデータにアクセスするわけではありません。それぞれのスレッドは同じL1データキャッシュの中から必要なキャッシュラインを排他的に使います。
どちらのスレッドがどのくらいのキャッシュラインを割り当てられるかは、それぞれのスレッドのデータアクセスパターンによって変化します。これが盗聴のキーになります。スレッドAが、短時間に広範なデータをアクセスするとL1データキャッシュの多くのラインをパージしてしまいます。このとき、スレッドBのデータキャッシュもパージされます。また、スレッドAが狭い範囲のデータしかアクセスしない場合には、スレッドBのL1データキャッシュはあまりパージされません。
この性質を使うと、スレッドAがどのようなメモリアクセスを行っているか、スレッドBはある程度類推することが出来ます。スレッドBは一定範囲のデータを規則正しく繰り返し実行します。そして繰り返し1回にかかるサイクル数を調べます。そうすると、スレッドAが広範なメモリにアクセスすればスレッドBの処理速度は低下し、スレッドAが狭い範囲のメモリにアクセスすれば、スレッドBの処理速度は向上しますので、スレッドBはスレッドAの様子を知ることが出来ます。
これによってSSLのキーを類推できる可能性があるというのが論文著者の意見です。
実験によればある程度のアクセスパターンの類推はできるようです。私にはこれで直ちにキーがもれるとは思えません。しかし金儲けにつながるならどんなコードでも開発する輩はいますから、安全ではないという意見には耳を傾けるべきかもしれません。
問題はサーバーにだけあり、クライアントは気にしなくていいとの事。

対策

論文著者は「L1データキャッシュの共有をやめろ」と設計者に忠告していますが、HTの並列数を4とか8に増やすという乱暴な方法もありますね。L2共有も原理的には問題になりうるんですが、どうでしょう。確度は低そう。ただし著者はやりようはあると思っているようです。
鍵のビットパターンとメモリアクセスのパターンの間の相関性をなくせばソフトウェアによる対策も可能です。
そうでなければHTを切れ、と。

slashdot

http://slashdot.jp/article.pl?sid=05/05/14/0153209
で、いろいろ言われていますが、いくつかおかしな意見もあります。

HTに限らずキャッシュを持っているプロセッサすべてに問題が起きうる。

こりゃどうでしょうね。HTが問題になったのは、同時にキャッシュを共有しているのが2つのスレッドという限定的な状況を極めて作り出しやすいからです。いったい幾つのスレッドが動いているのかわからなければ、読み取りは非常に困難になります。また、スレッド切り替えの間にいったい何ビット処理されるかを考えれば、2スレッドが密着しているHTとそれ以外の単純マルチタスクとの間には天と地の差があります。

SMTでなくてもスヌーピングによって問題が起きる。

スヌーピングは、すべてのキャッシュの同じアドレスのデータに一貫性をもたせる技術であり、すべてのキャッシュ内容を同じにする技術ではありません。
盗聴者と被盗聴者のスレッドは異なるプロセスで走っているはずであり、同じアドレスを共用しません。したがって、スヌーピングによるオーバーヘッド時間は問題になりません。

キャッシュ操作関数を制限すればいい

そういう問題ではありません。盗聴者はアプリケーションモードで動作していると考えられ、そもそもキャッシュ操作はしません。

*1:追記:パッチは無理です

/* -----codeの行番号----- */