Submit Search
Upload
SpectreとMeltdown:最近のCPUの深い話
•
6 likes
•
2,879 views
LINE Corporation
Follow
LINE Developer Meetup
Read less
Read more
Technology
Slideshow view
Report
Share
Slideshow view
Report
Share
1 of 50
Recommended
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
wata2ki
Glibc malloc internal
Glibc malloc internal
Motohiro KOSAKI
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
Takaaki Suzuki
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
constexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだ
constexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだ
Genya Murakami
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
Recommended
本当にわかる Spectre と Meltdown
本当にわかる Spectre と Meltdown
Hirotaka Kawata
ARM LinuxのMMUはわかりにくい
ARM LinuxのMMUはわかりにくい
wata2ki
Glibc malloc internal
Glibc malloc internal
Motohiro KOSAKI
今日からできる!簡単 .NET 高速化 Tips
今日からできる!簡単 .NET 高速化 Tips
Takaaki Suzuki
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
トランザクションの設計と進化
トランザクションの設計と進化
Kumazaki Hiroki
constexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだ
constexpr関数はコンパイル時処理。これはいい。実行時が霞んで見える。cpuの嬌声が聞こえてきそうだ
Genya Murakami
新入社員のための大規模ゲーム開発入門 サーバサイド編
新入社員のための大規模ゲーム開発入門 サーバサイド編
infinite_loop
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
Masami Hiramatsu
Ethernetの受信処理
Ethernetの受信処理
Takuya ASADA
最速C# 7.x
最速C# 7.x
Yamamoto Reki
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
ELFの動的リンク
ELFの動的リンク
7shi
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
Kohei Tokunaga
知っているようで知らないPAMのお話
知っているようで知らないPAMのお話
Serverworks Co.,Ltd.
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
VirtualTech Japan Inc.
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
MITSUNARI Shigeo
例外設計における大罪
例外設計における大罪
Takuto Wada
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
Gosuke Miyashita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Marp Tutorial
Marp Tutorial
Rui Watanabe
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
中3女子でもわかる constexpr
中3女子でもわかる constexpr
Genya Murakami
Meltdown を正しく理解する
Meltdown を正しく理解する
Norimasa FUJITA
ゼロから始める自作 CPU 入門
ゼロから始める自作 CPU 入門
Hirotaka Kawata
More Related Content
What's hot
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
Kumazaki Hiroki
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
Masami Hiramatsu
Ethernetの受信処理
Ethernetの受信処理
Takuya ASADA
最速C# 7.x
最速C# 7.x
Yamamoto Reki
並行実行制御の最適化手法
並行実行制御の最適化手法
Sho Nakazono
ELFの動的リンク
ELFの動的リンク
7shi
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
Kohei Tokunaga
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
Kohei Tokunaga
知っているようで知らないPAMのお話
知っているようで知らないPAMのお話
Serverworks Co.,Ltd.
DockerとPodmanの比較
DockerとPodmanの比較
Akihiro Suda
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
VirtualTech Japan Inc.
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
MITSUNARI Shigeo
例外設計における大罪
例外設計における大罪
Takuto Wada
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
Gosuke Miyashita
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Kumazaki Hiroki
Marp Tutorial
Marp Tutorial
Rui Watanabe
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
Yahoo!デベロッパーネットワーク
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
kazuhcurry
中3女子でもわかる constexpr
中3女子でもわかる constexpr
Genya Murakami
What's hot
(20)
トランザクションをSerializableにする4つの方法
トランザクションをSerializableにする4つの方法
SpectreBustersあるいはLinuxにおけるSpectre対策
SpectreBustersあるいはLinuxにおけるSpectre対策
Ethernetの受信処理
Ethernetの受信処理
最速C# 7.x
最速C# 7.x
並行実行制御の最適化手法
並行実行制御の最適化手法
ELFの動的リンク
ELFの動的リンク
Dockerからcontainerdへの移行
Dockerからcontainerdへの移行
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
今話題のいろいろなコンテナランタイムを比較してみた
今話題のいろいろなコンテナランタイムを比較してみた
知っているようで知らないPAMのお話
知っているようで知らないPAMのお話
DockerとPodmanの比較
DockerとPodmanの比較
ゼロからはじめるKVM超入門
ゼロからはじめるKVM超入門
C/C++プログラマのための開発ツール
C/C++プログラマのための開発ツール
例外設計における大罪
例外設計における大罪
イベント駆動プログラミングとI/O多重化
イベント駆動プログラミングとI/O多重化
本当は恐ろしい分散システムの話
本当は恐ろしい分散システムの話
Marp Tutorial
Marp Tutorial
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
At least onceってぶっちゃけ問題の先送りだったよね #kafkajp
PG-REXで学ぶPacemaker運用の実例
PG-REXで学ぶPacemaker運用の実例
中3女子でもわかる constexpr
中3女子でもわかる constexpr
Similar to 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 to 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
More from 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
More from 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 的技術策略佈局與跨國產品開發
Recently uploaded
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
CRI Japan, Inc.
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NTT DATA Technology & Innovation
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
CRI Japan, Inc.
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Hiroshi Tomioka
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
Toru Tamaki
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
atsushi061452
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
iPride Co., Ltd.
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Hiroshi Tomioka
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
Toru Tamaki
Recently uploaded
(11)
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
LoRaWAN スマート距離検出デバイスDS20L日本語マニュアル
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
NewSQLの可用性構成パターン(OCHaCafe Season 8 #4 発表資料)
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
LoRaWANスマート距離検出センサー DS20L カタログ LiDARデバイス
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
業務で生成AIを活用したい人のための生成AI入門講座(社外公開版:キンドリルジャパン社内勉強会:2024年4月発表)
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その22024/04/26の勉強会で発表されたものです。
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
論文紹介:Video-GroundingDINO: Towards Open-Vocabulary Spatio-Temporal Video Groun...
新人研修 後半 2024/04/26の勉強会で発表されたものです。
新人研修 後半 2024/04/26の勉強会で発表されたものです。
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
論文紹介: The Surprising Effectiveness of PPO in Cooperative Multi-Agent Games
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Amazon SES を勉強してみる その32024/04/26の勉強会で発表されたものです。
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
Observabilityは従来型の監視と何が違うのか(キンドリルジャパン社内勉強会:2022年10月27日発表)
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
論文紹介:Selective Structured State-Spaces for Long-Form Video Understanding
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 単体でのリスクはそれほど高くない