Enviar búsqueda
Cargar
SpectreとMeltdown:最近のCPUの深い話
•
6 recomendaciones
•
2,866 vistas
LINE Corporation
Seguir
LINE Developer Meetup
Leer menos
Leer más
Tecnología
Denunciar
Compartir
Denunciar
Compartir
1 de 50
Recomendados
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14
Ryo Suzuki
20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
yohhoy
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
MITSUNARI Shigeo
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
Kuniyasu Suzaki
組み込み関数(intrinsic)によるSIMD入門
組み込み関数(intrinsic)によるSIMD入門
Norishige Fukushima
マルチコアを用いた画像処理
マルチコアを用いた画像処理
Norishige Fukushima
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
Recomendados
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
ゲーム開発者のための C++11/C++14
ゲーム開発者のための C++11/C++14
Ryo Suzuki
20分くらいでわかった気分になれるC++20コルーチン
20分くらいでわかった気分になれるC++20コルーチン
yohhoy
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
MITSUNARI Shigeo
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
3種類のTEE比較(Intel SGX, ARM TrustZone, RISC-V Keystone)
Kuniyasu Suzaki
組み込み関数(intrinsic)によるSIMD入門
組み込み関数(intrinsic)によるSIMD入門
Norishige Fukushima
マルチコアを用いた画像処理
マルチコアを用いた画像処理
Norishige Fukushima
できる!並列・並行プログラミング
できる!並列・並行プログラミング
Preferred Networks
ARM Trusted FirmwareのBL31を単体で使う!
ARM Trusted FirmwareのBL31を単体で使う!
Mr. Vengineer
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
KiyotomoHiroyasu
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
sonickun
PyOpenCLによるGPGPU入門
PyOpenCLによるGPGPU入門
Yosuke Onoue
プログラムを高速化する話
プログラムを高速化する話
京大 マイコンクラブ
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
alwei
C++ マルチスレッドプログラミング
C++ マルチスレッドプログラミング
Kohsuke Yuasa
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
Masami Hiramatsu
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
Takateru Yamagishi
非同期処理の基礎
非同期処理の基礎
信之 岩永
LLVM最適化のこつ
LLVM最適化のこつ
MITSUNARI Shigeo
プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜
京大 マイコンクラブ
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Masahiro Sakai
Minecraft による強化学習の実践 (MineRL)
Minecraft による強化学習の実践 (MineRL)
Tusyoshi Matsuzaki
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
MITSUNARI Shigeo
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
Kohei Tokunaga
コルーチンでC++でも楽々ゲーム作成!
コルーチンでC++でも楽々ゲーム作成!
amusementcreators
メタプログラミングって何だろう
メタプログラミングって何だろう
Kota Mizushima
Meltdown を正しく理解する
Meltdown を正しく理解する
Norimasa FUJITA
ゼロから始める自作 CPU 入門
ゼロから始める自作 CPU 入門
Hirotaka Kawata
Más contenido relacionado
La actualidad más candente
ARM Trusted FirmwareのBL31を単体で使う!
ARM Trusted FirmwareのBL31を単体で使う!
Mr. Vengineer
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
KiyotomoHiroyasu
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
sonickun
PyOpenCLによるGPGPU入門
PyOpenCLによるGPGPU入門
Yosuke Onoue
プログラムを高速化する話
プログラムを高速化する話
京大 マイコンクラブ
Docker Compose 徹底解説
Docker Compose 徹底解説
Masahito Zembutsu
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
alwei
C++ マルチスレッドプログラミング
C++ マルチスレッドプログラミング
Kohsuke Yuasa
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
Kentaro Matsui
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
Masami Hiramatsu
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
Takateru Yamagishi
非同期処理の基礎
非同期処理の基礎
信之 岩永
LLVM最適化のこつ
LLVM最適化のこつ
MITSUNARI Shigeo
プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜
京大 マイコンクラブ
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Masahiro Sakai
Minecraft による強化学習の実践 (MineRL)
Minecraft による強化学習の実践 (MineRL)
Tusyoshi Matsuzaki
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
MITSUNARI Shigeo
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
Kohei Tokunaga
コルーチンでC++でも楽々ゲーム作成!
コルーチンでC++でも楽々ゲーム作成!
amusementcreators
メタプログラミングって何だろう
メタプログラミングって何だろう
Kota Mizushima
La actualidad más candente
(20)
ARM Trusted FirmwareのBL31を単体で使う!
ARM Trusted FirmwareのBL31を単体で使う!
RustによるGPUプログラミング環境
RustによるGPUプログラミング環境
RSA暗号運用でやってはいけない n のこと #ssmjp
RSA暗号運用でやってはいけない n のこと #ssmjp
PyOpenCLによるGPGPU入門
PyOpenCLによるGPGPU入門
プログラムを高速化する話
プログラムを高速化する話
Docker Compose 徹底解説
Docker Compose 徹底解説
カスタムメモリマネージャと高速なメモリアロケータについて
カスタムメモリマネージャと高速なメモリアロケータについて
C++ マルチスレッドプログラミング
C++ マルチスレッドプログラミング
テスト文字列に「うんこ」と入れるな
テスト文字列に「うんこ」と入れるな
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
CUDAのアセンブリ言語基礎のまとめ PTXとSASSの概説
非同期処理の基礎
非同期処理の基礎
LLVM最適化のこつ
LLVM最適化のこつ
プログラムを高速化する話Ⅱ 〜GPGPU編〜
プログラムを高速化する話Ⅱ 〜GPGPU編〜
SAT/SMTソルバの仕組み
SAT/SMTソルバの仕組み
Minecraft による強化学習の実践 (MineRL)
Minecraft による強化学習の実践 (MineRL)
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
コルーチンでC++でも楽々ゲーム作成!
コルーチンでC++でも楽々ゲーム作成!
メタプログラミングって何だろう
メタプログラミングって何だろう
Similar a SpectreとMeltdown:最近のCPUの深い話
Meltdown を正しく理解する
Meltdown を正しく理解する
Norimasa FUJITA
ゼロから始める自作 CPU 入門
ゼロから始める自作 CPU 入門
Hirotaka Kawata
自作コンピューターでなんかする - 第八回 カーネル/VM探検隊&懇親会
自作コンピューターでなんかする - 第八回 カーネル/VM探検隊&懇親会
Hirotaka Kawata
seccamp2012 チューター発表
seccamp2012 チューター発表
Hirotaka Kawata
Cpu idle expedition
Cpu idle expedition
cota2n
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
Hirotaka Kawata
Tremaで試すFirewall
Tremaで試すFirewall
M Hagiwara
Graviton2プロセッサの性能特性と適用箇所/Supership株式会社 中野 豊
Graviton2プロセッサの性能特性と適用箇所/Supership株式会社 中野 豊
Supership株式会社
kagami_comput2015_14
kagami_comput2015_14
swkagami
機械学習 / Deep Learning 大全 (6) Library編
機械学習 / Deep Learning 大全 (6) Library編
Daiyu Hatakeyama
katagaitaictf7_hw_ysk
katagaitaictf7_hw_ysk
ysk256
バイナリより低レイヤな話 (プロセッサの心を読み解く) - カーネル/VM探検隊@北陸1
バイナリより低レイヤな話 (プロセッサの心を読み解く) - カーネル/VM探検隊@北陸1
Hirotaka Kawata
ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
Atsushi Koshiba
[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文
[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文
CODE BLUE
kagamicomput201814
kagamicomput201814
swkagami
短距離古典分子動力学計算の 高速化と大規模並列化
短距離古典分子動力学計算の 高速化と大規模並列化
Hiroshi Watanabe
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
信之 岩永
OpenStack with OpenFlow
OpenStack with OpenFlow
Toshiki Tsuboi
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50
Preferred Networks
kagami_comput2016_14
kagami_comput2016_14
swkagami
Similar a SpectreとMeltdown:最近のCPUの深い話
(20)
Meltdown を正しく理解する
Meltdown を正しく理解する
ゼロから始める自作 CPU 入門
ゼロから始める自作 CPU 入門
自作コンピューターでなんかする - 第八回 カーネル/VM探検隊&懇親会
自作コンピューターでなんかする - 第八回 カーネル/VM探検隊&懇親会
seccamp2012 チューター発表
seccamp2012 チューター発表
Cpu idle expedition
Cpu idle expedition
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
30日でできない!コンピューター自作入門 - カーネル/VM探検隊@つくば
Tremaで試すFirewall
Tremaで試すFirewall
Graviton2プロセッサの性能特性と適用箇所/Supership株式会社 中野 豊
Graviton2プロセッサの性能特性と適用箇所/Supership株式会社 中野 豊
kagami_comput2015_14
kagami_comput2015_14
機械学習 / Deep Learning 大全 (6) Library編
機械学習 / Deep Learning 大全 (6) Library編
katagaitaictf7_hw_ysk
katagaitaictf7_hw_ysk
バイナリより低レイヤな話 (プロセッサの心を読み解く) - カーネル/VM探検隊@北陸1
バイナリより低レイヤな話 (プロセッサの心を読み解く) - カーネル/VM探検隊@北陸1
ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
ASPLOS2017: Building Durable Transactions with Decoupling for Persistent Memory
[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文
[CB19] Semzhu-Project – 手で作る組込み向けハイパーバイザと攻撃検知手法の新しい世界 by 朱義文
kagamicomput201814
kagamicomput201814
短距離古典分子動力学計算の 高速化と大規模並列化
短距離古典分子動力学計算の 高速化と大規模並列化
C# 7.2 with .NET Core 2.1
C# 7.2 with .NET Core 2.1
OpenStack with OpenFlow
OpenStack with OpenFlow
Topology Managerについて / Kubernetes Meetup Tokyo 50
Topology Managerについて / Kubernetes Meetup Tokyo 50
kagami_comput2016_14
kagami_comput2016_14
Más de LINE Corporation
JJUG CCC 2018 Fall 懇親会LT
JJUG CCC 2018 Fall 懇親会LT
LINE Corporation
Reduce dependency on Rx with Kotlin Coroutines
Reduce dependency on Rx with Kotlin Coroutines
LINE Corporation
Kotlin/NativeでAndroidのNativeメソッドを実装してみた
Kotlin/NativeでAndroidのNativeメソッドを実装してみた
LINE Corporation
Use Kotlin scripts and Clova SDK to build your Clova extension
Use Kotlin scripts and Clova SDK to build your Clova extension
LINE Corporation
The Magic of LINE 購物 Testing
The Magic of LINE 購物 Testing
LINE Corporation
GA Test Automation
GA Test Automation
LINE Corporation
UI Automation Test with JUnit5
UI Automation Test with JUnit5
LINE Corporation
Feature Detection for UI Testing
Feature Detection for UI Testing
LINE Corporation
LINE 新星計劃介紹與新創團隊分享
LINE 新星計劃介紹與新創團隊分享
LINE Corporation
LINE 技術合作夥伴與應用分享
LINE 技術合作夥伴與應用分享
LINE Corporation
LINE 開發者社群經營與技術推廣
LINE 開發者社群經營與技術推廣
LINE Corporation
日本開發者大會短講分享
日本開發者大會短講分享
LINE Corporation
LINE Chatbot - 活動報名報到設計分享
LINE Chatbot - 活動報名報到設計分享
LINE Corporation
在 LINE 私有雲中使用 Managed Kubernetes
在 LINE 私有雲中使用 Managed Kubernetes
LINE Corporation
LINE TODAY高效率的敏捷測試開發技巧
LINE TODAY高效率的敏捷測試開發技巧
LINE Corporation
LINE 區塊鏈平台及代幣經濟 - LINK Chain及LINK介紹
LINE 區塊鏈平台及代幣經濟 - LINK Chain及LINK介紹
LINE Corporation
LINE Things - LINE IoT平台新技術分享
LINE Things - LINE IoT平台新技術分享
LINE Corporation
LINE Pay - 一卡通支付新體驗
LINE Pay - 一卡通支付新體驗
LINE Corporation
LINE Platform API Update - 打造一個更好的Chatbot服務
LINE Platform API Update - 打造一個更好的Chatbot服務
LINE Corporation
Keynote - LINE 的技術策略佈局與跨國產品開發
Keynote - LINE 的技術策略佈局與跨國產品開發
LINE Corporation
Más de LINE Corporation
(20)
JJUG CCC 2018 Fall 懇親会LT
JJUG CCC 2018 Fall 懇親会LT
Reduce dependency on Rx with Kotlin Coroutines
Reduce dependency on Rx with Kotlin Coroutines
Kotlin/NativeでAndroidのNativeメソッドを実装してみた
Kotlin/NativeでAndroidのNativeメソッドを実装してみた
Use Kotlin scripts and Clova SDK to build your Clova extension
Use Kotlin scripts and Clova SDK to build your Clova extension
The Magic of LINE 購物 Testing
The Magic of LINE 購物 Testing
GA Test Automation
GA Test Automation
UI Automation Test with JUnit5
UI Automation Test with JUnit5
Feature Detection for UI Testing
Feature Detection for UI Testing
LINE 新星計劃介紹與新創團隊分享
LINE 新星計劃介紹與新創團隊分享
LINE 技術合作夥伴與應用分享
LINE 技術合作夥伴與應用分享
LINE 開發者社群經營與技術推廣
LINE 開發者社群經營與技術推廣
日本開發者大會短講分享
日本開發者大會短講分享
LINE Chatbot - 活動報名報到設計分享
LINE Chatbot - 活動報名報到設計分享
在 LINE 私有雲中使用 Managed Kubernetes
在 LINE 私有雲中使用 Managed Kubernetes
LINE TODAY高效率的敏捷測試開發技巧
LINE TODAY高效率的敏捷測試開發技巧
LINE 區塊鏈平台及代幣經濟 - LINK Chain及LINK介紹
LINE 區塊鏈平台及代幣經濟 - LINK Chain及LINK介紹
LINE Things - LINE IoT平台新技術分享
LINE Things - LINE IoT平台新技術分享
LINE Pay - 一卡通支付新體驗
LINE Pay - 一卡通支付新體驗
LINE Platform API Update - 打造一個更好的Chatbot服務
LINE Platform API Update - 打造一個更好的Chatbot服務
Keynote - LINE 的技術策略佈局與跨國產品開發
Keynote - LINE 的技術策略佈局與跨國產品開發
SpectreとMeltdown:最近のCPUの深い話
1.
Spectre と Meltdown: 最近の
CPU の深い話 LINE Developer Meetup #42 @京都 2018/07/26 LINE 株式会社 開発1センター LINE開発1室 Hirotaka Kawata @hktechno
2.
自己紹介 川田 裕貴 (Hirotaka
Kawata) @hktechno ● 開発1センター LINE 開発1室 ○ LINE スタンプ・着せかえ・絵文字ショップの開発 ○ IoT 関連のことを少々 ● 昔話: 友達と FPGA で自作 CPU を作っていた ○ 主にコンパイラ (gcc の移植) をしていた ○ 本を書いた http://amzn.asia/g2NTIUW ● セキュリティ・キャンプ全国大会2018 講師 ○ 同じような話をする予定
3.
Spectre・Meltdown って何?
4.
Spectre と Meltdown
について CPU を対象としたサイドチャネル攻撃に対する脆弱性 ● 2018年1月に Google の Project Zero などが共同で公開した 論文が発端 ○ https://meltdownattack.com/ ● オリジナルの手法は大きく分けて3つ (Variant 1,2,3) ○ Variant 3 のことを特に Meltdown と呼ぶ ● 現代の CPU アーキテクチャを巧妙に操ることにより、 サイドチャネル攻撃を可能に ○ 具体的には、メモリ内容の吸い取り
5.
Spectre / Meltdown
の手法の概要 Code Name 通称 CVE Spectre Variant 1 Bounds Check Bypass CVE-2017-5753 Variant 2 Branch Target Injection CVE-2017-5715 Meltdown Variant 3 Rouge Cache Data Load CVE-2017-5754 Spectre / Meltdown には、大きく3つの手法が存在する
6.
Spectre / Meltdown
の手法の概要 条件分岐の悪用 分岐予測をトレーニングし、 メモリアクセスの境界値 チェックをバイパスして実行 例えば... 本来は読み取りが行われ ないはずのメモリ領域の データを、吸い出すことが 可能。 Spectre Variant 2 間接分岐命令の悪用 うまいこと ROP 的な手法で 分岐予測をトレーニングし た上で狙ったコードを実行 例えば... 本来は読み取りが行われ ないはずのメモリ領域の データを、吸い出すことが 可能。 Meltdown (Variant 3) 特権レベルのバイパス 本来は例外が発生し実行さ れないコードを、特権レベ ルのチェックをバイパスして 実行 例えば... 本来は読み取ることができ ないメモリ領域のデータを、 吸い出すことが可能。 Spectre Variant 1 説明しなければいけないこと が多すぎるので、 今回は、雰囲気だけ ...
7.
サイドチャネル攻撃とは 攻撃対象に直接手を加えるのではなく、動作を観察することによ り、その挙動の違いから情報を得ようとする手法 ● Spectre, Meltdown
においては、本来読み取れない領域にあ るメモリ内のデータを推測する手法 ○ 具体的には、メモリアクセスの時間の差を使う ● メモリ内のデータを ”直接” 読み取るわけではない ○ (実際は読み取っているわけだが... 詳細は後述) ● 元のプログラムに手を加える必要がなく、 攻撃を成功することができる (可能性がある)
8.
Meltdown と Spectre
の難しい点 よく CPU アーキテクチャを理解していないと、理解困難 ● アセンブリが書けるだけでは、知識が足りない ● 繊細な CPU の気持ちを、よくわかっている必要がある ハードウェア由来の脆弱性、ソフトウェアでの対策が困難 ● 不可能ではないが、パフォーマンスの低下を伴う ● Spectre Variant 2 については、一部のアーキテクチャでは ハードウェア支援がないと対策がとても難しい
9.
サイドチャネル攻撃 - Flush
+ Reload メモリアクセスのレイテンシの差を利用した攻撃 1. キャッシュをクリア (特に、以下の array2 の領域) ○ キャッシュを追い出す (Eviction) させてもいい 2. メモリを間接的にアクセスさせる ○ y = array2[array[x] * 4096] ○ array[x] のメモリ内容を基に array2 にアクセスする ○ 4096 をかけるのは、プリフェッチを防ぐため 3. array2 のアクセスレイテンシを調べる ○ キャッシュに乗っていればレイテンシ低⇓ ○ 過去にアクセスされた可能性大 => 値がわかる
10.
時間のかかる何か if (Array 境界値チェック) array1[array2[x]] その先の何か サイドチャネル攻撃
- Flush + Reload array2 攻撃対象 array1 CPU 時間かかるなぁ ここはよく true だから今回も true のときの 処理を投機的に実行だ! 間違ってたらあとでやりなおす!
11.
サイドチャネル攻撃 - Flush
+ Reload array2 攻撃対象 data[x] = 0xa array1 CPU 時間のかかる何か if (Array 境界値チェック) array1[array2[x]] その先の何か まだ終わってない x は確定していた! array[0xa] もアクセスできる! キャッシュに乗る! 準備完了 先に実行だ!
12.
サイドチャネル攻撃 - Flush
+ Reload array2 攻撃対象 data[x] = 0xa array1 CPU array1 を Flush 時間のかかる何か if (Array 境界値チェック) array1[array2[x]] その先の何か array1 を Reload Array1 のキャッシュを消す Array1 のアクセスレイテンシをチェック 過去にアクセスしたことがあれば速い。 レイテンシの差で、array2 のデータがわかる...
13.
基本的な CPU の仕組みのおさらい
14.
基本的な CPU パイプライン ●
Instruction Fetch ● Instruction Buffer ● Instruction Decode ● Dispatch ● Execution IB
15.
Intel Skylake の内部 ●
命令は uOps に分解 ● 8個 / Core の実行ユニット ○ ALU: 4 ○ Branch: 2 ○ Load: 2 ● コア内部でも並列 ○ 1コア最大8命令を同時に 実行開始可能 ● デコーダを極力休める設計 ○ 命令セットが...
16.
現代の CPU と Meltdown
/ Spectre の関係
17.
Meltdown / Spectre
がなぜ起きるのか 現代の CPU が命令を実行する際に行う、高度なハードウェアレ ベルでの最適化が原因 ● 特に、”投機的実行 (Speculative Execution)” と呼ばれる、命 令を先読みして高速化する手法が問題 CPU 内で行われる投機的実行の例 ● 命令のプリフェッチ ● ☆ アウト・オブ・オーダー実行 (順序を守らない実行) ● ☆ 分岐予測器を組み合わせた投機的実行
18.
“投機的” に命令列を実行して、間違っていたら結果を捨てる ● アセンブリに書かれた命令の順番通りには実行しないこともあ る ○
とにかく、パイプラインに隙間が生まれないように ● 間違って実際には実行されない命令を、先読みして実行してし まうことがある ○ 最終的な結果には影響が出ないように結果を捨てる ○ 現代の CPU では、間違うことはかなり少ない うまく使うと脆弱性につながる可能性が...? 現代の CPU における投機的実行
19.
Out of Order Execution アウト・オブ・オーダー実行 CPU
の命令が上から順番に実行され るなんて、誰が言った!
20.
アウト・オブ・オーダー実行 (Out of Order
Execution, OoO) 先読みした命令の依存関係を解析して、実行できる命令から実際 の記述順序を無視して先に実行する ● 命令間のレジスタ依存関係を動的に解析する ○ 例えば、即値ロード命令は他の命令と依存関係がない ○ 即値ロード命令の例: mov eax, 0x1 ● CPU は、複数の命令実行ポートを持っている ○ すべての命令が同時に実行完了するとは限らない ● 依存しているレジスタの結果が準備されたら、先に実行 ○ レジスタマッピングや、書き戻しのバッファリングにより整 合性を保つ
21.
アウト・オブ・オーダー実行の例 mov eax, [eax] xor
ebx, ebx add ebx, eax inc ecx add eax, ecx Load (遅い) ↑の命令とは依存がない ↑の命令とは依存がない ※ 簡単な例で、特にアセンブリに意味はない
22.
アウト・オブ・オーダー実行の例 mov eax, [eax] xor
ebx, ebx add ebx, eax inc ecx add eax, ecx Load (遅い) ↑の命令とは依存がない ↑の命令とは依存がない 1 2 3 2 3 ⇓実行順 命令の順番を入れ替えても構わない しかも、開いてるポートで並列に実行できる
23.
アウト・オブ・オーダー実行の疑問 ● あるレジスタ (eax
や ebx) は CPU 内に1つじゃないの? ○ レジスタ・リネーミングを利用しています ○ 実はすべてただのエイリアスです ● CPU 内部で ”同時” に実行できる命令は1つじゃないの? ○ 複数の命令実行ポートが並列に並べられています ○ 例えば、Haswell 以降なら8実行ポート ● メモリアクセスを行う命令も並列に実行するの? ○ Intel の最近の CPU はメモリアクセスも OoO です ● なんでコンパイラでやらないの? ○ 成功していたら Itanium は死んでいない
24.
アウト・オブ・オーダー実行を支える技術 - 1 レジスタ・リネーミング
(Register Renaming) ● 物理レジスタを、内部の仮想レジスタにリネームする ● 命令の依存をより少なくできる mov eax, [eax] inc eax mov [eax], eax mov eax, ebx mov eax, [eax] 同じ eax レジスタ しかし、依存はない 実は先に実行可能
25.
アウト・オブ・オーダー実行を支える技術 - 1 レジスタ・リネーミング
(Register Renaming) ● 内部的なレジスタファイル内の物理レジスタと、論理レジスタ (eax, ebx…) との対応を持つ ○ 論理レジスタの数倍の物理レジスタを持っている mov r1, [r1] inc r1 mov [r1], r1 mov r3, r2 mov r3, [r3] レジスタ依存はない 先に実行可能
26.
アウト・オブ・オーダー実行を支える技術 - 2 Tomasulo
のアルゴリズム ● Reservation Station ○ 命令の依存関係を待つところ ○ ソースレジスタが利用可能かを監視して、 実行可能であれ ば実行を開始する ○ Unified な方式、実行ポートごとに持たせる方式 ● Re-order Buffer ○ 命令のコミットを制御するバッファ ○ 演算の結果は一度ここへ書かれる ※ 実際の Intel の CPU がこの通り実装されているわけではない
27.
Reservation Station の例 Reservation
Station 命令1 SRC1 NG SRC2 OK 命令2 NG NG 命令3 OK NG 命令4 OK OK Reorder Buffer, Register File Execution ステージへ
28.
Reorder Buffer を使ったデータの流れ Reorder
Buffer Stage 1. 割り当て Writeback Stage 2. 結果の書き込み Retire / Commit Reorder Buffer Register File 3. コミット
29.
Branch Prediction 分岐予測 運命の分かれ道
30.
分岐予測 (Branch Prediction) ブランチ命令で分岐する場合、行き先を予測して先に命令を読み 出し・実行を行う ●
Intel x86 でいうとジャンプ系の命令 Jxx (jne, je, jz…) ● 分岐するかしないか (“Taken” or “Not Taken”) および、 その分岐先をハードウェアで動的に予測する ○ 基本的に、過去の分岐結果をもとに分岐先を予測する ○ CPU 内部に過去の分岐履歴を保存している ● 予測した分岐先の命令を先読みして、実行する ○ 現代の CPU では予測成功率 99% 以上 (個人的な感想)
31.
分岐予測の例 - 簡単な分岐命令 mov
eax, [eax] cmp eax, 0 je is_zero ... ... is_zero: ... ... 実行完了するまで Jump するかわからない Load (遅い) Block 1 Block 2 Block1 or Block2 どちらかを投機的に実行したいが、高 確率で正解を選びたい 基本的な if 文であれば PC 相対ジャンプであることが多い
32.
分岐予測器 (Branch Predictor) 古典的な実装 ●
分岐しない (or する) 方向で常に予測しておく ○ x86 だと Pentium 以前の CPU はこれ (i486 とか) ● 飽和カウンター (Bi-modal Counter) ○ 4つのステートを持って、1度ミスしただけでは予測方向が 変わらないような方式 ○ ループの分岐予測には有効
33.
分岐予測器 - 最近の
CPU の実装 いくつかの方式の組み合わせで、あらゆるパターンでも予測 ● 局所的分岐予測 ○ 同じアドレスの命令の、過去の分岐履歴を利用 ○ 同じアドレスで、同じパターンを繰り返す場合有用 ● グローバル分岐予測 ○ 過去のコア全体の分岐履歴のパターンをもとに、次の分岐 の挙動を予測 ● 上記の組み合わせを bit 演算で行い、予測テーブルを引く ○ PC + 局所履歴 + グローバル履歴 ○ 具体的な実装は後述
34.
分岐予測の例 - 絶対アドレス間接ジャンプ (Indirect
Branch) レジスタに格納されたアドレスにジャンプする場合 ● レジスタに格納されたアドレスが確定するまで、投機的実行が できない ○ これまでの手法は、PC 相対 + 即値ジャンプの場合 ○ 間接ジャンプで、特にLoad が噛むととても遅い ● 間接ジャンプ先も、実は予測可能では? ○ 同じ PC のジャンプは、よく同じアドレスにジャンプするので はないか? ● BTB (Branch Target Buffer) というテーブルを持つ ※ PC (Program Counter): Intel では IP (Instruction Pointer) 実行中命令のアドレスのこと
35.
現代の CPU の分岐予測器の進化 分岐予測器の進化は、最近でも続いている
(というかアツい) ● 電力をそれほど消費せずに性能向上が可能 ○ 分岐予測のミスは大きなペナルティ ○ ブランチ命令の先のパイプラインが止まってしまう ● ニューラルネットワーク分岐予測機 ○ AMD の CPU? Intel も? ● 各社詳しい仕様は公開していない ○ 改良されたという事実のみが記載されている ○ 外側から観察して挙動を推測するのみ
36.
Spectre Variant 1
37.
Spectre Variant 1 分岐予測をコントロールして、実際とは異なる方向に予測させた 上で、メモリ領域を吸い出す if
(x < array1_size) y = array2[array1[x] * 4096]; ● 予め正規の x で何度か実行し、分岐予測を訓練させる ● x を悪意のあるもの (array1_size 以上など) に設定 ○ array2 の領域の読み取りが投機的実行されてしまう ○ Flush + Reload により読み取り可能
38.
Spectre Variant 1
対策 array の index のビットをマスクする ● array の外側にアクセスできないようにすればいい ○ ブランチ命令はいくらでも学習可能なので使えない ○ 投機的実行が起きても問題ないように ● ビット演算のみで行う ○ パフォーマンス低下もそれほどではない ● Linux Kernel : array_index_nospec ○ https://github.com/torvalds/linux/blob/v4.17/include/l inux/nospec.h#L49
39.
Meltdown - Spectre
Variant 3
40.
Meltdown - Spectre
Variant 3 ユーザー権限で任意のメモリ領域の内容を推測可能な脆弱性 ● Spectre シリーズの中で最もリスクが高い (個人的な感想) ● カーネル空間に物理メモリがそのままマップされている ○ Linux (x86_64) の場合 0xffff800000000000 ○ 通常は、ユーザーモードから読むことは不可能 ● 投機的実行と CPU の特権レベルの関わりが影響 ○ 特権レベルを無視して CPU が投機的実行を行う ○ 投機的実行を行ったあとに、特権違反により例外発生 ○ キャッシュの内容は...?
41.
Meltdown の裏側 -
投機的実行 コードでは3行で説明できるぐらい簡単 ● 裏で何が起きているのかを説明するのが難しい ... raise_exception(); // 実際はここまで // 以下の行には到達しない, でも OoO で実行されてる access(probe_array[data * 4096]); CPU の投機的実行は何を行うのだろう?
42.
Meltdown の裏側 -
投機的実行 kernel_adder の内容を Flush+Reload で推測する例 raise_exception(); access(probe_array[*kernel_addr * 4096]); 投機的実行により、kernel_addr と proble_array の load が raise_exception() より先に行われる ● 特権レベルの確認は、後から行われる ● proble_array を Flush + Reload で *kernel_addr を吸い出し
43.
Meltdown の裏側 -
投機的実行 Meltdown のアセンブリの例 ; rcx = kernel address ; rbx = probe array retry: mov al, byte [rcx] ; 実際はここで例外 shl rax, 0xc jz retry mov rbx, qword [rbx + rax]
44.
仮想アドレス空間のメモリマップ - Linux
x86_64 物理メモリすべての領域が 0xffff800000000000 からマップ ● ユーザー領域は仮想アドレス空間の先頭に配置 ● 後半部分に、物理メモリすべてがストレートマップ ○ つまり、物理メモリに乗っていれば、すべてのユーザー空 間・カーネル空間のメモリにアクセス可能
45.
なぜ、物理メモリをすべてマップするのか? システムコール・コンテキストスイッチの高速化のため ● ページテーブル切り替えのコストを削減 ○ カーネル空間が別ページテーブルであれば... ■
システムコール毎に、ページテーブル切替 + TLB フラッシュ ○ カーネル空間のアドレスがページテーブル (プロセス) ごと に異なるならば... ■ Global Page が使えない => カーネル空間の TLB が毎回消される ● TLB フラッシュは大きなコスト ○ ページウォーク => メモリアクセス ○ カーネル空間を常に TLB に載せておきたい
46.
Meltdown 対策 Kernel Page
Table Isolation : KPTI ● カーネルページテーブルの分離 ○ ユーザープロセスのページテーブルから、カーネル領域が 見えないように ○ Linux では KAISER という仕組みを実装 ● パフォーマンス低下の問題 ○ 最近の Intel CPU では、PCID 関連サポートが有る ■ Haswell 以降 ○ 新しい Kernel + CPU を使っていれば問題ない
47.
Spectre Variant 2
48.
Spectre Variant 2 BTB
(Branch Target Buffer) と分岐履歴をコントロールして、上 手に特定のアドレスの命令を投機的実行させる ● BTB は、コア内で共通である ● 同じコア違うプロセスで、同一のメモリマップのプログラムを走 らせ、うまいこと BTB と分岐履歴を訓練 ○ 例えば、SMT (HT) で動作している場合など ● その中でアクセスしたデータはキャッシュに残る ○ もしかしたらデータを抜き出せるかもしれない ○ あまり成功率は高くない ● 対策: Retpoline, (IBRS, IBPB, STIBP) 命令
49.
まとめ
50.
Spectre / Meltdown
まとめ ● Meltdown は大きな影響がある ○ Kernel 領域のメモリ領域の推測が比較的簡単に可能 ○ 対策も、CPU によっては大きなパフォーマンス低下 ○ 最新の CPU + 最新の Kernel では影響が緩和 ● Spectre は...? ○ ハードウェアの根本的な動作が原因で、対策が難しい ○ 沢山の派生手法、Intel 以外の CPU でも発生 ○ 対策により多少のパフォーマンス低下が発生 ○ Spectre 単体でのリスクはそれほど高くない