https://japan.zdnet.com/article/35133748/https://japan.zdnet.com/article/35133748/
>研究者らが、Intel製のすべてのチップに影響を及ぼす新たな脆弱性「SPOILER」を発見した。
>SPOILERは、CPUのパフォーマンス向上を図る投機的実行の方法に起因するものだ。
>2018年1月に発覚した「Spectre」や「Meltdown」と同様に、SPOILERを悪用する攻撃では、
>Intel製チップの投機的実行プロセスを使って機密情報を読み取ることが可能になる。
>研究者らは、ARMとAMDのプロセッサコアについても同じ脆弱性を探したが、Intelのチップと同じ動作は見つからなかった。
シリコンレベルでの大幅な再設計なしには修正はできないってよ
インテル
脆弱性
入ってる
すまんURLミスってたわ
https://japan.zdnet.com/article/35133748/
だいたい一人が占有しているPCよりも、鯖のほうが影響出やすそう
3-4年で鯖を置換える場合は、今年はHaswell(Broadwell)あたりのマシンが対象
この辺とコア当たり性能の向上を望まず同等程度で構わないなら、
今だとAMD EPYCで置換え出来てしまうし、多コアな分統合が捗りそう
（エンプラ用にAMDマシンで稟議が通るかは知らん）
命令セットがあれだけ複雑なもんだから脆弱性は当たり前だ
当たり前なんじゃなくアーキテクチャ斬新せず使い回してきたツケだろ
マイクロアーキテクチャの進化に伴う脆弱性なんで
命令セットという意味でのアーキテクチャはあんまり関係ない
そのマイクロアーキテクチャが命令セットの複雑さを埋め合わせるために存在するので
あんまり関係ないとは言い難い
マイクロアーキテクチャは命令セットの複雑さを埋め合わせるために存在するのではなくて
圧縮率の高いコードを実行しやすいコードに翻訳するためにあるんだし
その翻訳機構にバグがあるわけではない
それに投機的実行やアウトオブオーダー実行はarmでもやってることだよ
C言語のアナロジーで考えるのがいい
「観測できる挙動」を変えないという制約の中で速いコードを吐く
コンパイラが優秀だとされるけれども
セキュリティーなにそれって時代に定義された「観測できる挙動」には
実行速度に関する規定がない
そのせいで実行速度の違いを突いてセキュリティーを突破する攻撃は
実際にかつて存在した
同じことが CPU にも起きている
>>9
為と仕組みは別でしょう。
そしてARMにも投機的実行の装置があるのにこのバグがないということは
まさに俺が訴えたいことを裏付ける。
インテルのCPUをデザインしてる人たちに天才は多いはずだ。優秀な人ばかりなはずだ。
なのにこんなつまらないミスが起きた。しかもインテルは10年以上気づかなかった。
外部からの指摘がなければずっと気づかなかったかもしれん。
それに、まだ潜んでるミスがこれからもっと発見されるかもしれん。
その可能性はRISCより高いということについてあなたたちの考慮を求めてる。
マイクロアーキテクチャと命令セットは表裏一体なので隔離して考えてはいけない。
複雑なマイクロアーキテクチャがあるのは命令セットが複雑だから。
今回の件はメモリーの脆弱性だからメモリー系の命令を調べてみた。
報告書によって悪い命令はrdtscp（read time stamp counter and processor ID）らしい。
ざっくり言えば他の命令が実行された場合どんだけサイクルを食うか予測してくれるやつだ。
さて、何故そんな命令がインテルの命令セットだけにあるのかな…
命令が食うサイクルの数を即座に調べる必要があるのは何故かな…
命令の中に複雑でサイクルをめちゃくちゃ食うやつがあるからだぞ。
問題は命令セットだ。
命令セットが複雑で、って言うなら同じ命令セットのAMDにもなきゃおかしいが、
見付かっていないのだからそれが理由にはならないわな
タイムスタンプカウンタは何クロック経過したかを調べるものではないよ
アイドル時に周波数が下がったりターボ時に上がったりしてもタイムスタンプカウンタの刻み幅は実時間に沿って増えていく
タイムスタンプカウンタはただの高精度時計にすぎない
×刻み幅は実時間に沿って増えていく
〇刻み幅は実時間に沿って固定
個人ブログだけど解説記事
CPUの新たな脆弱性 SPOILERの論文を読む - FPGA開発日記
http://msyksphinz.hatenablog.com/entry/2019/03/11/040000
(最後のみ)
回避策
今のところ有効な回避策はなく、ストア命令がバッファに入っている間にロード命令を投機的に実行することを禁止にすると性能に重大な問題を引き起こしてしまう。ソフトウェア的にはストアとロードの間にフェンスを入れることが有効ではあるが、それをすべてのソフトウェアに適用させることはできない。
ハードウェア的にも性能低下を避けるためには、投機的実行の手法を考え直す必要がある。性能を低下させずにこの問題を解決するためには、何らかの方法を考える必要があるものと思われる。
>>12
根本的な原因の話だろ。お願いだから論理的に考えてくれ。
【問題】部屋の中が暑い。
インテルは外へ出る。でもAMDは上着を脱ぐ。
対策は自由だが根本的な問題は同じだ。
CISCの根本的な問題は天才でも人間には理解できないほどの複雑さ。
CPUはただでさえ複雑なのにその上に気まぐれな命令を乗せて
それを支えるために余計なマイクロアーキテクチャを作る。
裏目に出るのはSPOILERで最後とは思えない。
何事もほどほどが一番だ。
>>13
ありがとう。
インテルアーキテクチャが悪い、ではなくて CISC が悪いときたか (笑)
いつの人間だよ
半世紀前にはCISCだRISCだと争っていたのかも知れないが
今はもうそういう時代じゃない
CPU は爆速になった
CISCもRISCも変わらん
問題は止まって見えるほど遅いままのメモリーだ
メモリーアクセスの工夫が今の CPU の速さを決める
そこの工夫は命令セットとは関係ない
CISCでも RISCでもどんな命令セットでも
ライバルを出し抜こうと思えばメモリーアクセスを工夫する必要がある
そしてインテルの工夫の仕方はサイドチャネル攻撃を考慮していなかった
これはそう言う問題だ
言いそびれた
「メモリーアクセスの工夫」は命令セットに施すものではなくて
命令を実行する CPU 実装の側の工夫のことだぞ
どんな言語で命令されようとも
そう命令されたなら CPU はメモリーにアクセスしなきゃいけない
さあどうするのが速いだろうか？
それが CPU の腕の見せ所だ
この先アクセスしそうなアドレスを先読みしたり
キャッシュを使ったりして他者を出し抜くためにズルをするわけだ
ズルをしたってプログラムにバレなければ問題ない
各社の CPU はみんなズルをしてる
そんな中インテルはズルを見つかってしまった
さて、CPU に「メモリーにアクセスしろ」と日本語で命令する代わりに
英語や中国語で命令すればこの問題は解決するだろうか？
ここIT技術者達がいてすげーな
ワイさっぱりなので尊敬するよ
どうせAMDだって腐って粗悪品得るようになるんだからインテルがダメでもイイじゃん(大局を見据えてる人の感想)