アカウント名:
パスワード:
>>その状態モデルを操作できるようにするところから始めないと、脆弱性の解消どころか研究すら手が付けられないとしている。
脆弱性を利用する方にとっても高度すぎて手を付けられないということになるなw
「投機的実行におけるサイドチャネルを残したまま」対策を行ったり対策された状況での攻撃余地の探索についてはその通り。未対策の場合は普通に突けるだろうし。抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。
前提を絞ってフィクションでの電子戦みたいな夢物語を現実として語ってみた感。
> 抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。
今のところハードウェア量が30-40%増えるか、互換性がなくなるかしか抜本策はないのだが?
互換性やダイ面積程度の犠牲で対策できるんであれば
Spectre脆弱性は投機実行機能を持つすべてのCPUに存在する、プロセス分離という概念は滅びた、個々のソフトウェア実装どころかプログラミング言語でもハードウェアでも解決できない
ってのは誇大広告と言うしかないでしょう。てかハードウェア量30〜40%ってどういう計算なんだか……
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
それは逆に言うと (スコア:0)
>>その状態モデルを操作できるようにするところから始めないと、脆弱性の解消どころか研究すら手が付けられないとしている。
脆弱性を利用する方にとっても高度すぎて手を付けられないということになるなw
Re:それは逆に言うと (スコア:1)
「投機的実行におけるサイドチャネルを残したまま」
対策を行ったり対策された状況での攻撃余地の探索についてはその通り。
未対策の場合は普通に突けるだろうし。
抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。
前提を絞ってフィクションでの電子戦みたいな夢物語を現実として語ってみた感。
Re: (スコア:0)
> 抜本対策(フェッチ段階で転かすとかコンテキストスイッチを厳密にやるとか)された場合は普通に余地が無くなるだろうし。
今のところハードウェア量が30-40%増えるか、互換性がなくなるかしか抜本策はないのだが?
Re: (スコア:0)
互換性やダイ面積程度の犠牲で対策できるんであれば
ってのは誇大広告と言うしかないでしょう。
てかハードウェア量30〜40%ってどういう計算なんだか……