ハイパースレッディングに深刻な脆弱性が報告される 123
ストーリー by GetSet
エンコ時以外は切るかな 部門より
エンコ時以外は切るかな 部門より
ｃｃｋ曰く、"ITmediaニュースの記事によれば、
FreeBSDプロジェクトでセキュリティを担当するコリン・バーシバル氏より、ハイパースレッディング(HT)の脆弱性に関する論文がオタワで開催された「BSDCan 2005」に提出された、とのことだ。(参考：Hyper-Threading Considered Harmful)
具体的には、HTの脆弱性が原因でローカル情報が流出する可能性があり、権限を持たないユーザがRSA非公開鍵を盗み出せてしまうのだとか。
この問題について、現時点でIntelからの情報は無いとのことだ。"
2003年に発見済 (スコア:4, すばらしい洞察)
FreeBSD-securityに流れたメール [freebsd.org]にありますが、Sunは2003年の時点で、SMTに対して本質的にこの手口による攻撃が可能なことを発見しています。また、キャッシュの挙動によっては、SMTを使用していなくても攻撃可能だそうです。
何だか、「CPUにキャッシュが載っているために、どこを実行しているかがバレてしまう」ことがガンのように思えてきました。これが正しければ、およそ今の世の中に出ているCPUは全てアウトなんですが...
発見済かどうかよりも実行効率が問題 (スコア:5, 参考になる)
従来からSMPやUPでも可能ではあったが、HTTではそれが「理論的にはできる可能性がある」から「確実に盗聴できる」と実現可能性が昇格してしまったことが問題のようです。
The fundamental trouble is that HTT makes the spying far more efficient than it is with SMP or even UP (I think we are talking in the order of a million times more efficient).
That takes the attack from the "if you were really lucky" to the "almost always in first try" category.
Re:2003年に発見済 (スコア:4, すばらしい洞察)
もっともそうなると今のCPUとの互換性はどうすんねんという話になるわけですが。
あとどうでもいいけど、タレコミ文の
＞権限を持たないユーザがRSA非公開鍵を盗み出せてしまう
ってのは
自分以外の、権限を持たないユーザにRSA秘密鍵などの重要な情報を盗み見られてしまう
のほうがよい気がした。
-- Takehiro TOMINAGA // may the source be with you!
Re:2003年に発見済 (スコア:2, 参考になる)
Kernelにexploitを仕込まれたらゲームオーバーじゃないですか? 攻撃するだけなら別にuserlandにこだわる必要はないんだし。
phkが言っている
ってのを防ぐには... 彼自身は「HTTは同一プロセス内でのみ使用する」と考えてますが、in-kernelなcrypto codeを使用していると(IPsec等)、やはり甘そうです。CPUの実行ユニット間でキャッシュを共有するという考え方がそもそもの欠陥なのでは? 基本設計に落とし穴があるのであれば、互換性は二の次でも良さそうですけど。
Re:2003年に発見済 (スコア:1, 参考になる)
すみません、これもう少し詳しく説明してもらえないでしょうか？
このHTT holeは同時に走るhyperthreadの片方が、もう一方のhyperthreadの走行によって起きるキャッシュ内容の変動を（自分の発行する命令の実行時間によって）間接的に調べることができる。そして、キャッシュに残されている変動パターンは相手が実行した命令によってそれぞれ異なる、というのがベースになっているものだと思いますが、違うでしょうか？であれば同じ owner/process の下にあるhyperthreadが同時走行するように変更することで解決するのでは？
http://www.daemonology.net/papers/htt.pdf
Re:2003年に発見済 (スコア:0)
「in-kernelなcrypto code」の条件では、FreeBSDは危険でも、NetBSDは安全ということですか？
Re:2003年に発見済 (スコア:1, すばらしい洞察)
Kernelにexploitを仕込まれるような状況になった時点ですでにゲームオーバーだと思いますが
Intel 迷走中？ (スコア:4, すばらしい洞察)
RDRAM導入失敗あたりから始まって、数々のリコール、スピードグレード導入、64bit拡張での敗北、偽デュアルコア、そしてHTTセキュリティホールと散々。
> The correct (technical) workaround (IMO) is to restrict HTT to be used only for threads from the same process.
>
> The political problem is that if all operating systems do that, Intel has a pretty dud feature on their hands, and they are not particularly eager to accept that fact.
この辺 [freebsd.org] を見て思ったんですが、元々Intelの技術的戦略は
- アプリケーションにはスレッド化してもらい
- スレッド実行効率を高めて
- 各スレッドを高速実行できるようにクロックを上げ
- それに対応して高速なメモリ規格を導入
をセットで行うことで対 AMD 戦やってたはずですが、ほぼ全面的に敗北かケチがついた状況に見えます。
Intel の強いところは切り替えの速さ（PentiumM とか）と生産能力と周辺チップ・規格含めた部分まで展開・マーケティングができる点なので市場での地位は揺るいでないものの、CPU/chipset に関してはx86 互換メーカ + サードパーティ chipset ベンダ連合が互角の地位まで完全に上がってきましたね。かつては
AMD はオフィスアプリでは互角でも総合的に Intel に劣る
とか
AMD の CPU はよくても chipset が屑
とかいわれてたもんですが…
Re:Intel 迷走中？ (スコア:1)
AMD とか Transmeta とかはパチモンという
多数派の評価は動かない。
Intel マーケティングの勝利。
でも中に何が入っているのか知らない、
というか、知りたくもないユーザが
増えればこれも変わってくるでしょうね。
閾値は 0 で
Re:Intel 迷走中？ (スコア:2, 興味深い)
理由がＦＰＵを使う計算の重要度が上がったからで
した。
昔は、オフィスアプリなどでは問題ないけど、
計算をさせると速度が段違い（に遅い）という評判
でしたが、最近は浮動小数点計算も同じレベルくら
い速くなってるんでしょうか？
これもまた、過去実績による、イメージですね。
Re:Intel 迷走中？ (スコア:1, 参考になる)
>速くなってるんでしょうか？
初代のAthlon(K7)の時点で、FPU性能はPentiumIIIを抜いてます。
SSE2の使用を主眼に置いた設計故ですけど、FPUに関して言えばPentium4はPentiumIIIから退化していますね。
>これもまた、過去実績による、イメージですね
K7の登場が99年ですから、ちょっと引きずってるイメージが古すぎますね。
Re:Intel 迷走中？ (スコア:1)
マルチプロセッサにすると差が出るかも。
Re:Intel 迷走中？ (スコア:1, 興味深い)
まんまと乗せられて上っ面で選んできた結果が
まさにその 「Intel マーケティングの勝利」 なのではないでしょうか。
Re:Intel 迷走中？ (スコア:2, 興味深い)
サーバは数値演算用途にかなりOpteronがのしてきつつあるのでおいておくとして、
NECは一般向けPCとしてAthlon64をかなり持ち上げてきたし
ビジネス用途としてもHPが「Xeonでは足らぬはこのぬるぽメーカー共が！」
という市場向けにOpteronワークステーションを出してきたりするので
少しずつではあるが風向きは変わりつつある。
＃あとはDELLがOpteron採用してくれればいいのだが・・・
Re:Intel 迷走中？ (スコア:1, 興味深い)
足りないねぇ。SPICEシミュレーションで12日とかいう話になると。
あるSPICEシミュレーションでXeonで3日かかったシミュレーションが
Opteronで1.5日とかいう結果を出して、
ほかのシミュレータでも回路のシミュレーションを行うなら
やっぱり同じ傾向がでるらしい。
新しく導入する機器はXeonからすべてOpにする事になりますた。
Re:迷っているんですよ。(オフトピ (スコア:0)
マイクロコードのパッチで対応できるのか？ (スコア:2, 興味深い)
まあ、本当にそれで直したら、立派だけど。
ＣＥＬＬでは (スコア:2, 参考になる)
デスクトップPCなどのシングルユーザーシステムは影響 (スコア:1, 参考になる)
それよりも論文にはaffect systemとして FreeBSD/amd64が
あがっているのが不安。Intelだけじゃないのか?
SCOは対応早くてgood job!
#部門名からすると、サーバでエンコという発想のひともいるんだね
Re:デスクトップPCなどのシングルユーザーシステムは (スコア:3, 参考になる)
> あがっているのが不安。Intelだけじゃないのか?
FreeBSDではamd64というアーキテクチャ名でEM64Tに対応しています。
OpteronやAthlon 64にこの脆弱性があるということではないと思います。
Re:デスクトップPCなどのシングルユーザーシステムは (スコア:1)
一人で使ってればシングルユーザーだとは言えません。なぜなら、別のユーザーの権限で動いてるプログラムも存在しないとは言えないからです。
もしその別ユーザー権限で動いてるプログラムにリモートから実行可能な脆弱性があれば、今回の脆弱性を利用して"ローカルから"攻撃を仕掛ける事が可能です。
ローカルからしか攻撃できない脆弱性でも、他のリモート攻撃可能な脆弱性と組み合わされば、それも実質リモート攻撃可能な脆弱性になるということです。
しかしハードウェアに脆弱性って……どういうことなのか、どう対処すればいいのかよくわからんな……。
マルチコアプロセッサも同じ脆弱性がある？ (スコア:1, 興味深い)
Re:マルチコアプロセッサも同じ脆弱性がある？ (スコア:5, 参考になる)
＃都度キャッシュクリアすれば良いのでしょうが、そのことで別の形のヒントを与えないかを検証する必要があります。
またデュアルコアや SMT でなくても Hyper Transport を介して継った複数の Opteron の様にローカルのキャッシュミスよりはリモートのキャッシュヒットの方は速い場合は、キャッシュの使われ具合を他プロセッサから推定される可能性は出てくると思います。
今回の脆弱性を観ると、CELL の設計って暗号向きですね。
対策ソフト登場の可能性は？ (スコア:1, 興味深い)
今回の問題の対策ソフトをリリースできる可能性はあるので
しょうか？
そんなレベルの問題ではないのでしょうか。
Re:対策ソフト登場の可能性は？ (スコア:2, 参考になる)
というのを追加してるようですね。
このパッチにより、通常のシステムではHTTが無効になります。
本当にシングルユーザでしか動かさず、
ネットワークにつながっていないことが保証されるのであれば、
sysctlでHTTを有効にするということも出来ます。
ソフトで出来ることと言えば、このハードウェア(HTT)を使うとまずいということなので、
ソフト側から認識せず、有効化しないということでしょうね。
ハードウェアの"管理"はOS=kernelのお仕事ですから、kernel側での
対処しかできないと思います。
userlandのシマンテックには何も出来ませんね。
# さてマイクロソフトはどう出るのか
『深刻』という表現は妥当なのかしら？ (スコア:1)
# 脆弱性の危険度の修飾語彙(深刻、とか潜在的な、とか)には、
# それ固有のイメージがある、と思うのですが、どんなもんでしょう？
intel入ってる = DRMぶっこ抜き放題？ (スコア:0)
2chスレ [2ch.net]より。
＃きじゃくせいてのは脆弱性の2ch用語な。
Re:intel入ってる = DRMぶっこ抜き放題？ (スコア:1, 興味深い)
秘密鍵を盗むこともできてDRMも回避できてしまうのでしょうか？
例えばCellはセキュリティを保持するためにコアとローカルキャッシュだけで閉じた
演算を行うことができるという話を聞いたことがありますが
Cell自体のエミュレーションを行われたら
仮想Cellとめて仮想ローカルキャッシュ覗き放題？
だれか、世の中そんなに甘くないと言って下さい。
Re:intel入ってる = DRMぶっこ抜き放題？ (スコア:0)
Re:RSA非公開鍵？ (スコア:1)
Re:RSA非公開鍵？ (スコア:1)
「暗号」の対義語が「復号」、
「暗号化」の対義語が「復号化」だが。
# でも「暗号通信」の対義語は「平文通信」だな。
# 「プラス」の対は「マイナス」だったり「ゼロ」だったりする
Re:RSA非公開鍵？ (スコア:1)
# どうしても「化」が使いたいなら平文化でいいんじゃない？
Re:RSA非公開鍵？ (スコア:0)
Re:RSA非公開鍵？ (スコア:0)
暗号はバイト列だけど、復号は操作なので
対義語としてしまうのはちょっと抵抗があるな。
Re:RSA非公開鍵？ (スコア:1)
申し訳ないけど…。なるほど、
cipher(暗号技術？ RSA cipher とか),
cryptogram(暗号化されたデータ),
encryption(暗号化操作)とあって、
それぞれの対義語が、特にない、平文、復号化、
になりますね。
Re:RSA非公開鍵？ (スコア:0, フレームのもと)
復号化というのは（今のところ）誤用．あえて言うなら平文化．
普通に言うと復号．
#将来的には変化するかもしれんですけど．
Re:RSA非公開鍵？ (スコア:1)
「化」を付けると、暗号を元に戻すことに化かす、というわけのわからんことになる。
暗号化は、（平文を）暗号に化かすわけだから、「化」が必要ですね。
ちなみに、旧陸軍ではencodeを「組み立て」、decodeを「翻訳」といっていたそうです。んで、強引に読むこと（decrypt）を「解読」といったそうですよ。
/K
Re:RSA非公開鍵？ (スコア:1)
そりゃそうなんですが、「復」と「化」にはともに状態を変えるという意味があるわけでして、「復号化」だと部分的に意味が重複しちゃって、熟語として見たときにやや気味が悪い。
/K
Re:RSA非公開鍵？ (スコア:1)
対になる概念だから、言葉も対になっていた方が分かりやすいっていう主張はわかる。だけど、それに理屈をつけて「復号化」でもいいじゃないか、っていう議論のはどうなのか。
たとえば、「酸化」の対義語は「還元」ですが、「『化』が付いた方が対義語としてわかりやすい」という理屈だと「還元化」の方が分かりやすいという話になる。しかし、「化」が付くことによって「わかりやすさ」がどう変わるのか。ちっとも変わっていない。
/K
Re:RSA非公開鍵？ (スコア:1)
「還元化」ていうのは変化する過程を意味するのに使いますね。（意味が広がっていって、「還元」そのもので使う例もあるけど）「復号化」はそうじゃないでしょ。
/K
Re:RSA非公開鍵？ (スコア:1)
「復号化」はdecodeの訳として違和感があるという話をしているのであって、そういう用例があるから使ってもいいという話じゃない。
「還元化」っていうのはたとえば「土壌の還元化が進む」のように「元に戻る過程」という意味で使うならOKでしょう。
だけど化学の試験で「酸化の反対の概念は何ですか？」と問われたときに「還元化です。この言葉は文部科学省のサイトでも使われています」と答えたら正解になるのかい？
あと、「脱灰」←→「再石灰化」というのもあるよ、と隣の席のの人がスラドを見ながらにやついているｗ これも「脱灰化」とはいわないでしょ。「脱」と「化」は意味がダブっているから、と説明できる。
/K
Re:RSA非公開鍵？ (スコア:1)
逆に、復員化、復縁化、復学化、脱衣化、脱獄化などに違和感があるのは、意味のダブりで説明できるでしょう。「復号化」に違和感がない人はなぜないのか教えて欲しい。
/K
Re:RSA非公開鍵？ (スコア:1)
なお、復員を最初にあげたのは、復員がdemobilizationの訳語で、反対語が動員（mobilization）だからです。de+○っていうのがdecodeに近いでしょ。【en+○←→de+○が□化←→復□に訳されている言葉はどうしても思いつかなかった。】
関係ないけど（っていったらこのスレのことだな）、mobilizationを動員と訳せる感覚はすごいなーと感心してしまいます。
/K
Re:RSA非公開鍵？ (スコア:1)
化学分野だと普通「脱水」か「脱水反応」ではないですかね？
＃使うヒトもいるかもしれないけど、スラングっぽいなあ・・・。
意図してるのは水が解離するのではなくて、水酸基や水素基を
水の形にして分子から引き抜くことなので、結果的に水が抜ける
けど、乾燥などの水分抜きとは意味が違いますしね。
ちなみに、「水化」ってのは滅多に聞いたことはないです。
＃「水素化」ならよく聞くけどね。
＃あと、水和とか。
水は原子の組み変わりが起こるような化学反応でいろいろ結びつき方が
変わるので、水分子の形を保って他の物質と結合することはほとんどありません。
＃水酸基や水素基になってしまう。
＃だから水素化、水酸化というのはよく使うし、脱水素化とかもよく使う。
水和は弱い相互作用での結合なので、分子の原子数とかは変わらないし。
そういう分子の形式から見ると、リン酸化はリン酸基がそのまま付加して、
脱リン酸化はリン酸基がリン酸化合物になって解離するので、ちょっと脱水反応とは
違うように扱っていい気がしますね。
---- redbrick
Re:RSA非公開鍵？ (スコア:1)
対になる概念は、熟語の形式も対になっていた方がわかりやすい、というのであれば、「復号化」説を採る人は「酸化-還元化」「再石灰化-脱灰化」も肯定しなければいけない。
だから、余計な理屈はつけずに、「誰かの誤用が広がっちゃったんですね。アハハ」という話でいいじゃん。
/K
Re:RSA非公開鍵？ (スコア:1)
「復」と「化」を重ねることへの気味悪さを打ち消す説明は、「状態に化かす」では十分でない。それだと「復号」は何かの状態を表すことになってしまうよ。「暗号する」という日本語はないけど、「復号する」という日本語はある。
> 文字数、音数、語尾の号と化まで一致している
熟語を構成する漢字の意味は無視して、形式だけそろっていればいいということでしょ。これだと「復」と「化」の意味のダブりに違和感を持つ人は納得しない。余計な理屈を持ち出さずに、「どうやら間違えて覚えちゃいました。でもいまさら『復号』というのも違和感があります」っていえばいいじゃん。言葉なんてそんなもんだ。
/K
Re:RSA非公開鍵？ (スコア:1)
還元化って環境用語でしょ。たとえば「土壌の還元化」っていう場合は「（汚染された）土壌を元の状態に戻す」って意味。「土壌から酸素を抜いて土として役に立たないようにする」という意味ではない。化学用語の「還元」から来たけど、もとの意味を残しつつ、環境分野の人はもっと広い意味で使ってますよね。
それとも還元化という言葉が定着してきたから、酸化の反対語として還元化という言葉を使うべきってこと？
さあ、Googleで還元化を化学用語として使っている権威ある例を検索だ！ がんばれ。
>「復号」という日本語があるなら
ああ、ついに「復号」という日本語の存在が仮定条件にされてしまったｗ
私は「復号化」という言葉を使うな、とはいってない。漢字の意味を考えたら「化」を付けずに「復号」の方が素直ですよ、といっている。意味を考えずに形式だけ見るなら、「暗号化」←→「復号化」という関係は意味も言葉の形式も対になっていて一見わかりやすいという話はわかる。でも漢字は表意文字ですよ。それでいいのかい？というのが私の疑問。あるいは、むしろ「復号化」というべきで、「復号」は使うべきでないってこと？
/K
Re:RSA非公開鍵？ (スコア:1)
どうやら「復号」は間違いという主張ではなさそうだから、こう考えたらどうですか？
この場合、「復号化」よりも「復号」を使った方が無難（波風がたたない）ってことでいかが？
で、ACはen/de×code/crypt/cipherの訳語として何が適切だと考えてんの？
/K
Re:RSA非公開鍵？ (スコア:1)
/K
Re:RSA非公開鍵？ (スコア:0)