追記1（2018/1/4 21:36）案の定読み間違いがありました！すみません！
追記2(2018/1/5 13:21)パッチの結果がわりと出てきたので追記
ニュースになっているintelのセキュリティ脆弱性の情報が国内に全然ないので海外のサイトを適当にみてまとめた。
内容については保証しないので必要があればソースを見てください。
お昼やすみとかで書いたので気が向いたらアプデする
参照サイト
多分ここみればこの記事より詳しい
https://meltdownattack.com/
上のサイトに掲載されている今回ざっくり縦読みしたMeltdownのペーパー
https://meltdownattack.com/meltdown.pdf
本脆弱性の対策実装のwikipedia
https://en.wikipedia.org/wiki/Kernel_page-table_isolation
他いくつか。
結局何に影響があるか
何もしないと全ての物理メモリ上のデータが盗める
Meltdownだけで全ての物理メモリにアクセス可能なので、パッチを当てないとメモリ上にある全てのデータが盗まれるため非常に危険（実行がどれくらい簡単かは読めてないけど、JavaScriptで実行可能との記事を読む限りできはするものだとおもう）
KTPI(KAISER)パッチを当てることでパフォーマンスが劣化する。
実際影響が大きいのはおそらくクラウドで
- VMのホストOS
- VMのゲストOS
両方で保護しないといけない可能性が高い。
ホストOSでは、悪意のあるゲストがこの脆弱性をついた場合に他の顧客含め物理メモリ全DUMPが可能なので、他顧客のデータが漏洩する可能性があるため。
ゲストOSでは、悪意のあるコードが実行される可能性は低いものの、もし適当な攻撃コード入りのライブラリ等を実行すれば実行ユーザー関係なくすべての物理メモリがdump可能なので、ホストOSほどではないものの危険。
その結果、今のコア貸しのクラウドだとパフォーマンス低下が二重に発生すると考えられ、スペックをあげないと既存のアプリケーションが動かなくなる可能性がある。
この点、実際のクラウド基盤に疎いことやいまの仮想化技術に疎いこともあって責任は持たない。
追記2:実際AWSなどパッチを適用したクラウドでは致命的なパフォーマンスの低下はなさそうとの話がぽつぽつ出てきているので想定したほどインパクトはないかもしれません。（エビデンスはない）
問題の概要
今回の問題は
- Meltdown
- Spectre
の二つがある。
これらによる問題
保護されているはずの他プロセスやkernelのメモリ空間を参照できる。
それによって、他のアプリケーションの重要なデータ（パスワードとか）にアクセスできたり、クラウドの場合他の顧客のデータにアクセスできる。
基礎知識
適当なので必要があれば別途調べてください。
アウトオブオーダー実行
最近のCPUはアウトオブオーダー実行という実行方式で命令を実行しており、これはプログラムを効率的に実行する上で不可欠な CPUの機能となっている
（初期のAtomはこの機能がなかったために致命的に遅かったことは記憶にあるかもしれない）
本来プログラムは記述された順番に実行されるものの、実際CPUでその通りに実行すると多分な待ち時間などが発生する。（メモリとのやりとりとか）
そこで、命令実行できる部分からバラバラに実行して最終的に順番に実行した結果とおなじ結果になるように調整する機構がアウトオブオーダー実行という。（ちなみに逆に順番に実行する手法はインオーダー実行という）
Meltdown
詳細はこちらのペーパー。
https://meltdownattack.com/meltdown.pdf
アウトオブオーダー実行時にkernel空間のメモリをreadできるという脆弱性。
これによって、他のプロセスや他のVM（クラウド上であればこれは他の顧客のVMとなる）のデータが読める。
具体的には、全ての物理メモリをdumpすることができる。
原因
本来致命的なexceptionが発生したらそのタイミングでプログラムの実行が終了するが、アウトオブオーダー実行で並行実行される処理が無効化されるまでのわずかな時間を使って、exception発生後にプログラムを実行することができる。
その間に物理メモリにアクセスするのに必要なsecretを盗み、その後それを使って全ての物理メモリをdumpすることが可能。
追記1:こちら、secretというのは鍵ではなく、機密情報そのものでした。つまり、上記の方法を繰り返して順次本来アクセスできない情報を取得するとのことでした。
また、関連して保護された領域にアクセスする際に発生するexceptionは無視する手法があるらしい。
対策
KTPI(KAISER)手法を取り入れる。
Wikipediaによると、これまではユーザーコードとkernelをおなじページテーブルに配置していた。これの恩恵は割り込みやsystemcall時のコンテキストスイッチコストが軽減されるため。
しかし、同じページテーブル上のアクセス権管理がMeltdownで破れたため、trampoline functionのみを同じページテーブルに配置する対策をするのがKAISER。
これによって、kernelは別のページテーブルであるため、その切り替えコストが発生することになって性能が劣化する・・・っぽい。
Spectre
まだよめてない
MeltdownのFAQ（上と重複あり）
あとでまとめ直す
なんで攻撃できたの
根本的には、アウトオブオーダー実行で本来実行されないはずの例外が発生したあとのコードが実行されたから。
例外が発生したタイミングで例外処理をするkernelに実行ユーザーが移るが、そのユーザー権限でユーザーコードを実行することに成功。そのタイミングで物理メモリアクセスするためのsecretの取得と転送を行う。
追記1:こちら、secretというのは鍵ではなく、機密情報そのものでした。つまり、上記の方法を繰り返して順次本来アクセスできない情報を取得するとのことでした。
参照先
- p.4-5: 3 A To Example
- p.8-9: 5.1 Attack Description: Step1, Step2
なにができるの
物理メモリアクセスするsecretが盗まれているので、時間をかければ全ての物理メモリがダンプできる
追記1:物理メモリにアクセスするためのsecretなんてない！「なんで攻撃できたの」の方法で全部のほかプロセス含む情報が取得できます。
参照先
- p.9 : 5.1 Attack Description: Dumping the entire physical memory
どう対策すればいいの
KAISERってパッチを当てる。処理は遅くなるけど致命的な問題はなくなる。
KAISERはアウトオブオーダー実行でアクセスできるkernel空間にsecretを置かないように空間を分離する実装。とはいえ必要な情報が見えるところからなくなるので、処理のたびにワンクッション置いてsecretのあるデータをロードする分がオーバーヘッドになる。
追記1:kernel空間というのがユーザー空間から見たときのほかのプロセスのデータも含むようです。なのでkernel空間にアクセスできる＝ほぼすべてのマシン上のほかプロセスのメモリにアクセスできるとなるらしい。
参照先
- p.14 : 7.2 KAISER
- https://en.wikipedia.org/wiki/Kernel_page-table_isolation
知らないことやわからなかったこと
いわゆる免責的な
物理メモリを読むのにsecretが必要なのか？secretがあればよめるのか？この辺の管理機構についてよくしらない。標準的な32bitプロテクトモードでのメモリ保護についてはざっくり知ってるけど。（bitで管理するやつ）
あとpaging周りもだいぶ忘れたのでフィーリングで書いてます。
追記1:前述のとおりそんなものはなかったです。secretという単語はアクセスできない情報という意味でした。
あと、カーネル領域がユーザー領域にmappingされているテクニックもよく知らない。割り込み発生したらカーネル領域へコンテキストスイッチが発生するような実装しか書いたことがない。
追記1:ここも同上の勘違いです。結局ほぼすべての物理メモリ上の情報を仮想メモリ空間にmappingしているようです。（要出展）
関連論文や技術に目を通していないのがバレてしまう・・・。
追記1
めっちゃ読み間違えていました本当にすみません。