アカウント名:
パスワード:
googleのレポート [blogspot.jp]
問題は以下の3種・Variant 1: bounds check bypass (CVE-2017-5753)・Variant 2: branch target injection (CVE-2017-5715)・Variant 3: rogue data cache load (CVE-2017-5754)
脆弱性は以下の2つに分類して命名されている Spectre (variants 1 and 2) Meltdown (variant 3)
■Spectre はLinuxでの話eBPFという仕組みを経由してカーネルの情報を取得する手法Linux環境内に入ってからの話だし一般ユーザには関係ない?AMDはvariants 1に対してはOSアプデにより解決、またそれによるパフォーマンスの影響も微々variants 2に対しては設計の違いによりほぼゼロリスク、また再現もされてない
仮想サーバ関係者は大変ちなみにAMDはデフォルトでは無効の ePBF JIT が有効になっている場合にのみ影響があるとのことそれも ePBF JIT の脆弱性に起因しているのでこれが修正されれば問題ない
■Meltdown はIntel CPUの脆弱性の話カーネルモードで使った領域がL1Dキャッシュに残っていてユーザ権限から読めちゃうと書かれている性能面でやばいのもこっちAMDは設計の違いによりゼロリスクIntelはNorthwood以降Xeonも含め全滅
Meltdownはそんな単純な話ではないのでは。カーネル空間のあるアドレスの内容を投機的にアドレスとして用いてメモリラインをキャッシュさせ、どのキャッシュラインが埋められてるかタイミングを測ることでカーネルメモリの値を推定すると読めました:https://meltdownattack.com/meltdown.pdf [meltdownattack.com]
こんな脆弱性、OSではどうしようもないんじゃないかと思いましたが、特権モード用のページテーブルと非特権モード用のページテーブルの2種類を用意して対応できるんですね。
カーネル空間が見えると言っても、仮想メモリアドレス経由なので対策が可能だったということでしょうか。物理メモリアドレスで見えたらもうだめでしたね。
システムコール時にPLTを変えないと行けないから、キャッシュがクリアされて性能が下がるのでしょうか。
Meltdownについてはそんな単純ではないし、性能低下も実際にはそんな大きくないMeltdownの影響をひたすら受け続ける最悪のテストコード書いてみると30%程度の低下があった(と、コードを書いた人は主張しているがコードの品質や真偽はまだ不明)とかそんな話
プロセッサの設計にくわしい人おしえて投機実行!やっぱやーめたで先にキャッシュに乗っちゃった命令やデータって普通はその都度破棄するものなの?いやそっちのほうが安全かなと思うけどそんなのやってたら遅いんじゃねっていうか
メモリーから読み出した内容をインデックスとして別のメモリー領域を読み出して(ここら辺の処理を全て投機実行)、どこのメモリー領域を読み出したかをアクセス速度(一度読みだしている場合はキャッシュにヒットして速い)で判別して元のメモリー内容を推測するってのがキモのようです。全て破棄するのは手間も時間も掛かりそうですね。
「eBPF」が途中から「ePBF」に変わってます。検索する人は気を付けて。
いやそりゃSpectreの方でしょ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
概要 (スコア:5, 参考になる)
googleのレポート [blogspot.jp]
問題は以下の3種
・Variant 1: bounds check bypass (CVE-2017-5753)
・Variant 2: branch target injection (CVE-2017-5715)
・Variant 3: rogue data cache load (CVE-2017-5754)
脆弱性は以下の2つに分類して命名されている
Spectre (variants 1 and 2)
Meltdown (variant 3)
■Spectre はLinuxでの話
eBPFという仕組みを経由してカーネルの情報を取得する手法
Linux環境内に入ってからの話だし一般ユーザには関係ない?
AMDはvariants 1に対してはOSアプデにより解決、またそれによるパフォーマンスの影響も微々
variants 2に対しては設計の違いによりほぼゼロリスク、また再現もされてない
仮想サーバ関係者は大変
ちなみにAMDはデフォルトでは無効の ePBF JIT が有効になっている場合にのみ影響があるとのこと
それも ePBF JIT の脆弱性に起因しているのでこれが修正されれば問題ない
■Meltdown はIntel CPUの脆弱性の話
カーネルモードで使った領域がL1Dキャッシュに残っていてユーザ権限から読めちゃうと書かれている
性能面でやばいのもこっち
AMDは設計の違いによりゼロリスク
IntelはNorthwood以降Xeonも含め全滅
Re:概要 (スコア:4, 参考になる)
Meltdownはそんな単純な話ではないのでは。
カーネル空間のあるアドレスの内容を投機的にアドレスとして用いてメモリラインをキャッシュさせ、
どのキャッシュラインが埋められてるかタイミングを測ることでカーネルメモリの値を推定すると読めました:
https://meltdownattack.com/meltdown.pdf [meltdownattack.com]
Re: (スコア:0)
こんな脆弱性、OSではどうしようもないんじゃないかと思いましたが、
特権モード用のページテーブルと非特権モード用のページテーブルの2種類を用意して対応できるんですね。
カーネル空間が見えると言っても、仮想メモリアドレス経由なので対策が可能だったということでしょうか。
物理メモリアドレスで見えたらもうだめでしたね。
システムコール時にPLTを変えないと行けないから、キャッシュがクリアされて性能が下がるのでしょうか。
Re: (スコア:0)
Meltdownについてはそんな単純ではないし、性能低下も実際にはそんな大きくない
Meltdownの影響をひたすら受け続ける最悪のテストコード書いてみると30%程度の低下があった(と、コードを書いた人は主張しているがコードの品質や真偽はまだ不明)とかそんな話
Re: (スコア:0)
プロセッサの設計にくわしい人おしえて
投機実行!やっぱやーめたで先にキャッシュに乗っちゃった命令やデータって普通はその都度破棄するものなの?
いやそっちのほうが安全かなと思うけどそんなのやってたら遅いんじゃねっていうか
Re:概要 (スコア:1)
メモリーから読み出した内容をインデックスとして別のメモリー領域を読み出して(ここら辺の処理を全て投機実行)、
どこのメモリー領域を読み出したかをアクセス速度(一度読みだしている場合はキャッシュにヒットして速い)で判別して元のメモリー内容を推測するってのがキモのようです。
全て破棄するのは手間も時間も掛かりそうですね。
Re: (スコア:0)
「eBPF」が途中から「ePBF」に変わってます。
検索する人は気を付けて。
Re: (スコア:0)
いやそりゃSpectreの方でしょ