Intel CEO、Spectre/Meltdown脆弱性を解決するシリコンベースの修正内容を説明 36
ストーリー by headless
防護 部門より
防護 部門より
Intel CEOのBrian Krzanich氏はシリコンベースの変更でSpectre/Meltdown脆弱性を直接的に解決した製品を今年中に出荷できると1月に述べていたが、より具体的な変更内容を15日発表のプレスリリースで説明している(プレスリリース)。
GoogleのProject Zeroが発表した3つの脆弱性のうち、バリアント1 (Spectre 1)はソフトウェアでの対策を続けるが、バリアント2 (Spectre 2)とバリアント3 (Meltdown)の対策でハードウェア的な変更を行うのだという。具体的にはプロセッサーのパーツを再設計し、アプリケーションと特権レベルの間に「防護壁」を追加するパーティショニングを行うことで、攻撃者に対する障壁を作るとのこと。
ハードウェアの変更は、今年下半期に出荷予定の次世代Xeon Scalableプロセッサー(Cascade Lake)と第8世代Coreプロセッサーから適用される。新製品投入にあたっては、人々が期待するパフォーマンス向上を確実にすることが重要だとし、演算能力だけでなくセキュリティ面でも最高のパフォーマンスをもたらすことが目標だとも述べている。
また、既存製品についてはSpectre/Meltdown脆弱性からの保護に必要なマイクロコードアップデートをリリースしているが、過去5年間に発売された製品の100%を既にカバーしているとのことだ。
GoogleのProject Zeroが発表した3つの脆弱性のうち、バリアント1 (Spectre 1)はソフトウェアでの対策を続けるが、バリアント2 (Spectre 2)とバリアント3 (Meltdown)の対策でハードウェア的な変更を行うのだという。具体的にはプロセッサーのパーツを再設計し、アプリケーションと特権レベルの間に「防護壁」を追加するパーティショニングを行うことで、攻撃者に対する障壁を作るとのこと。
ハードウェアの変更は、今年下半期に出荷予定の次世代Xeon Scalableプロセッサー(Cascade Lake)と第8世代Coreプロセッサーから適用される。新製品投入にあたっては、人々が期待するパフォーマンス向上を確実にすることが重要だとし、演算能力だけでなくセキュリティ面でも最高のパフォーマンスをもたらすことが目標だとも述べている。
また、既存製品についてはSpectre/Meltdown脆弱性からの保護に必要なマイクロコードアップデートをリリースしているが、過去5年間に発売された製品の100%を既にカバーしているとのことだ。
解決してないじゃん (スコア:2, すばらしい洞察)
>バリアント1 (Spectre 1)はソフトウェアでの対策を続けるが、
つまりSpectreは一部しか解決してない。
>「Intel CEO、Spectre/Meltdown脆弱性を解決するシリコンベースの修正内容を説明」
まるで脆弱性を両方解決したかのようの物言い。
Re:解決してないじゃん (スコア:1)
訴訟起きてリコールまでがワンセット
# Pentiumの時は最初は対応するそぶりすら見せなかったけどな。
Re: (スコア:0)
リコールが起きたらどんなCPUと交換になるんだろう？
それに加えて、普通は世代の異なるCPUだけ取り替えられないし、WindowsのDSPライセンスはPCIのLANカードに設定してるケースもありそうだけど。
Re: (スコア:0)
でも対応でパフォーマンスが落ちても訴訟するんでしょ？
Re: (スコア:0)
後から下位グレードの製品買ったのと同じにしても問題ないってことになるんなら、他も含めて皆ダウングレードやりだすぞ。
Re:解決してないじゃん (スコア:1)
どう対処するのがベストなのか、それぞれ違うから。
まず、分岐予測か投機実行という技術を使うのを止めてしまえば、問題になってる脆弱性は消えて無くなるけど、CPUの性能が大幅に劣化する。その辺の技術を安全に使うにはどうすれば良いかは、慎重に検討する必要がある。
例えば、完全に廃止するんじゃなくプロセス間で分岐予測の結果が一切共有されないようにすれば、性能劣化をある程度に留めつつ、この脆弱性の問題を大幅に減らせる。
でも、減らせても、ブラウザ上で走るJavascriptでアクセス不可能な情報を抜き出しうる、とされていたように、仮想マシンの類作ったサンドボックスへの封じ込めみたいに、完治しない問題は残る。諦めてCPU性能の大幅劣化を受け入れるか、その手のソフトウェアを作る時に気を付けるようにするか。
また、プロセス間で共有されるようにしたままだと、別のプロセスのデータを不正に読み出せる危険はあるけど、ある種のソフトではその共有のおかげで性能が上がる可能性もある。共有のせいで不正行為を防止できるようにソフトを作る方法があるなら、そうした方が良い。
逆に、ソフト側で対処すると性能が大幅に劣化する部分についてはCPUのアーキテクチャを変更した方が良い。
Re: (スコア:0)
> プロセス間で分岐予測の結果が一切共有されないようにすれば、
されてます
されてるけど嘘のつき方が下手だから何を知ってるかがバレる
勉強し直してきて
Re: (スコア:0)
> > プロセス間で分岐予測の結果が一切共有されないようにすれば、
> されてます
どこにかかるのか分かりにくいけど、話の流れからして「共有」「されてます」ではないよね？
「一切共有されないように」「されてます」で合ってる？
> 嘘のつき方が下手だから
嘘の付き方が下手だと、「一切」共有されないように、するという目標は達成できてないから、対策になってないと思うんだけど。
Re: (スコア:0)
「一切共有されないようにする」というのがリングプロテクションの仕様の一部
「よく観察していると知っているかどうかが分かる」というのがMeltdown
「一切」共有されないようにするのがretpolineはじめ各社の対策コード
最初から共有することに意味があるものでも、共有するように作られているものでもない
Re: (スコア:0)
> 最初から共有することに意味があるものでも、共有するように作られているものでもない
・分岐予測をプロセス間で共有させれば、同じプログラムをたくさん並列で走らせている場合(CGIサーバとか)で性能が向上する可能性がある
・プロセスごとに分岐予測テーブルを変えるような仕組みは余りにコストが高く付きすぎる
といった理由で共有されてるのかと思ってたけど、そういうわけでも無いのか。
Hyper Threadingで同じコア上で走らされてるプロセス間ぐらいでしか共有されないのか。
Re:解決してないじゃん (スコア:1)
解決してないのではない解決できない
Spectre 1は投棄実行アルゴリズムの穴なので
投棄実行をしている限り完全な防御は無理
確率的に出来るだけ防ぐことは出来るが完全ではない
そこらへんはAMDも同様
あちらも同様に投棄実行を実装している為、成功確率的に低いがSpectre 1は存在する
メモリ等のレスポンスを犠牲にして
投棄実行を辞めればSpectre 1は解決する
それをするには新規アーキテクチャを立ち上げないと行けないレベル
それぐらい投棄実行は深く実装されている
Re:解決してないじゃん (スコア:3, おもしろおかしい)
とりあえずポイ捨てはやめよう
Re: (スコア:0)
ポイ捨てしたから回収されたのかw
Re: (スコア:0)
Re: (スコア:0)
予想が外れると投棄せないかん
Re: (スコア:0)
c = *himitsu;
b = a[c];
みたいなコードで、1行目で例外が発生した場合、インテルのCPUでは投機実行で2行目が実行されちゃう。
最終的には投機実行の結果は破棄されて、cにhimitsuのデータは入らないし、bにはa[c]の値は入らない。
でも、投機実行中はcにhimitsuのデータが入り、a[c]が読み出される。
事前にaをキャッシュから追い出しておけば、配列aの中でcの位置のデータだけがキャッシュに載っている状態になる。
もし、himitsuが8bitのデータなら、配列aのサイズを256にしておけば、配列を先頭から順番に読んで、
一番速く読み出せた位置を調べることでキャッシュに載っている位置
Re: (スコア:0)
既存の製品はアップデートで対応できてんの？
ちゃんと動くアップデート配信されてんの？
うまく動かないと言う話しか聞こえてこないんだけど
Re: (スコア:0)
5年超のCPUは対応せんの？
家のメインマシンはC2Qなんだが
Re: (スコア:0)
そもそもC2Qが該当するのかどうか。
Sandy以降はmicrocodeがアップデートされてるけど、Spectre/Meltdown対策かどうかは分からないけど。
https://downloadcenter.intel.com/download/27591/Linux-Processor-Microc... [intel.com]
Re: (スコア:0)
ここ見て確認して
マイクロコードの開発状況が載ってる
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microco... [intel.com]
Re:解決してないじゃん (スコア:1)
C2QだがProduction StatusがPlanningだった
やる気はあるというアリバイの様な orz......
Re: (スコア:0)
見た限り、Sandy以降のアップデートはSpectre対策済みのようだね
WindowsだとMicrosoft純正のアップデートがどこまで反映されてるか分からないけど、
VMWareのツールでやってしまうか
Re:解決してない (スコア:0)
じゃん
よくわかってないから.... (スコア:2, 興味深い)
対策CPUが出て、検証してみる人たちの結果待ちかなぁ。
CPUの中身ってそんなに急に対策できるわけじゃないだろうから、
Intelがどれくらい前から検討していたかがかぎになりそう。
ARMとかほかのCPUでも同じ問題があるって言ってたけど、
そっちは対策済みなのかなぁ。
株価対策 (スコア:1)
市場は「ほーん、それで現物は？」な段階なのです。
あとは株主への火消し。首元が寒いでしょうね。
もともと4リングじゃなかったっけ？ (スコア:0)
x86って4リングで、UnixやNTはリング0とリング3しか使ってないとかって話だったような。
それとは違う話なのかな。
CPUのハードウェア自体を物理的に分けるとかなのかな。
Re: (スコア:0)
また使われないリングを増やすってことなんじゃないか?
Re: (スコア:0)
この前リーナス・トーバルズがキレてた奴じゃないの? 複雑すぎるし責任が全部カーネル持ちになるしソフトでやっても変わらんとか
Re: (スコア:0)
０を実行する前に
適当にキャッシュ済みアドレス内で完結する命令を0.5リングで必ず実行し
３から０を噛み付けないようにするんじゃね？
Re: (スコア:0)
投機実行中にメモリを読むのが諸悪の根源なんだとすれば、メモリを読めないリングとかなんですかね。
投機実行の状態が終わったら然るべきリングへ遷移して処理を継続する感じで。
投棄実行の結果の時間差が問題なんだから (スコア:0)
OS側のメモリ保護機能を強化すれば解決はしないが悪用は出来ないと思うんですが
あと現実問題としてローカルの1台のマシンでも攻撃難易度高いのに企業が使ってるようなサーバー群の上のさらにVM上のメモリを覗くなんて事できるスーパーハッカーは地球上に何人いるんでしょうか？
Re:投棄実行の結果の時間差が問題なんだから (スコア:1)
現実を見ようぜ。
・ソフトウェアでの緩和策は性能が劣化する
・カーネルで対策しても守れるのはカーネル空間だけで、ユーザ空間は守られない
・簡単に攻撃に使用できるコードが既に広く出回っていてハッカーいらない、子供でもできる
・現状の対策は攻撃を困難にするための緩和策であって根本解決にはなっていない
まだまだ書けるけど？
Re: (スコア:0)
> ・カーネルで対策しても守れるのはカーネル空間だけで、ユーザ空間は守られない
これは勘違いだと思います
実証コードがあれば教えてください
Re: (スコア:0)
どの方法でも、やってみればすぐわかるよ。実際の攻撃方法を指南することは敢えて避けるけど。
逆に何で対策されていると思ったの？ 根拠知りたい。
Meltdown: 今のところユーザー空間を守る具体的な方法は存在しない、AMD に乗り換えろ
SpectreV1: アプリケーションプログラムの個別書き換えが必要
SpectreV2: retpoline でアプリケーションの再コンパイル、もしくは IBRS always を有効にする。
この中でカーネル(+マイクロコードも必要)でできるのは IBRS always だけだよー。
Re: (スコア:0)
特定のアドレスがCPUのキャッシュに載ってるか
載ってないかですら有益な情報になってしまうので
メモリ保護機能をどうこうするだけでは実はダメだった
というのが今回の騒ぎの本質のひとつ。
Re: (スコア:0)
企業が使ってるサーバ群→AWSやGCP、Azureといったパブリッククラウド
VM上のメモリを覗く→IaaSサーバは大概仮想マシン。誰と誰が同じ物理ホストに同居してるか不明