![[book image]](data/20040930/4-8399-0930-X.jpg) |
[→
書籍情報] [→ amazon.co.jp] [→ cbook24.com] [→ 関連する日記のエントリ (09/24)] |
LAST MODIFIED: 2005/06/11 17:09:02 UTC
不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。
|
[→
書籍情報] [→ amazon.co.jp] [→ cbook24.com] [→ 関連する日記のエントリ (09/24)] |
無理矢理スケジュールをあけたしわ寄せが。
HTT の弱点の s/convert/covert/ という誤字修正。 convert してどうする。
気づいたらもう 5 月。とりあえずまだ生きてます。
5.x で変わった部分の注釈や加筆に加えて、 「正誤表がほしいです」というご意見もいただいています。 ちゃんとサポートページをつくらなければならないのですが、 どうにもまとめている時間がとれなくて進んでいません。 来月までには、何とか時間をとって進めようかと思ってます。
加筆分はとりあえず rc.d, GEOM, portupgrade について準備中です。
無理矢理スケジュールあけて行ってきました。
5/11-12 は FreeBSD devsummit 参加。rwatson の SMPng 話や scottl の FreeBSD 6.0 話を聞きつつ、これからどうする、 みたいな話で盛り上がる。 Dan がケーキつくったぜ、と持ってきたのがこの写真。 みんなで食べる。
BSDCan では、まず cperciva の話を聞く。写真はちと暗いけど壇上の cperciva 本人 とスライドの一部。
簡単にまとめると、
HT では 2 つのスレッドがキャッシュを共有している。 また、キャッシュへのアクセスで特権のチェックはおこなわれない。
片方のスレッドでメモリ領域を広範囲にわたってスキャンすると、 データがキャッシュにあるかどうか、読み出し速度の差から調べることができる。
というもの。この原理を使うと、片方のスレッドからもう片方のスレッドにデータを送る ことが可能になる (この通信路を cperciva は covert channel と呼んでいる)。 exploit する方法にはいくつかあり、ページングを使うもの (たとえば大きなファイルを参照している場合) と、 L1/L2 キャッシュを経由するものが紹介された。キャッシュを使うものは、 1Mbps 以上でデータを送る (というか盗む) ことができる。
また、実例として OpenSSL への攻撃が紹介された。1024-bit の RSA 処理をおこなう場合、ライブラリ内部では 512-bit の素数 2 個に対して、 2 乗と乗算の処理がおこなわれる。 この 2 乗と乗算の処理がいつ、どのメモリに対しておこなわれているのかは、 実はキャッシュの使われ方を調べることで判明する (このへんは論文に詳しい図入りで説明されている)。 スレッドでその処理が実行されている時に、隣のスレッドから鍵データを盗み出せば、 攻撃成立というわけだ。cperciva の示した exploit 方法では、512-bit の素数のうち 310 ビット前後を同定することが可能。
もちろん、影響を受けるのは RSA 暗号や OpenSSL の実装だけではなく、 キャッシュの利用パターンが入力に依存しているものであれば exploit できる可能性がある (もし、アプリケーションやライブラリが 入力に依存しないキャッシュ利用パターンになっていれば、 どのメモリにアクセスしているのか同定することができないので、危険性は低くなる)。
この影響が HT だけにとどまるかというと、実はそうではないのでご注意。 多くの OS では、context switch 間でキャッシュをフラッシュしたりしないので、 L1 キャッシュや L2 キャッシュに、その直前に実行していたコードのメモリアクセスの痕跡が 残っている可能性が高い。HT と比べると exploit は困難だが、 原理的には同じ手法でメモリアクセスを同定することができる危険性があるからだ。
この弱点は CPU の構造に由来するもので、FreeBSD に依存しているわけではない。 根本的な解決には、たとえばスレッド単位で個別のキャッシュを実装するなどの対策が必要になるが、 OS 側で HT を意識したスケジューラを実装して、スレッド実行時に credential をチェックする (異なる credential のコードを同時に実行しない)、 あるいはカーネル内部の暗号関数が、入力に依存しないキャッシュパターンを生成するように 改良するという方法も考えられる。
いずれにしても、ソフトウェア的にどこか一点を改善すれば OK というものではない悩ましい問題。 たとえばリモートログインのサービスを提供している SSH サーバ とか、 SSL と CGI に対応したウェブサーバなどが影響を受けるので、 HT を無効にしてしまうのが最も確実だろうというお話。
次は rwatson の話。SMPng の概要と、network stack の lock について。 「SMP は "make it work" が終って "make it work faster" の段階にあり、 どうやって最適化していくかが課題」という話。 kris が最近出したベンチマークでは、 VFS が Giant free になって以降は scalability がかなり改善されたことが実証されており、 今までの苦労はきちんとむくわれております。 lock primitive のオーバヘッドが CPU やアーキテクチャによってたいぶ違うので、 そのへんをどう扱うのかが難しい。
synchronization の方法は今でもいろいろと検討しているところで、 DFly の serialization by thread や serialization by CPU なんかも、適材適所で採り入れていくことになるでしょう。
次は sam の WiFi 話。実装がどうなっているのかにはあんまり注目してなかったのだけど、 概要からしっかり話してくれたので勉強になった。他のプロジェクトとも協調して動いていて、 先のみとおしもしっかりしてる。すばらしい。
初日最後は kris の package cluster の話。こんな風に build してるよ、 というのを統計を交えて説明。i386 の場合、2300 分前後で 10000 ちょいのパッケージをつくることができる。 その時間の半分以上を占めるのが OpenOffice. SMP では md を使うと build 効率がかなり良くなるとのこと。 その後、ports BoF があってセキュリティブランチつくるのはどうよとか、 pkgsrc にあるクロスコンパイルはー、とか、distcc とか ccache を使うこととか、 いろいろ話が出る。
初日終って飲みに行く。左写真は左から rwatson, scottl, simon。あと dwhite (中写真), nectar (右写真), その他がいたけど、 同じ側に座ってたので写ってない。
3 時間ほどおしゃべりして解散すると、パラパラと雨が降ってくる。 寒い中 (昼間は 16-20C くらい、夜中は 0C くらいまで下がる) をホテルまで歩く。アメリカ大使館とか国会議事堂がすぐ近くにあるところだからかも 知れないのだけど、23 時にひとりでうろうろしても、 まあそんなに危険すぎるわけではなさそう。21 時までは明るく、 飲食店やスーパーはだいたい 21-23 時まで。
2 日目。スケジュールの都合で参加できないので、朝に出発。 あわただしい日程だったけれど、十分おもしろかったというのが素直な感想。 規模は見た感じ 200 人前後。USENIX の BSDCon はやらなくなってしまったので、 BSD 系のソーシャルなイベントとしては、EuroBSDCon と並んで定着しつつある感じ。 来年も 5 月に開催が決定してます。
LAST MODIFIED: 2005/06/11 17:09:02 UTC