アカウント名:
パスワード:
各種予測・キャッシュミスが発生したときにペナルティ(やり直し)が発生するから問題な訳で、予測をミスったらCPUは開き直って、ごみデータを返せばよいのです!
# OSやファームウェアレベルで乱択アルゴリズム等と組み合わせれば、そういうアーキテクチャもアリだとは思う。
Spectreなどの攻撃は,投機的実行の副作用を悪用しています.つまり,実行時間の変化から,キャッシュのヒットとミスヒットを判定して,サイドチャネル攻撃を実現しています
そして,仮に"投棄的"実行を使ったとしても,サイドチャネル攻撃の対策になり得ません."投棄的"実行の副作用を悪用して,つまり,結果がゴミかそうじゃないか調べれば,キャッシュのヒットとミスヒットが判定できます.Spectraなどと同様のアプローチで攻撃が可能です.
具体的には,投機的実行の場合は,例えば同じ計算を複数回して,その実行時間の差を調べます."投棄的"実行の場合は,同じ計算を複数回して,その実行結果の差を調べるだけです.
つまり本質的には何も解決していません.
googleの研究者が指摘しているのはまさにこの問題です.サイドチャネル攻撃の根本的解決には投機的実行とか投棄的実行といった従来のコンピュータアーキテクチャレベルの議論や発想ではもはや対応できません.もっとメタな視点での新しい論理や,それに対応した新しい計算機モデルが必要だ,という主張です
同じ計算をして同じ結果が得られることを前提としているので、その方法では不十分なのでは?
ノイズを混入しても統計処理で消せるなら同じこと
攻撃の難易度で言えば違うのでは?そもそも比較という行為自体が非決定的になるので。
勿論、実装によっては確率に偏りを作ることは容易かも知れませんが。
キャッシュにもガチャを導入すれば解決ですね
陶器的実行(窯から出てきたデータをときたま破壊)
ガチャンじゃねーか!
サイドチャネル攻撃はメモリやストレージに入っている情報を直接読み取るのではなく情報を読み書きする時の処理時間、消費電力、放射される電磁波、音波、振動等の違いから間接的に情報を推測しているだけですからね。だから99.99%の正確さで中身を当てられるというような話が出てくる。
キャッシュにヒットするかどうかで処理時間が変わるってそんなの当たり前じゃんていうかそれがキャッシュってものなわけで、その特性が悪用可能というのならもうキャッシュするのやめるぐらいしか抜本的な解決策はないんじゃないのって気になりますよね。当然、遅くなりますが。
一応プロセスかスレッド単位かなんかそんなかんじでキャッシュを分離すればかいけつそれでキャッシュの意味があるかと言うと分離機構のオーバーヘッドでキャッシュの意味がなくなるだろうけど
初期RISCの「遅延スロット」は、ある意味そういう方向のものじゃないかな。予測なんてせず「とにかくパイプラインは埋めるから、それで問題がないようにコンパイラが頑張れ」の思想。
結局、コンパイラが頑張るのは限界があってNOPを埋めるばかりであまり効率が良くないのと、内部実装(パイプライン段数)とべったりな関係なので内部実装を超えたアーキテクチャの維持が難しくなって、汎用的なCPUでの採用は廃れた感じ
今なら昔よりは頑張ってくれそうだし、JITにしてしまえばアーキテクチャへの依存性も緩和出来るのよね。……というか、現状マイクロコードへの変換がそれに相当しているというべきか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
投棄的実行 (スコア:1)
各種予測・キャッシュミスが発生したときにペナルティ(やり直し)が発生するから問題な訳で、予測をミスったらCPUは開き直って、ごみデータを返せばよいのです!
# OSやファームウェアレベルで乱択アルゴリズム等と組み合わせれば、そういうアーキテクチャもアリだとは思う。
Re:投棄的実行 (スコア:4, 興味深い)
Spectreなどの攻撃は,投機的実行の副作用を悪用しています.
つまり,実行時間の変化から,キャッシュのヒットとミスヒットを判定して,
サイドチャネル攻撃を実現しています
そして,仮に"投棄的"実行を使ったとしても,サイドチャネル攻撃の対策になり得ません.
"投棄的"実行の副作用を悪用して,
つまり,結果がゴミかそうじゃないか調べれば,キャッシュのヒットとミスヒットが判定できます.
Spectraなどと同様のアプローチで攻撃が可能です.
具体的には,投機的実行の場合は,例えば同じ計算を複数回して,その実行時間の差を調べます.
"投棄的"実行の場合は,同じ計算を複数回して,その実行結果の差を調べるだけです.
つまり本質的には何も解決していません.
googleの研究者が指摘しているのはまさにこの問題です.
サイドチャネル攻撃の根本的解決には
投機的実行とか投棄的実行といった従来のコンピュータアーキテクチャレベルの議論や発想ではもはや対応できません.
もっとメタな視点での新しい論理や,それに対応した新しい計算機モデルが必要だ,という主張です
Re: (スコア:0)
同じ計算をして同じ結果が得られることを前提としているので、その方法では不十分なのでは?
Re: (スコア:0)
ノイズを混入しても統計処理で消せるなら同じこと
Re: (スコア:0)
攻撃の難易度で言えば違うのでは?
そもそも比較という行為自体が非決定的になるので。
勿論、実装によっては確率に偏りを作ることは容易かも知れませんが。
Re: (スコア:0)
キャッシュにもガチャを導入すれば解決ですね
Re: (スコア:0)
陶器的実行(窯から出てきたデータをときたま破壊)
Re: (スコア:0)
ガチャンじゃねーか!
Re: (スコア:0)
サイドチャネル攻撃はメモリやストレージに入っている情報を直接読み取るのではなく
情報を読み書きする時の処理時間、消費電力、放射される電磁波、音波、振動等の違いから
間接的に情報を推測しているだけですからね。
だから99.99%の正確さで中身を当てられるというような話が出てくる。
キャッシュにヒットするかどうかで処理時間が変わるってそんなの当たり前じゃんていうか
それがキャッシュってものなわけで、その特性が悪用可能というのなら
もうキャッシュするのやめるぐらいしか抜本的な解決策はないんじゃないのって気になりますよね。
当然、遅くなりますが。
Re: (スコア:0)
Re: (スコア:0)
一応プロセスかスレッド単位かなんかそんなかんじでキャッシュを分離すればかいけつ
それでキャッシュの意味があるかと言うと分離機構のオーバーヘッドでキャッシュの意味がなくなるだろうけど
Re:投棄的実行 (スコア:1)
初期RISCの「遅延スロット」は、ある意味そういう方向のものじゃないかな。
予測なんてせず「とにかくパイプラインは埋めるから、それで問題がないようにコンパイラが頑張れ」の思想。
結局、コンパイラが頑張るのは限界があってNOPを埋めるばかりであまり効率が良くないのと、
内部実装(パイプライン段数)とべったりな関係なので内部実装を超えたアーキテクチャの維持が難しくなって、
汎用的なCPUでの採用は廃れた感じ
Re: (スコア:0)
今なら昔よりは頑張ってくれそうだし、
JITにしてしまえばアーキテクチャへの依存性も緩和出来るのよね。
……というか、現状マイクロコードへの変換がそれに相当しているというべきか。