如何看待 2018 年 1 月 2 日爆出的 Intel CPU 設計漏洞？

01-06

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

目前已知的消息（我不完全確定是這樣）

此漏洞會導致低許可權應用訪問到內核內存
此漏洞是硬體設計導致的，無法使用microcode修復，只能進行OS級的修復
OS級的修復會導致嚴重的性能問題，將會導致5%-30%的性能下降
目前phoronix已對此進行了測試，IO性能幾乎下降了50%，編譯性能下降了接近30%，postgresql和redis也有差不多20%的性能下跌，詳細地址：

Initial Benchmarks Of The Performance Impact Resulting From Linuxamp;amp;amp;amp;#x27;s x86 Security Changeswww.phoronix.com

AMD不受此漏洞影響

Report: Intel CPUs suffer from major security flaw, fix could bring notable performance hit to macOS9to5mac.com

-- 英文版的詳細信息

Intel: Details und Benchmarks zur Sicherheitslücke in allen CPUswww.computerbase.de

-- 最早的新聞來源

@vczh 順便讓輪子哥來作答………………

===========================

2018年1月4日的更新：

根據某發行版Linux的內核組基友的說明，目前推測的性能影響大部分可以取5%的下限，影響最大的是IO頻繁的應用環境，所以最大的影響應該是各大公司的資料庫伺服器。

===========================

繼續更新：

這一次由Intel伺服器CPU產品誘發的安全事故現在規模正式擴大，確認波及到ARM和AMD，也就是說，近二十年來生產的幾乎一切手機、電腦、雲計算產品都在風險之列。

安全人員將兩個新的漏洞命名為Meltdown（熔斷）和Spectre（幽靈），前者允許低許可權、用戶級別的應用程序「越界」訪問系統級的內存，從而造成數據泄露。

聽說是由Google Zero團隊發現的，目前這個規模就真的很大了……

Spectre affects Intel, AMD, and ARM processors, broadening its reach to include mobile phones, embedded devices, and pretty much anything with a chip in it. Which, of course, is everything from thermostats to baby monitors now.

It works differently from Meltdown; Spectre essentially tricks applications into accidentally disclosing information that would normally be inaccessible, safe inside their protected memory area. This is a trickier one to pull off, but because it』s based on an established practice in multiple chip architectures, it』s going to be even trickier to fix.

主要麻煩的是幽靈這個漏洞………………影響全部CPU………………不單止可以從內核態泄露，虛擬化的也可以………………而且目前沒有有效的可行性修復方法………………

參考新聞來源：

Kernel panic! What are Meltdown and Spectre, the bugs affecting nearly every computer and device?techcrunch.com

「Meltdown」 and 「Spectre」: Every modern processor has unfixable security flawsarstechnica.com

有新消息會繼續更新。

===================================

from Google Zero：

Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running on them.

There is no single fix for all three attack variants; each requires protection independently. Many vendors have patches available for one or more of these attacks.

We will continue our work to mitigate these vulnerabilities and will update both our product support page and this blog post as we release further fixes. More broadly, we appreciate the support and involvement of all the partners and Google engineers who worked tirelessly over the last few months to make our users and customers safe.

==================================

貼一下目前最終的結論

Google Project Zero 和奧地利格拉茨技術大學等機構的研究人員正式披露了三個處理器高危漏洞，分別編號為 CVE-2017-5753（Variant 1）、CVE-2017-5715（Variant 2）和 CVE-2017-5754（Variant 3），前兩個漏洞被稱為 Spectre，後一個漏洞被稱為 Meltdown，Spectre Variant 1 影響 AMD，英特爾和 ARM 處理器，而所有三個漏洞都影響英特爾處理器，研究人員已經開發出了概念驗證的漏洞利用。AMD 和 ARM 已經發表聲明稱漏洞可以通過軟體修正，對性能影響不大。而英特爾處理器的軟體修正則被認為存在顯著的性能影響。

目前具體的實例演示是這樣的：

總結一下，最後是AMD和ARM都受到Spectre V1影響，就是上邊說的全CPU受影響的漏洞，這個漏洞不是硬體級的所以可以比較容易處理，最終AMD和ARM可以通過系統更新來填補漏洞而且不會對性能有重大影響。而Intel目前受到所有三個漏洞影響，最終如何解決不明。

來源：

處理器漏洞 Meltdown 和 Spectrewww.solidot.org

再次更新：Google Project Zero 今天發布這篇文章，基本可以確定文章描述的就是這次引發討論的漏洞。文章中描述了 Spectre 和 Meltdown 兩種攻擊方式，都是利用之前被懷疑的「預測執行」機制實現的，且這兩種方法需要用不同的方式來分別防禦。

我現在只讀了 Meltdown 那篇文章，梗概大概是這樣的：

Meltdown 技術可以讀取 Linux、Mac OS 的整個物理內存和 Windows 的大部分物理內存。Linux 內核 2.6.32 ~ 4.13.0 的版本以及最新的 Windows 10 均受到影響。
可以讀取其他進程的物理內存。即使在使用內核共享技術（例如 Docker, LXC）或者用 Xen 晶元的 paravirtualization 功能製作的沙箱中，也可以讀取內核或 hypervisor 內存。
影響了大部分從 2010 年開始生產的 Intel 晶元。在 ARM 和 AMD 晶元上的實驗沒有成功。
漏洞根本原因是「預測執行」技術的設計缺陷。
實驗中破譯數據的速度可達 503 KB/s，錯誤率低至萬分之二。實驗中已經可以讀取 Firefox 56 的內存，並從中找到網頁請求的頭數據和瀏覽器儲存的密碼。
KAISER 技術可以阻止 Meltdown。目前 Windows Build 17035, Linux Kernel 4.15, OS X 10.13.2 和 iOS 均添加了 KAISER 技術或其變種。

Meltdown 的過程大概是：

構造一段代碼，使得一句需要訪問受保護內存的指令本來永遠無法達到，但是可能因為「預測執行」而提前執行。
那句提前執行的代碼會根據受保護的數據內容不同而訪問內存中的不同位置（例如如果 data 是想破譯的數據，那麼 prob_array[data*4096] 會根據 data 的不同而訪問不同的內存頁）。
晶元發現許可權不足，因此回滾之前的操作，將狀態恢復到那條指令執行之前的情況。然而，CPU 中的內存緩存沒有回滾。
攻擊程序檢測 prob_array 中的每個內存頁取回數據的時間。如果某內存頁的取回時間很短，說明該頁在緩存中，是之前剛剛訪問過的頁面。從這個頁面的下標就可以推斷出 data 是什麼。

以下是原答案：

更新：根據 @馮博群提供的鏈接修正了一些原文中描述比較模糊的細節。

幫大家翻譯一下文章梗概：

英特爾的晶元級設計漏洞導致 Linux 和 Windows 內核的關鍵部分必須重新設計

======= 關於修復進展 =======

開源程序員們已經修改了 Linux 的虛擬內存系統，但是代碼注釋被縮減，人們猜測是為了隱藏漏洞的詳細信息。
Windows 預計在本周四正式發布相關補丁，且補丁已經在去年十一月、十二月的 Windows Insider 版本中發布給了測試用戶。
macOS 也需要進行升級。

======= 關於修復方法 =======

晶元微碼更新不足以修復漏洞，必須修改系統或者購買新設計的 CPU。
目前 Linux 內核的解決方案是重新設計頁表（KPTI 技術，前身為 KAISER）。之前普通程序和內核程序共用頁表，靠 CPU 來阻止普通程序的越權訪問。新方案讓內核使用另外一個頁表，而普通程序的頁表中只保留一些必要的內核信息（例如調用內核的地址）。這個方案會導致每次普通程序和內核程序之間的切換（例如系統內核調用或者硬體中斷）都需要切換頁表，引起 CPU 的 TLB 緩存刷新。TLB 緩存刷新相對來說是非常耗時的，因此會降低系統的效率。
KAISER 技術對系統性能的影響一般是 5%，最高可達 30%。一些高級的晶元功能（例如 PCID）可以支持其他技術，從而減少性能影響。Linux 已經在 4.14 版本的開發過程中添加了對 PCID 的支持。
在 Linux 系統中，KPTI 只有在英特爾晶元上才會啟用，因此 AMD 晶元不受影響，且用戶可以通過手動修改開關的方式關閉 KPTI 。

======= 關於漏洞影響 =======

根據 AMD 在 Linux 內核郵件列表裡發送的郵件，AMD 晶元沒有發現這樣的漏洞。
人們推測，漏洞會導致普通程序可以獲得受保護的內核頁表信息，進而導致一些內核保護技術（例如 KASLR，即內核地址空間布局隨機化）可能被攻破。
微軟 Azure 雲服務將在 1 月 10 日進行維護並重啟，人們推測可能是為了修復這個漏洞。
Amazon Web Services 通過郵件警告客戶，本周五會有一次重要的安全更新。

======= 其他信息 =======

還是根據 AMD 的那封郵件，人們推測出現問題的根源是「預測執行」（Speculative execution）機制。這個技術讓 CPU 可以預測即將執行的代碼，從而加快運行速度。人們猜測，可能晶元在完成許可權檢查之前，就會因為這個機制而執行本來不該執行的代碼。
也有人推測這個漏洞就是去年年末傳言的虛擬機器監視器（hypervisor ）的重大 bug。
KPTI 的前身 KAISER 本來是用來預防 time-based attack 的，但是因為性能損失較高而一直沒有併入主流 Linux 版本中。
Linux 內核中阻止 KPTI 在 AMD 晶元上自動啟用的代碼是 AMD 自己提交的。

話說知乎那麼多 Insider，17035 以上版本都有針對 Spectre/Meltdown 的 patch（那組修改幾乎把整個內核翻了個底朝天），也沒見你們說電腦變卡的。大多數現代 CPU 都有 PCID，基本消除了性能影響。

（不過我相當懷疑你更新完了發現騰訊的遊戲玩不了了……）

國外好事者的跑分數據：

https://youtu.be/_qZksorJAuYyoutu.be

可以看出這個 patch 對於運算性能沒有影響，對 IO 性能有影響，但是遠沒有 30% 那麼劇烈。

另外，非 JvN 的計算模型這回能雄起了不？

「圖規約大法好，天滅 JvN，INTEL 去死，HASKELL 萬歲」

AS SSD Benchmark

ATTO Disk Benchmark

Cinebench R15

Corona 1.3 Benchmark

Excel 2016 蒙特卡洛模擬

7z 壓縮解壓

遊戲

// 回答僅供參考更新了影響範圍

首先要明確的是：

1）這個漏洞不是去年說的Intel ME的漏洞；

2）這個漏洞不是很多答主說的依靠時間推測內核載入地址的問題。（Update：Meltdown的利用方法同樣依靠計時，但可以推測出內存內容）

這是一個新爆出的漏洞，雖然看起來不是1月2號才暴露出來。因為Linux和Windows早在去年11月份左右就有動作開始修補了。

下面是科普時間：

首先我們需要知道，以前常見的虛擬內存結構是怎樣的。以32位Linux為例，我們知道2^32 Bytes = 4GB，從應用程序的眼中來看，我擁有4個G的內存。但是，這4個G的內存並不完全屬於應用程序——高地址那邊的1GB大小的映射是屬於內核的。比如，假設內核有一段代碼在虛擬地址0xCCCCCCCC這個位置上，應用程序也是無法直接調用的。換句話說，雖然這些地址普通程序不能訪問，但內核程序、內核棧等確實映射在這了。

看起來一切正常。接下來，假設我們發現了一個內核漏洞，這個漏洞允許程序調用任意內核級的代碼——也就是說，應用程序通過這個漏洞可以調用內核中0xCCCCCCCC地址的程序了，進而對系統造成危害。

那麼如何減輕發現內核漏洞之後的危害呢？畢竟，有代碼的地方就會有bug。大佬們決定採用一種隨機的方法：你不是要調用0xCCCCCCCC這塊的代碼嗎？那我每次啟動的時候，把內核映射到一個隨機的地址上就好了嘛，比如這段代碼這次啟動的時候它在0xCCCC0000，下次啟動它就變成了0xCCCC8888，讓人摸不著頭腦。

這種機制就叫KASLR。它隨機化內核在虛擬空間中的地址，只有內核自己知道我在哪，別人休想知道。所以說，KASLR不是「修補」漏洞，而是提高了利用漏洞的成本——最好的情況是，雖然有人發現了漏洞，但卻難以利用。

但是，魔高一尺道高一丈。另一位大佬說，你這太弱了。我用一種方法，能探測出你究竟隨機到哪去了。這就是很多答主說的Time Based Attack。因為放代碼的地址和沒放代碼的地址，在某些操作下時間長短不一樣。

因此，這種Attack不是真正的漏洞攻擊，但他讓KASLR機制失效了。如果有人發現了可利用的內核漏洞後，就可以用這種方式繞過KASLR。

大佬還說了，雖然KASLR不好使了，但我的新方法好使啊。這個新方法就是KAISER——內核除了讓應用程序知道必要的信息外，不再在應用程序的眼中「可見」。但是代價也是有的，就是性能會有所下降。

好了，下面到了今天主角登場的時間了。這次的CPU漏洞，能夠使得應用程序訪問任意虛擬地址（更正：Meltdown可以讀取任意物理內存）——包括映射到應用程序空間中的內核內存（即新聞標題中的「Kernel Memory Leaking」，內核內存泄露）。這就相當於我們剛才說的「內核漏洞」（雖然這是CPU的bug），但是這個漏洞可不好修。所以只能阻止這個漏洞的利用條件了——用KAISER機制，讓你根本訪問不到內核中的東西，把內核從應用程序的眼中「隱藏」。雖然降低了一些性能，但也總比被搞事情強。

Ps. 根據一些文章，目前這項機制在Linux中改名為了「KPTI」，即內核頁表隔離。

更新：關於影響範圍

Meltdown

下圖是Meltdown論文中測試的CPU，全部淪陷：

那塊賽揚是Sandy Bridge架構（即酷睿i系列2代）。所以保守估計，至少從2代開始的CPU都有問題，包括志強。

論文的專題網站（ https://meltdownattack.com/ ）上指出，除了Itanium和Atom，Intel自1995年以來所有的CPU都可能受到影響。

AMD和ARM暫時不受影響。論文中給出的兩點猜測是，1）同樣的代碼在這些CPU上跑的比較慢，如果有更優化的代碼，也許能成功；2）這些CPU缺少某些特性……

AMD給出的說明是，AMD的CPU在實現上沒有缺陷。

Spectre

這個Spectre是地圖炮，Intel/AMD/ARM 均有CPU淪陷。具體包括哪些型號沒有明確指出，但根據專題網站上的信息，影響範圍很可能非常大。

國內的話，華為發了一個公告，目前還在正在調查中。

Security Notice - Statement on the Media Disclosure of a Security Vulnerability in the Intel CPU Architecture Designwww.huawei.com

我目前收集到的最新消息。

關於漏洞：

這次的漏洞一共有三個variant，在Google Project Zero發公告前，有一篇關於KAISER的論文(就是之前很多答主都引用過的作者有Daniel Gruss那篇)將其中variant 1和2命名為Spectre，3命名為Meltdown[1]。

在這其中，Spectre對所有的AMD，Intel和ARM處理器都有效。

// 但是，由於Spectre的攻擊不存在越權讀取內存的情況，所以user mode的進程無法獲得kernel mode進程的信息，只會導致進程間的內存泄漏。這個漏洞只能由各個應用和軟體自行修復，不需要OS級的補救。

【之前寫的這一段是錯的，更正如下】

Spectre的variant 1能讀取同一用戶態進程中分支預測mis掉、本應該被清理的那部分內存，不涉及越權讀取。在1的基礎上更進一步的利用這個漏洞，可以針對運行現在流通的發行版Linux內核的電腦，在i系列cpu上一次讀取4Gb的內核虛擬內存，速度約為2000位元組每秒。每次攻擊需要4秒啟動時間。在Linux開了BPF JIT後(這一項在Linux中是默認關閉的)也可以在amd的cpu上進行一樣的操作。

Spectre的variant 2 可以利用一個已經過時的Debian內核，讓一個內核虛擬內存的guest進程運行在root許可權下可以讀host內核內存。讀取速度約為1500位元組每秒，並有可優化的空間。每次攻擊在一個有64G內存的電腦上需要10-30分鐘的準備時間，這個時間理論上跟內存大小成正比[2]。

我發表一點bia言，2000位元組每秒的速度真的很慢很慢，要想搜完1個G的內存都需要接近6天。個人認為Spectre很可能沒有太大的利用價值，這也可能是現在沒有多少針對Spectre的補丁的原因。希望有大神來打臉。

現在在大規模討論的漏洞其實是Meltdown，這個漏洞會導致越權讀取內存的情況，會導致kernel mode進程的內存泄漏。Linux和Windows所植入的KPTI及類似的內存管理方法只針對Meltdown有效[3]。

目前Google Project Zero測試過的CPU包括Intel的i系列構架，AMD Zen之前的構架，以及ARM Cortex-A57的ARM64構架。其中Meltdown隻影響i系列，Spectre會影響ARM64，i和挖掘機。

關於Meltdown的修復：

Linux和Windows的詳情之前的答主都已經說過了，Linux已經發布patch後的內核，Windows 10很快就會推送打好補丁的正式版。

三大雲服務運營商AWS，Azure，GAE都會在近期停機打補丁。

macOS目前確認在上個月6號發布的macOS High Sierra 10.13.2、2017-002 Sierra和2017-005 El Capitan中就已經修復了這個漏洞[4]。這些補丁有可能也將Spectre修復了，詳情見Ref的鏈接中第一項Apache。macOS引入的功能被稱為Double Mapping，從名稱推測跟KAISER是一個類似的機制[5]。順便多說一句，爆料者說10.13.3會有驚喜。

關於修復漏洞造成的性能影響：

目前很多消息報告說對性能有5%-30%甚至是50%I/O性能的巨大影響。但是實際上影響會小很多。當OS引入類似於KAISER的內存管理後，如果CPU支持PCID那麼性能幾乎不受影響。Intel在消費級市場是從93年開始引入PCID的，從Haswell構架開始有針對PCID進行優化。PCID本身已經有20多年的歷史了，UN*X內核對PCID的支持已經很完善了（評論里的朋友消息：Linux並沒有起用PCID），而且Darwin核心很早就開始使用PCID了。所以在i3/5/7-4xxx以及之後的Mac用戶可以放心，Windows應該也已經啟用了PCID，官網上有提到新一些的硬體受影響會較小。理論上講I/O的性能也會因為有PCID不會下降50%這麼多[6]。

Ref.

[1] Google Project Zero Blog

[2] Reply from user ramrod from Phoronix

[3] Google Project Zero Blog

[4] macOS High Sierra 10.13.2, Security Update 2017-002 Sierra, and Security Update 2017-005 El Capitan

[5] The question on everyone『s mind: Does MacOS fix the Intel #KPTI issue?

[6] Alex Ionescu

大家都在回答漏洞的原理，對此我也無法完全解釋清楚，但不說一些感覺不太好，我今天上午將7700HQ做了更新補丁前後的一些測試，包括使用sisoftware 2017的內存事務性測試，.net公共虛擬機語言環境的算術和SIMD測試（廣義虛擬機下的計算測試），內存與緩存帶寬測試和在Android studio上使用虛擬設備運行安兔兔的測試，AS為3.01版，今天專門更新了一下，使用API 26 8.0的SDK，開啟HAXM，至少某種角度來說，大家可能更關心作為普通人的自己，手上的CPU會不會有明顯性能下降，還對人民群眾喜聞樂見的R15也跑了一下

目前來看，除了安兔兔有一兩項有明顯影響外（原因還不能確定是補丁影響），總體沒什麼明顯性能變化，大家大可不必擔憂自己的PC，尤其是Windows上的常見應用的性能，Linux的情況我現在還不太清楚，目前來看影響的可能是依賴於虛擬化技術且頻繁訪問頁表與內核的程序，但高計算密集程序無論是Linux還是Windows都不必太擔心，受影響主要是雲服務

晚上拿NVMe的SSD跑了一下，選3GB的大小，AS SSD的4K-64線程的寫入有明顯下降

未來可能會有更多Intel方面的信息透露，我也會做更多測試，目前Intel中國的反應也很懵逼

2018-01-05

Intel發表了一份溝通函，介紹此次被利用漏洞的攻擊為Side Channel attack，相關細節和風險大致含義如下

Speculative Execution

預測執行（Speculative execution）是大多數現代高性能處理器用來提高性能的主要技術之一。推測/預測執行背後的概念是指令在知道它們是否是必需的之前執行。如果沒有推測執行，處理器將需要等待先前的指令在執行後續指令之前被解析。通過執行指令的預測，性能可以提高通過最小化延遲和提取更大的並行性。預測執行的一個缺點是，如果發現所有的指令都不需要，結果可能會被丟棄。

最常見的預測執行形式涉及程序的控制流。處理器不需要等待所有分支指令來決定要執行哪些操作，而使用高度複雜的機制來預測控制流。通常情況下，預測是正確的，通過隱藏決定控制流的操作的延遲來提高性能，並通過有更大的分析池來提取處理器的並行性，從而實現高性能。然而，如果一個預測是錯誤的，那麼工作就是投機執行將被丟棄，處理器將被重定向到執行正確的指令路徑。

而預測操作不影響處理器的結構狀態，他們可以影響的結構狀態在於如存儲在TLBs和緩存信息。下文中描述的側通道方法利用了高速緩存的內容可能受到投機預測性性執行的影響。

側信道緩存方法

側信道方法通過觀察系統獲取信息，如測量系統的結構特性。與緩衝區溢出和其他安全漏洞不同，側通道不直接影響程序的執行，也不允許數據被修改或刪除。

緩存定時側信道涉及代理，檢測數據是否存在於處理器緩存的特定級別中，其存在可用於推斷其他信息。一種檢測數據是否存在的方法是使用計時器來測量在地址處訪問內存的延遲。如果內存訪問需要很短的時間，那麼數據必須存在於附近的緩存中。如果訪問時間較長，則數據可能不在附近的緩存中。

谷歌Project 0已經識別出三種方法，其中一個緩存定時側信道可能被用來泄露機密信息。

邊界檢查旁路（Bounds Check Bypass ）

邊界檢查旁路方法利用條件分支指令之後的推測執行。攻擊者發現或導致創建「混淆代理（confused deputy）」代碼，使得攻擊者可以通過投機操作來揭示通常不能訪問的信息

此方法使用處理器在檢查輸入是否處於邊界時發生的推測操作，例如檢查正在讀取的數組的索引是否在可接受的值內。它充分利用了內存訪問越界內存的邊界檢查解決之前做投機。在某些情況下，可以使用這些內存訪問來向攻擊者泄漏信息。

如果攻擊者能夠在更為特權的級別識別適當的「混淆代理」，攻擊者可能利用該代理來推斷該代理訪問的內存內容。

分支目標註入

分支目標註入方法利用處理器內部的間接分支預測器，用於指導哪些操作被推測執行。通過影響間接分支預測器如何操作，攻擊者可以使惡意代碼被推測性地執行，然後使用代碼對緩存的影響來推斷數據值。

對於有條件的直接分支，在代碼推測性執行上只有兩個選項（true or false）- 分支的目標或直接在分支之後的指令的直通路徑。攻擊者不能使代碼在這些位置之外被推測性地執行。間接分支可能導致更廣泛的目標的代碼的推測執行。這種方法通過使間接分支推測性地執行基於受害者可用的敏感數據創建副通道的「小工具」來工作。

干擾處理器的預測器以產生這樣的旁通信道的能力高度依賴於微架構實現，因此所使用的確切方法可能在不同的處理器系列和世代之間有所不同。例如，某些處理器實現中的間接分支預測器可能僅使用整個地址的子集來索引預測器。如果攻擊者能夠辨別使用哪個比特的子集，他們可以使用這個信息來產生由於混疊造成的干擾。同樣，在支持超線程的處理器上，一個線程的行為是否會影響另一個線程的預測是一個考慮因素。分支目標註入方法只能發生在一個接近間接的分支指令上。

惡意數據緩存載入

最後的方法是流氓數據緩存載入（ rogue data cache load）。這種方法涉及一個應用程序（用戶）攻擊者直接探測內核（主管）的內存。這樣的操作通常會導致程序錯誤（由於頁表許可權導致的頁錯誤）。然而，對於某些實現，在某些條件下可能推測性地執行這樣的操作。例如，在某些實現中，如果數據駐留在最低級數據高速緩存（L1）中，則這種推測操作將僅將數據傳遞到後續操作。這可以允許應用程序查詢有問題的數據，導致顯示管理員數據的副通道。該方法僅適用於僅由頁表指定的內存區域; 不是指定為不存在的內存

緩解措施

英特爾一直與包括其他處理器供應商和軟體開發商在內的生態系統密切合作，以確定先前描述的三種旁路方法的緩解措施。緩解策略的重點是確定可適用於目前市場上的產品以及未來產品開發的技術。所採取的緩解措施解決了有關的攻擊方法，並將其與諸如性能影響和實施複雜性等其他因素進行了平衡。啟用現有的處理器安全功能（如管理模式執行保護和執行禁用位）可能會大大增加攻擊系統的難度，並可能降低其他緩解的性能成本。有關這些安全功能的更多詳細信息，請參閱英特爾安全功能相關部分

英特爾一直在與操作系統供應商，虛擬機監控供應商和其他軟體開發商合作，以緩解這些攻擊。

作為我們正常開發過程的一部分，英特爾可能會在即將到來的處理器中提高這些緩解的性能和功效。

邊界檢查旁路的緩解

對於邊界檢查旁路方法，英特爾的緩解策略側重於軟體修改。

英特爾建議的軟體緩解措施是在適當的地方插入屏障來阻止投機。特別是，為此，建議使用LFENCE指令。序列化指令以及LFENCE指令將會停止較舊的指令，即使在舊指令退出之前，也可以推測性地執行，但是LFENCE是比其他序列化指令更好的性能解決方案。在邊界檢查之後插入的LFENCE指令將會阻止在邊界檢查退休之前執行早期的操作。請注意，LFENCE的插入必須明智地進行;如果使用過於寬鬆，性能可能會大打折扣。

可以創建一組靜態分析規則，以幫助查找可能需要猜測屏障的軟體位置。例如，英特爾對Linux內核的分析只發現了一些需要LFENCE插入的地方，導致性能影響最小。與所有的靜態分析工具一樣，結果可能有誤報，建議進行人工檢查。

分支目標註入緩解

對於分支目標註入方法，已經開發了兩種緩解技術。這允許軟體生態系統選擇適合其安全性，性能和兼容性目標的方法。

第一種技術在處理器和系統軟體之間引入了新的介面。該介面提供了一些機制，允許系統軟體防止攻擊者控制受害者的間接分支預測，例如在適當的時間刷新間接分支預測器以減輕這種攻擊。英特爾?64和IA-32架構軟體開發人員手冊的未來版本將提供此介面的詳細信息。這種緩解策略要求更新系統軟體以及微代碼更新，以支持許多現有處理器，未來的英特爾處理器也將支持這個新的介面

現在有三種新的功能可以支持這種緩解策略。如果適用的微代碼更新以及未來的產品，這些功能將在現代現有產品上可用，這些產品的性能成本將得到改善。具體來說，這些功能是：

1，間接分支限制投機（IBRS）：限制間接分支的投機。

2，單線程間接分支預測器（STIBP）：防止由兄弟超線程式控制制間接分支預測。

3，間接分支預測器屏障（IBPB）：確保較早代碼的行為不控制後來的間接分支預測。

第二種技術引入了「返回蹦床」（return trampoline）的概念，也被稱為「retpoline」。本質上，軟體用一個代碼序列代替間接跳轉和調用指令，包括將所討論的分支的目標推送到堆棧上，然後執行返回（RET）指令以跳轉到該位置，因為通常可以使用返回指令來保護這個方法。對於許多當前的英特爾處理器，這種技術可能比第一種技術對某些工作負載的性能要好。

英特爾已經與各種開放源碼編譯器合作，以確保對return trampoline的支持，並與操作系統供應商確保支持這些技術。對於Broadwell一代的英特爾?酷睿?處理器以及之後的版本，此次減排策略還需要應用微碼更新，以使緩解完全有效。

惡意數據緩存負載緩解

對於惡意數據緩存載入方法，操作系統軟體可以確保在執行用戶代碼時特權頁面不被映射，以防止用戶模式訪問特權頁面。操作系統可為每個用戶進程建立兩個分頁結構（CR3值）「用戶」分頁結構應映射所有應用程序頁面，但只有正常處理器操作所需的監督頁面的最小子集以及用於管理員模式。「Supervisor」分頁結構應映射所有內核頁面。它也可能希望映射應用程序頁面，以方便訪問。

這種基本的雙頁表方法以前被提出作為KASLR在 Dead: Long Live KASLR文件中被稱為KAISER的內核地址空間布局隨機化（KASLR）的旁道攻擊的緩解。這種方法也可以減輕惡意數據緩存負載。英特爾與各種操作系統供應商合作，在其操作系統中啟用了雙頁表方法。

實施這種雙頁面緩解的OS可能希望採取實現這種雙頁表緩解的OS可能希望在支持它的處理器上利用進程上下文標識符（PCID）功能。 PCID可以大大降低在用戶/管理員模式轉換期間由於頻繁重新載入CR3導致的TLB刷新的性能成本。未來的英特爾處理器也將有減輕惡意數據緩存負載的硬體支持。

結論

與平台受到這些新威脅潛在影響的其他公司一道，英特爾與軟體供應商，設備製造商和其他生態系統合作夥伴合作，共同開發可保護系統免受這些方法攻擊的軟體和固件更新。最終用戶和系統管理員應該檢查他們的軟體供應商和系統製造商，並儘快應用任何可用的更新。

對於使用這些方法危害安全的惡意軟體，它必須在系統上本地運行。英特爾強烈建議遵循一般的防惡意軟體的良好安全措施。這樣做也將有助於防止這些分析方法的可能利用。

威脅環境不斷演變。英特爾致力於投資於我們產品的安全性和可靠性，並與安全研究人員和業內其他人士進行建設性的合作，以幫助保護用戶的敏感信息。請參閱英特爾安全中心2了解更多詳情。英特爾正在繼續研究體系結構和/或微體系結構的變化，以抵禦這些類型的攻擊，同時保持高處理器性能。

簡單來說，這次利用漏洞攻擊叫側信道攻擊（網上有類似的講解），而實施攻擊的漏洞存在於分支目標註入，Bounds Check Bypass ，惡意數據載入rogue data cache load，而後者迫使處理器使用了雙頁表策略保護安全，而PCID將能緩解這些用戶/高許可權模式轉換期間的開銷，抵銷性能損失

牙膏擠了原來真的還能吸回去。

這裡簡單翻譯下Meltdown and Spectre 這個地址最後的QA，這裡有很多大家可能會關心的解釋說明。

強烈推薦看原文，個人英文一般，只是能簡單看懂，這裡的翻譯是用GoogleTranslation+人工校對，翻譯的結果，可能會有翻譯錯誤或者翻譯不準確，再次推薦看原文。

註：Meltdown直譯為熔化，熔毀，Spectre直譯為幽靈

Who reported Meltdown?

誰報告了Meltdown？

Meltdown was independently discovered and reported by three teams:

Meltdown被三個團隊獨立發現並報告：

Jann Horn (Google Project Zero),
Werner Haas, Thomas Prescher (Cyberus Technology),
Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology)

Who reported Spectre?

誰報告了Spectre？

Spectre was independently discovered and reported by two people:

Spectre被兩個人獨立發現並報告：

Jann Horn (Google Project Zero) and
Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61)

Am I affected by the bug?

我受到這個錯誤的影響嗎？

Most certainly, yes.

當然，是的。

Can I detect if someone has exploited Meltdown or Spectre against me?

我是否可以檢測到有人利用Meltdown或Spectre攻擊我？

Probably not. The exploitation does not leave any traces in traditional log files.

可能不會。傳統日誌文件中不會留下任何痕迹。

Can my antivirus detect or block this attack?

我的防病毒軟體能檢測或阻止這種攻擊嗎？

While possible in theory, this is unlikely in practice. Unlike usual malware, Meltdown and Spectre are hard to distinguish from regular benign applications. However, your antivirus may detect malware which uses the attacks by comparing binaries after they become known.

雖然理論上可行，但在實踐中這是不太可能的。與通常的惡意軟體不同，Meltdown和Spectre很難與常規良性應用程序區分開來。但是，你的防病毒軟體可能會通過比較二進位文件後發現的惡意軟體來檢測這些惡意軟體。

What can be leaked?

什麼可能被泄露？

If your system is affected, our proof-of-concept exploit can read the memory content of your computer. This may include passwords and sensitive data stored on the system.

如果您的系統受到影響，我們的proof-of-concept可以讀取您的計算機的內存內容。這可能包括存儲在系統上的密碼和敏感數據。

Has Meltdown or Spectre been abused in the wild?

Meltdown或Spectre在野外（翻譯標註：in the wild作者打錯了？不懂，猜測可能是world)已經被濫用了嗎？

We don"t know.

我們不知道。

Is there a workaround/fix?

有沒有解決方法/修復？

There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre ( LLVM patch).

有針對Linux（KPTI（以前稱為KAISER）），Windows和OS X的Meltdown補丁。還有一些工作是為了防止未來利用Spectre，會分別通過開發Spectre（LLVM補丁）補丁讓攻擊變得非常困難。

Which systems are affected by Meltdown?

哪些系統受到Meltdown影響？

Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

台式計算機，筆記本電腦和雲計算機可能會受到崩潰的影響。從技術上講，自1995年以來，每個英特爾的無序執行的處理器都可能受到影響（2013年之前除英特爾安騰和英特爾凌動外）。我們成功測試了2011年發布的英特爾處理器上的Meltdown。目前，我們只驗證英特爾處理器上的Meltdown。目前還不清楚ARM和AMD處理器是否也受到Meltdown的影響。

Which systems are affected by Spectre?

哪些系統受到Spectre的影響？

Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

幾乎每個系統都受到Spectre的影響：台式機，筆記本電腦，雲伺服器以及智能手機。更具體地說，所有能夠在飛行(翻譯標註：flight？飛行？飛速運轉？高速運行？)中保持多指令的現代處理器都有可能受到攻擊。特別是，我們在Intel，AMD和ARM處理器上驗證了Spectre。

Which cloud providers are affected by Meltdown?

哪些雲提供商受到Meltdown的影響？

Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.

使用Intel CPU和Xen PV作為虛擬化技術，並且沒有應用修補程序的雲提供商。此外，沒有真正硬體虛擬化的，依賴於共享一個內核的容器，如Docker，LXC或OpenVZ雲提供商。

What is the difference between Meltdown and Spectre?

Meltdown和Spectre有什麼區別？

Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory. Consequently, applications can access system memory. Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location. For a more technical discussion we refer to the papers ( Meltdown and Spectre)

Meltdown破壞了應用程序無法訪問任意系統內存的機制。因此，應用程序可以訪問系統內存。 Spectre會欺騙其他應用程序訪問其內存中的任意位置。兩種攻擊都使用side channels從訪問的內存位置獲取信息。對於更多的技術討論，參考我們的論文（Meltdown和Spectre）

Why is it called Meltdown?

為什麼叫做Meltdown（熔化，熔毀）？

The bug basically melts security boundaries which are normally enforced by the hardware.

該錯誤基本上融化了通常由硬體強制執行的安全邊界。

Why is it called Spectre?

為什麼叫做Spectre（幽靈）？

The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.

這個名字是基於根本原因，推測性的執行。因為修理起來不容易，所以會困擾我們很長一段時間。

Is there more technical information about Meltdown and Spectre?

有更多關於Meltdown和Spectre的技術信息嗎？

Yes, there is an academic paper and a blog post about Meltdown, and an academic paper about Spectre. Furthermore, there is a Google Project Zero blog entry about both attacks.

是的，有一篇關於「Meltdown」的學術論文和博客文章，還有一篇關於「Spectre」的學術論文。此外，還有一個關於這兩種攻擊的Google Project Zero博客條目。

What are CVE-2017-5753 and CVE-2017-5715?

什麼是CVE-2017-5753和CVE-2017-5715？

CVE-2017-5753 and CVE-2017-5715 are the official references to Spectre. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.

CVE-2017-5753和CVE-2017-5715是Specter的官方參考。 CVE是由MITRE維護的信息安全漏洞名稱標準。

What is the CVE-2017-5754?

什麼是CVE-2017-5754？

CVE-2017-5754 is the official reference to Meltdown. CVE is the Standard for Information Security Vulnerability Names maintained by MITRE.

CVE-2017-5754是Meltdown的官方參考。 CVE是由MITRE維護的信息安全漏洞名稱標準。

Can I see Meltdown in action?

我可以看到Meltdown？

（翻譯標註：這裡有兩個演示視頻）

Can I use the logo?

我可以使用logo嗎？

Both the Meltdown and Spectre logo are free to use, rights waived via CC0. Logos are designed by Natascha Eibl.

Meltdown和Spectre徽標都可以免費使用，通過CC0放棄權利。標誌由Natascha Eibl設計。

Logo Logo with text Code illustration
Meltdown PNG/SVG PNG/SVG PNG/SVG
Spectre PNG/SVG PNG/SVG PNG/SVG

Where can I find official infos/security advisories of involved/affected companies?

在哪裡可以找到涉及/受影響公司的官方信息/安全通報？

Intel Security Advisory / Newsroom
ARM Security Update
AMD Security Information
Microsoft Security Guidance / Information regarding anti-virus software / Azure Blog
Amazon Security Bulletin
Google Project Zero Blog / Need to know
Mozilla Security Blog
Red Hat Vulnerability Response
Debian Security Tracker
Ubuntu Knowledge Base
SUSE Vulnerability Response
LLVM Spectre (Variant #2) Patch
CERT Vulnerability Note
MITRE CVE-2017-5715 / CVE-2017-5753 / CVE-2017-5754
VMWare Security Advisory
Citrix Security Bulletin

----QA結束----

https://twitter.com/lavadostwitter.com

這是發現漏洞發現者之一，名叫DanielGruss的推特。裡面有他演示漏洞的截圖和視頻。他自己推特里介紹

PhD in InfoSec, PostDoc @ #TUGraz, #rowhammer, #meltdown, #spectre, cache attack

作者置頂的推：

下圖來自作者置頂推。置頂推里貼了Meltdown and Spectre 個網址有漏洞的詳細介紹，還有一些常見問題的解答。有相關paper（一個一個字母看，全看懂了，～哈哈～），關心原理的專業人士就去看作者paper吧，別被這個問題下很多看似很專業的知乎答給誤導了。

不關心原理，只想知道效果的，就是下面作者的演示圖，圖1拿到了圖2瀏覽器的內存數據。

他給的攻擊Firefox密碼的截圖裡顯示密碼是17年12月28號更新，雖然這只是密碼更新時間，但看截圖中的賬號名稱，猜測這個圖作者很可能12月28號就截好了，然後為了等廠商補丁，憋了這麼久才發推特。

裡面還有攻擊演示的視頻，攻擊效果其實就是很多人介紹的，讓當前進程能訪問到不屬於當前進程的內存數據（不懂具體漏洞信息，不是很確定這個描述是否完全準確）。就像上面圖片中那樣，Firefox密碼被作者寫的工具獲取到了。

Linux可能是動作最快的，畢竟牙膏廠是Linux內核最大貢獻者之一。Linux補丁代碼已經合併，不知道什麼時候會被合併到下游實際安裝到用戶電腦上。如果是Arch的話好像4.14.11已經打上了補丁。Windows也有補丁了。

About speculative execution vulnerabilities in ARM-based and Intel CPUssupport.apple.com

Apple說Watch沒問題，其他設備已經發布了補丁。

Apple has already released mitigations in iOS 11.2, macOS 10.13.2, and tvOS 11.2 to help defend against Meltdown. Apple Watch is not affected by Meltdown.

裡面的用詞很有意思，「to help defend against Meltdown. 」英文不好，to help defend這算是修掉了還是沒有？還請更專業的幫忙解釋。

更多Apple解釋就看上面link原文吧。

順便黑下Apple：今年Apple不用更新性能劣化補丁了，修個bug就可以了，～哈哈～。

謝邀。

首先要說的是，雖然這次漏洞影響範圍廣泛，並引起全球關注，但受影響最大的主要是雲服務廠商，對於普通用戶來說影響不大，不必過於恐慌。

言論正傳，讓我們先回顧一下這次事件的發生背景：

1月4日，國外安全研究機構公布了兩組CPU漏洞：Meltdown（熔斷），對應漏洞CVE-2017-5754；Spectre（幽靈），對應漏洞CVE-2017-5753/CVE-2017-5715。

利用Meltdown漏洞，低許可權用戶可以訪問內核的內容，獲取本地操作系統底層的信息；當用戶通過瀏覽器訪問了包含Spectre惡意利用程序的網站時，用戶的如帳號，密碼，郵箱等個人隱私信息可能會被泄漏；在雲服務場景中，利用Spectre可以突破用戶間的隔離，竊取其他用戶的數據。Meltdown漏洞影響幾乎所有的Intel CPU和部分ARM CPU，而Spectre則影響所有的Intel CPU和AMD CPU，以及主流的ARM CPU。從個人電腦、伺服器、雲計算機伺服器到移動端的智能手機，都受到這兩組硬體漏洞的影響。

這兩組漏洞來源於晶元廠商為了提高CPU性能而引入的新特性。現代CPU為了提高處理性能，會採用亂序執行(Out-of-Order Execution)和預測執行(Speculative Prediction)。亂序執行是指CPU並不是嚴格按照指令的順序串列執行，而是根據相關性對指令進行分組並行執行，最後匯總處理各組指令執行的結果。預測執行是CPU根據當前掌握的信息預測某個條件判斷的結果，然後選擇對應的分支提前執行。亂序執行和預測執行在遇到異常或發現分支預測錯誤時，CPU會丟棄之前執行的結果，將 CPU的狀態恢復到亂序執行或預測執行前的正確狀態，然後選擇對應正確的指令繼續執行。這種異常處理機制保證了程序能夠正確的執行，但是問題在於，CPU恢復狀態時並不會恢復CPU緩存的內容，而這兩組漏洞正是利用了這一設計上的缺陷進行測信道攻擊。

我們在獲悉該病毒輿情後，第一時間對其展開溯源分析，具體如下：

1、Meltdown漏洞原理

亂序執行可以簡單的分為三個階段，如下圖所示：

每個階段執行的操作如下：

獲取指令，解碼後存放到執行緩衝區Reservations Stations
亂序執行指令，結果保存在一個結果序列中
退休期Retired Circle，重新排列結果序列及安全檢查（如地址訪問的許可權檢查），提交結果到寄存器

結合Meltdown利用的代碼片段來看：

; rcx = kernel address
; rbx = probe array
1 mov al, byte [rcx]
2 shl rax, 0xc
3 mov rbx, qword [rbx + rax]

Meltdown漏洞的利用過程有4個步驟：

指令獲取解碼；
亂序執行3條指令，指令2和指令3要等指令1中的讀取內存地址的內容完成後才開始執行，指令3會將要訪問的rbx數組元素所在的頁載入到CPU Cache中；
對2的結果進行重新排列，對1-3條指令進行安全檢測，發現訪問違例，會丟棄當前執行的所有結果，恢復CPU狀態到亂序執行之前的狀態，但是並不會恢復CPU Cache的狀；
通過緩存測信道攻擊，可以知道哪一個數組元素被訪問過，也即對應的內存頁存放在CPU Cache中，從而推測出內核地址的內容。

2、Spectre漏洞原理

與Meltdown類似，Spectre的原理是，當CPU發現分支預測錯誤時會丟棄分支執行的結果，恢復CPU的狀態，但是不會恢復CPU Cache的狀態，利用這一點可以突破進程間的訪問限制（如瀏覽器沙箱）獲取其他進程的數據。

Spectre的利用代碼片段：

if (x &< array1_size) {
y = array2[array1[x] * 256];
// do something using Y that is
// observable when speculatively executed
}

具體攻擊過程可以分為三個階段：

訓練CPU的分支預測單元使其在運行利用代碼時會進行特定的預測執行；
預測執行使得CPU將要訪問的地址的內容讀取到CPU Cache中；
通過緩存測信道攻擊，可以知道哪一個數組元素被訪問過，也即對應的內存頁存放在CPU Cache中，從而推測出地址的內容。

關於漏洞驗證

目前開源社區github已經放出來了漏洞的驗證代碼（PoC），如下：

https://github.com/Eugnis/spectre-attack

https://github.com/feruxmax/meltdown

https://github.com/gkaindl/meltdown-poc

https://github.com/turbo/KPTI-PoC-Collection

經過我們的技術專家和其他安全研究人員實際驗證，漏洞可在Windows、Linux、Mac-OS等操作系統下，成功讀取任意指定內存地址的內容，如下圖所示：

Windows：

Ubuntu 16.04：

此外，有安全研究人員驗證了可以通過漏洞獲取到用戶正在輸入的密碼，不過暫未放出相關代碼。如下圖所示：

目前漏洞修復進展如何？

根據最新消息，目前針對這兩組漏洞，各家晶元廠商、操作系統廠商、瀏覽器廠商，以及雲服務廠商，都發布了安全公告，並及時推出了緩解措施和修復補丁。我們梳理了相關廠商的更新信息，具體如下：

1、晶元廠商

1.1 Intel

Intel已經確認自身CPU中存在相關問題，並正與包括AMD、ARM和多家操作系統廠商在內的許多其他科技公司緊密合作，制定行業範圍的方法，以便及時和建設性地解決這些漏洞。另外Intel認為有些媒體裡面的報道並不準確，這些問題不僅僅Intel，其他廠商的CPU中也存在相關問題。Intel已經提供軟體和固件更新以解決這些漏洞，預計下周末之前會修復最近5年中90%的CPU。

1.2 ARM

ARM確認大部分處理器不受漏洞影響，但給出了一個受影響的處理器列表。ARM認為，利用這些漏洞進行攻擊需要在本地運行惡意軟體，用戶及時更新軟體和不點擊來歷不明的鏈接會降低攻擊風險。針對linux上的程序，ARM提供了新編譯器，可用新編譯器重新編譯。另外發布了Linux ARM內核補丁，用於修補漏洞，相關頁面如下：

https://developer.arm.com/support/security-update/download-the-whitepaper

https://developer.arm.com/support/security-update

1.3 AMD

AMD針對每個漏洞做了回復，第一個漏洞由軟體、操作系統廠商發布補丁解決，性能影響非常輕微，其他兩個漏洞由於AMD CPU特殊的架構，都不受影響。具體如下：

https://www.amd.com/en/corporate/speculative-execution

2、操作系統

2.1 Windows

微軟已經發布了安全通告，修復了IE、Edge、Windows內核中相關問題，並針對普通用戶、伺服器用戶、雲用戶各自給出了防護指南。

微軟普通用戶：https://support.microsoft.com/help/4073119

伺服器用戶：https://support.microsoft.com/help/4072698

雲用戶：https://support.microsoft.com/help/4073235

微軟安全通告：https://support.microsoft.com/en-us/help/4073235/cloud-protections-speculative-execution-side-channel-vulnerabilities

2.2 Linux

Linux內核開發者Thomas Gleixner在2017年12月在Linux內核郵件列表中就新的KAISER隔離補丁發布了說明。目前有人懷疑這批補丁可能正是為了解決Linux系統當中的Metldown與Spectre

漏洞。具體如下：

https://lkml.org/lkml/2017/12/4/709

2.3 RedHat

紅帽公司已經發布一項建議，其中列出受到影響的產品及其當前狀態。建議內容表明：對於正在運行受影響版本產品的紅帽客戶，強烈建議用戶儘快根據指導清單進行更新。所有受影響產品都應安裝修復補丁，藉以緩解CVE-2017-5753 (變種1)與CVE-2017-5754

(變種3)漏洞。CVE-2017-5715 (變種2)可通過本地以及虛擬訪客邊界兩種方式被加以利用。具體如下：

https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_cid=701f2000000tsLNAAYamp;

2.4 安卓

Android團隊於2018年1月更新了安全通告：CVE-2017-5715、CVE-2017-5753以及CVE-2017-5754為已經得到公開披露的一系列與處理器內推測執行相關的漏洞。Android尚未發現任何在基於ARM的Android設備之上重現上述漏洞以進行的未授權信息泄露行為。具體如下：

https://source.android.com/security/bulletin/2018-01-01

3、瀏覽器

利用漏洞在瀏覽器中進行攻擊依賴於新特性SharedArrayBuffer和用於高精度時間計算的函數performance.now。各個瀏覽器表示都採取了以下兩個緩解措施：

移除瀏覽器中可用於攻擊的SharedArrayBuffer特性
降低用於高精度時間計算的函數performance.now的精確性

加上這兩個緩解措施後，JS版本的漏洞PoC代碼將無法觸發：

3.1 Microsoft Edge

微軟已經發布了瀏覽器補丁：

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002

3.2 FireFox

Mozilla從FireFox 57版本開始採取了這兩個緩解措施：https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

3.3 Chrome

谷歌從Chrome 64版本開始採取了這兩個緩解措施：

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

4、雲服務廠商

4.1 Amazon

Amazon方面已經發布一項安全公告，指出：此項安全漏洞廣泛存在於過去20年推出的英特爾、AMD以及ARM等各類現代處理器架構當中，影響範圍涵蓋伺服器、台式機以及移動設備。

雖然AWS所執行的更新能夠切實保護底層基礎設施，但為了充分解決此次問題，客戶還應對實例中的操作系統進行修復。目前Amazon Linux更新已經開始發布，具體如下：

https://aws.amazon.com/security/security-bulletins/AWS-2018-013/

4.2 阿里雲

為解決處理器晶元的安全問題，阿里雲將在北京時間2018年1月12日凌晨1點進行虛擬化底層的升級更新。屆時，阿里雲將採用熱升級的方式，絕大多數客戶不會受到影響。但個別客戶可能需要手動重啟，阿里雲建議客戶提前準備運營預案及數據備份。

4.3 騰訊雲

騰訊雲將於北京時間2018年1月10日凌晨01:00-05:00通過熱升級技術對硬體平台和虛擬化平台進行後端修復，期間客戶業務不會受到影響。對於極少量不支持熱升級方式的，騰訊雲另行安排時間手動重啟修復，這部分伺服器騰訊雲安全團隊將會另行進行通知，協商升級時間。

漏洞修復過程中還存在一些問題，迫使我們採取了較為保守的策略

由於漏洞是晶元底層設計上的缺陷導致的，修復起來會非常複雜，同時難以完美修復。從目前的情況來看，漏洞很難通過CPU微碼修復，更多是依賴於OS級的修復程序。

修復程序本身也存在諸多問題。以Windows 10為例，微軟於北京時間1月4號凌晨緊急發布了1月份系統安全更新，但補丁存在明顯的性能和兼容性的問題：

更新可能會讓受影響的系統性能下滑30%
更新可能會導致部分軟體（安全軟體等）不兼容從而系統藍屏

出於兼容性考慮，Windows Update並不會在所有的電腦環境中進行自動更新，而是在其認為軟體比較兼容的情況下才會進行自動更新。另外，對於有需要更新的用戶，可以通過下載微軟相關補丁包，進行手動運行修復安全威脅。

根據我們的實際測試，性能問題對於普通用戶來說，影響並不大：只有在極端的測試下，才會出現明顯的性能問題；而正常的使用過程中一般不會出現。但是兼容性問題確實比較嚴重：在有安全軟體，以及一些遊戲的電腦上，安裝補丁比較容易出現藍屏現象。這也使得我們和其他安全廠商採取了比較保守的策略，暫時不主動推送微軟的補丁，避免造成用戶電腦無法正常使用。

此次漏洞會對普通用戶產生影響嗎？

雖然漏洞影響範圍廣泛，並引起全球關注，但受影響最大的主要是雲服務廠商，對於普通用戶來說，大可不必過於恐慌。

首先，雖然漏洞細節以及PoC已經公開，但是並不能直接運用於攻擊。漏洞運用於真實攻擊還有許多細節問題需要解決，目前也沒有一個穩定通用，同時可以造成明顯嚴重後果（竊取賬號密碼等）的漏洞利用代碼；

其次，我們和其他安全廠商目前也還沒有監控到利用這些漏洞進行的真實攻擊，一旦出現真實攻擊，我們將第一時間跟進，確保用戶安全；

另外，對於普通用戶而言，漏洞可造成的主要危害在於用瀏覽器訪問了一個帶有漏洞利用代碼的網頁，導致敏感信息（賬號密碼等）泄露。只要養成良好的上網習慣，不輕易點擊陌生人發來的鏈接，基本不會受到漏洞影響；同時，瀏覽器針對漏洞發布的補丁和緩解措施簡單有效，而且不會造成性能下降或兼容性問題，用戶可以選擇將瀏覽器升級到最新版本，從而避免受到漏洞攻擊。

這些漏洞未來一段時間內仍然是各界關注的重點，我們的安全團隊將對漏洞動態保持持續關注，同時對漏洞做更加深入的分析和研究，從而為廣大用戶提供更加準確的參考信息，以及更加可靠的解決方案。

本文為騰訊安全聯合實驗室知乎機構賬號原創內容，轉載請註明出處。

想要獲取更多官方資訊請關注騰訊安全聯合實驗室微信公眾號：txaqlhsys

更多騰訊安全聯合實驗室官方精品回答：

2017年，在科技互聯網領域，最讓你難以忘懷的關鍵詞是？
2017 年，讓你好感度最高的科技產品是什麼？
2017 年你所在的行業和領域發生了哪些大事？
騰訊安全部門的幾個實驗室老大是誰？分別做哪方面研究呀？
有哪些有趣的電腦病毒？
最近「佛系」火了，除了90後，大家還發現了哪些具有佛性的事物？
個人信息的泄露在今天已經嚴重到了什麼地步？對普通人的生活有多大的影響？

修正下，分兩個漏洞

漏洞1：spectre：AMD、Intel、ARM全部中招。可以擊穿JAVA沙箱。KAISER無法拯救。

Hardware.
We have empirically verified the vulnerability
of several Intel processors to Spectre attacks, including
Ivy Bridge, Haswell and Skylake based processors.
We have also verified the attack』s applicability
to AMD Ryzen CPUs. Finally, we have also successfully
mounted Spectre attacks on several Samsung and
Qualcomm processors (which use an ARM architecture)
found in popular mobile phones.

漏洞2：meltdown：Intel中招，AMD倖免。雲廠商虛擬化被嚴重穿透，虛擬機可以獲得host內存的訪問許可權，及高達503kb/s的系統內存下載速度。對雲廠商是致命打擊。可以用KAISER拯救。

We also tried to reproduce the Meltdown bug on several
ARM and AMD CPUs. However, we did not manage
to successfully leak kernel memory with the attack described
in Section 5, neither on ARM nor on AMD. The
reasons for this can be manifold.

奉勸某些人看完論文再來評論，謝謝

We evaluated Meltdown running in containers sharing a
kernel, including Docker, LXC, and OpenVZ, and found
that the attack can be mounted without any restrictions.
Running Meltdown inside a container allows to leak information
not only from the underlying kernel, but also
from all other containers running on the same physical
host.
The commonality of most container solutions is that
every container uses the same kernel, i.e., the kernel is
shared among all containers. Thus, every container has
a valid mapping of the entire physical memory through
the direct-physical map of the shared kernel. Furthermore,
Meltdown cannot be blocked in containers, as it
uses only memory accesses. Especially with Intel TSX,
only unprivileged instructions are executed without even
trapping into the kernel.
Thus, the isolation of containers sharing a kernel can
be fully broken using Meltdown. This is especially critical
for cheaper hosting providers where users are not
separated through fully virtualized machines, but only
through containers. We verified that our attack works in
such a setup, by successfully leaking memory contents
from a container of a different user under our control.

分幾個player吧：

Intel：涉及太廣，產品沒法召回（筆記本難道整體返廠么），趕緊明白問題根源。該道歉道歉，企業級客戶該賠償賠償。按照5%-30%的性能衰減，相當於目前所有CPU退回一代。

AMD：太棒了親，我沒有這問題，歡迎來買！AMD性價比進一步提升。目測股價應該有所表現。

MicrosoftAppleOtherOS：瘋狂給Windows和MacOS和OtherOS搞補丁並推送。IT運維有的忙了。

雲廠商：重災區，本次的問題若被黑客利用後果不敢設想。24小時加班部署補丁，重啟伺服器。IAAS層的服務會出現中斷並影響PAAS層和SAAS層。對於如火如荼的雲化是一劑清醒劑。

別的：貌似也幫不上忙。。。

增加下某券商研報：

預測技術，Intel成也蕭何敗也蕭何

為了提高處理效率，當代處理器內嵌有預測技術：通過預測下一條指令，處理器可以填滿內部流水線，充分發揮運作效率。Intel的推測執行(Speculative Execution)技術是業界標杆水平，行業內所有公司都在向Intel靠攏，但是這個漏洞說明Intel的推測性執行在晶元內部的訪存執行單元Load/Store Unit和重排序緩衝區ROB上存在安全檢查漏洞，導致操作系統核心的安全保護出現問題，使得用戶程序可以窺測內核數據，包括系統訪問歷史記錄，密碼等等隱私，同時會造成KASLR（Kernel Address Space Layout Randomization，內核位址空間布局隨機化）的無效化，導致攻擊者可以推斷出內核地址，進而發動攻擊控制控制整個系統，造成嚴重的安全風險。受影響用戶包括伺服器環境、PC環境和移動環境。

在Linux的源代碼和郵件列表中顯示，一開始的補丁也囊括了AMD CPU，但是AMD公司的工程師主動進行了修正，聲明AMD的處理器不受影響並且要求取消了對AMD的補丁，目前這個補丁僅在Intel CPU上生效。

操作系統廠商紛紛發布補丁嘗試修復此漏洞，但補丁會對性能造成嚴重影響

本次漏洞無法在晶元層面得到修復，修復只能在操作系統層面進行（或重新購買CPU）。微軟預計本周四會推送補丁，且補丁已經包含在去年年底的Windows Insider版本中。蘋果的MacOS也未能倖免，需要進行相應的修補工作。

本次補丁的主要功能是通過KPTI（Kernel Page Table Isolation）完全分離系統內核與用戶內存，讓系統使用另外一個分區表，使得用戶程序無法訪問系統內核。但是，KPTI會導致CPU頻繁地從內核模式切換到用戶模式，引發耗時的TLB緩存刷新，拉低系統效能。根據初步測試，Intel CPU效能會降低5%-30%，相當於回退1~2代。舉例來說，第八代的酷睿CPU打上補丁後的效能可能低於同檔次的第七代的酷睿CPU。

Intel善後花費巨大

綜合專家看法，我們認為，研發方面，Intel修複本漏洞需要組織工程師Review幾十萬行RTL源碼來確認問題所在，而發現問題後的問題解決過程將耗費更多的人力物力：我們預計Intel至少需要花費幾個月的時間才能提出可行的解決方案，並做完初步測試，而採用新方案的晶元的性能將會是一個未知數；商務方面，Intel需要安撫各大客戶的情緒，特別是採購了大量Intel CPU的雲廠商，以防新增訂單向AMD的轉移，同時，對於已有的伺服器設備，Intel需要與廠商一起研發解決方案堵住漏洞；品牌形象方面，Intel的高端形象無疑會遭受重創，建立品牌認知將花費較長的時間。

2016年，Intel花費了127億美元用於研發。假設其中10%用於CPU研發，本次漏洞造成Intel CPU性能的回退至少給Intel帶來了12.7億美元的損失（相當於研發產生的性能提升被抹掉），而整體的善後成本在考慮修復成本、商務成本、品牌重建、市場競爭等因素後或將超過25億美元。

雲廠商面臨巨大壓力，雲服務成本或有較大提升

本次的漏洞會影響所有的雲廠商，包括但是不限於Amazon、Microsoft、Google等巨頭。雲廠商只要使用Intel CPU，就需要通過補丁進行系統加固。然而，由於雲平台應用了大量的虛擬化技術，這些補丁比針對個人電腦的補丁更為複雜，由於雲廠商的伺服器擁有極高的數據吞吐，補丁對伺服器系統效能的影響會比對PC更為嚴重。

Microsoft Azure將於1月10日進行維護和重啟，據稱跟本漏洞有關；AWS也發送了通知郵件聲稱本周五將進行重大安全更新。讓人擔心的是，已經有跡象表明有黑客在利用本漏洞攻擊雲系統。我們認為短期來看，雲廠商的服務成本或有較大提升。

給文科生強行解釋一波。可能還是有些人不懂，結合評論區，更新一下。

1：麋鹿每天都在同一家KFC點漢堡，這家KFC主營漢堡，雞翅，薯條和可樂。

2：狗仔（卓sir）想知道她吃的是什麼,於是派出狗仔A去偵察。

3：狗仔A在某一天跟在麋鹿的身後

4：麋鹿和收銀員說，點和昨天一樣的。然後拿走了包裝好的的漢堡（密碼）。

5：狗仔A對收銀員說，我點和麋鹿一樣的。（非法讀取）

6：收銀員說你這樣侵犯了麋鹿的隱私，不可以這麼點。然後狗仔A就被叉出去了（執行非常讀取時被發現，終止進程）。

7：狗仔公司換了戰術，派兩個狗仔第二天跟在麋鹿身後排隊（使用漏洞）。

8：狗仔A在麋鹿點餐的時候大聲喊，我要點和麋鹿一樣的（發送指令）。

9：廚師聽到了，多做了一個漢堡（漢堡進入緩存，CPU預測指令亂序執行）。狗仔A涉嫌侵犯麋鹿隱私被叉出去X2！（非法讀取被發現，終止進程）

10：狗仔B說，我餓死了，我要雞翅，薯條，可樂和漢堡。哪個先好先給我哪個。

11：狗仔B先拿到了漢堡（從內存中讀取此段緩存速度最快）卓sir同時也知道了麋鹿點的是漢堡。

隨著時間更新，情況變成了這樣：

現在發現了兩個嚴重的硬體級安全漏洞：融毀漏洞Meltdown，幽靈漏洞Spectre。
都是除了更換無漏洞CPU外無法治本。都會帶來信息泄露的風險。
Meltdown就是之前所說的Intel CPU bug，覆蓋面是所有支持亂序執行的Intel CPU。包括1995年起的幾乎全線產品，只有少量安騰和ATOM倖免。AMD強調自己的CPU沒有這個BUG，不過目前第三方還沒有支持這一觀點，只說待查。
Spectre影響你能看到的所有消費級CPU。包括Intel，AMD和ARM，手機也不能倖免。
Meltdown目前有了治標的辦法，就是那些會降低性能的系統補丁。AMD如果確實沒有這個BUG，那大概可以逃過一劫。
Spectre目前連治標的辦法都沒有。大家一起歡樂地裸奔……

以後會發生什麼的估計和吐槽

雖然之前吐槽好像用力過度，但個人用戶大量轉投AMD的可能性確實不大。
反倒是最大受害者：數據中心，雲服務商等組織可能會慎重考慮將一部分系統轉移到AMD甚至ARM平台上了。
雖然這次他們也中槍了，但是把雞蛋分開放，總比都堆在一個籃子里強。哪怕是最結實的籃子，最小心地看護，也不能保證永不翻車啊……
其實我有點好奇IBM POWER，龍芯之類的小眾晶元有沒有踩雷。亂序執行不是什麼新概念，也不是x86獨有的，高性能晶元一般都會有自己的實現。
很多人強調個人用戶的機器性能不受多少影響。目前來看，最受影響的是IO（準確來說是系統調用）。個人用戶的典型高負載任務如遊戲，作圖，壓片等等，瓶頸都在計算而非IO，受影響並不大。但也並不是說你就一定感覺不出來。那些上了特別高性能的PCIE介面SSD的土豪們就有可能發覺自己的硬碟性能下降了。掛機下載狂人也有可能發現自己的下載應用多佔了CPU。

和當年的心血漏洞一樣，這次的嚴重BUG獲得了專門開站介紹的待遇。大家不妨去專門的站點去看消息。

https://meltdownattack.commeltdownattack.com

======================以下舊答案========================

現在的情況看起來是這樣：

Intel的CPU有嚴重安全漏洞，會泄露信息。
除了換CPU，無法治本。
治標的辦法是更新操作系統繞過漏洞。
治標會嚴重降低性能。

所以未來大概會這樣：

個人用戶Intel根本不會理睬。
也許會有人搞集體訴訟之類的活動，吃瓜群眾各種嘲笑，最後不了了之。
大部分人什麼都不知道。
操作系統放出補丁來，影響性能
大家發現電腦慢了，以為是老機器不行了，催生出一波換機潮
大家繼續看著等燈廣告買Intel

AMD崛起？不存在的。

一開始報出這個大新聞的媒體嘲諷了一下Intel的公關文，順道cos了Trump：

We translated Intelamp;#x27;s crap attempt to spin its way out of CPU security bug PR nightmarewww.theregister.co.uk

==============================================

這個說的算是比較淺顯易懂的。

安全專家發現英特爾處理器有重大安全問題，建議立即更新系統cn.engadget.com

==============================================

Linus開噴了……

Avoid speculative indirect calls in kernellkml.org

Alan Cox的回復也很有意思。

===============================================

那些給明星洗地的粉絲需要來學習一下公關文該怎麼寫。

我就懶得打字了，直接看下面的評論吧。

發現AMD已經針對Intel混淆視聽的聲明懟回去了

補充新聞，等一個ibm

首先感謝知乎朋友的邀請，我想先用一個容易理解的比喻來說明Intel CPU最近的Meltdown Bug：

假定你希望知道你老闆最近是不是在北京，但是按照公司規定，你是無法知道老闆行蹤的。所以你決定嘗試竊取這個秘密。

於是，你給老闆的秘書打電話說「你能不能幫我查下老闆的日程，看看老闆是不是在北京出差，如果在北京的話，再幫我去公司CRM系統裡面查下，看看我名下近期需要拜訪的北京重點客戶，這些可能是需要老闆幫忙拜訪的。」

秘書很敬業，先是查了老闆的日程，發現老闆確實在北京；然後又花了幾分鐘時間從CRM系統里把近期需要拜訪的北京重點客戶名單拿出來。這時，她突然反應過來你是不應該知道老闆現在在哪裡的。於是她回電話告訴你「不好意思，我覺得你不應該了解老闆去了哪裡。」

你回復道：「那好吧，那麻煩你直接告訴我有哪些北京重點客戶是近期需要拜訪的？」

因為秘書剛剛已經從系統里查到了對應的客戶，並且你有許可權了解這些，她很快就回答你：「近期需要拜訪的北京重點客戶有A,B,C.......」

通常情況下，從系統裡面調取出這些信息需要好幾分鐘，但是秘書很快就告訴了你答案，那麼你可以推測老闆就在北京。所以，秘密就這樣泄露了。

CPU執行的過程，有一個很重要的加速優化技術叫做「speculative execution", 其實就和以上比喻中秘書的工作方式一樣，她只有在告訴你結果的時候，才發現你不應該了解這個信息。但是此時，通過下一步執行結果的速度變化，仍然有可能暴露重要的信息，這就是所謂的"time based side channel attack（基於時間的旁路攻擊）」。

Intel的CPU在伺服器市場可能佔據了99%的份額，一旦它出了問題，就意味著有很多伺服器上的敏感數據都可能泄露。因此這是一次非常嚴重的安全事故，有可能比Heartbleed更嚴重。

我軟官方回應，打補丁吧：

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002portal.msrc.microsoft.com

Azure已經上補丁了：

Securing Azure customers from CPU vulnerabilityazure.microsoft.com

從原理和起因角度，大家已經分析的差不多了，不少人最關心的，應該是這次漏洞到底對我們這些普通用戶有什麼影響。

首先說結論，我目前沒看出什麼性能損失（遊戲，建模（3dmax，cad），Adobe全家桶，安卓模擬器，SATA，pcie性能都正常）。估計90%以上的人是不會受影響的，如果你需要工作都在上面幾項之內，你可以放心的更新補丁，不會損失掉任何性能。

首先看看遊戲性能，這是基於linux的測試，所以遊戲數量有限...但是影響不大，不光的圖上的兩款。Dota2，地鐵這些遊戲影響也很小。

那麼渲染呢？

x264沒問題

adobe全家桶問題都不大。

office軟體..

文件解壓...

Windows下的刺客信條起源...

ssd性能，差距理解為誤差都毫無問題，有的項目在打了補丁之後分數甚至提高了，只能說明這個補丁對該項測試性能的影響是不存在的。

要虛擬機的用戶應該會受到較大的影響。

但是如果只是遊戲，辦公，視頻剪輯，建模這些簡單工作，影響還是不大的。

今天更新了kb4056892這個補丁。然後跑了一下內存和緩存性能。

這是更新前

這是更新後

更新後還變快了一點點....大概是誤差吧...io性能表現最突出就是內存和緩存性能了，這都沒有影響，日常使用看來是毫無影響了，特定程序性能也許會嚴重下降吧...

這次漏洞的最大受害者是數據中心，咱們倒不算啥受害者，然而數據中心是Intel大單生意的主要來源，這次損失可慘重了。

剛讀了一下Meltdown的論文。問題的起源是現代處理器的亂序執行。現代的操作系統都會把虛地址的高位部分直接映射到物理地址上面去，然後通過設置許可權不讓程序訪問來保護這些隱私數據，然而亂序執行的特性讓程序讀取這些非法數據變得可能。在亂序處理器會在某個指令在等待的時候，預先開始執行之後的指令，然後通過speculation的機制來保證如果預先執行了不該執行的指令，不會產生體系結構層面可見的結果。speculation簡單來講就是把預先執行的指令的結果存到暫存區（體系結構層面不可見），然後按照順序一條一條commit。異常的處理是在commit過程中完成的。於是當應用程序訪問非法內存的時候，程序並不是馬上出異常，而是要等訪存指令commit，這中間的時間差足夠CPU預先執行若干指令了（文中管這部分指令叫做transient instructions）。Speculation雖然能夠保證不出現體系結構層面可見的更改，但是可以影響緩存的內容。信息的接收者開闢一段內存（probe array），並且保證這段內存都沒被緩存過。信息的發送者是transient instructions，這些指令無法產生體系結構層面可見的更改，只能改變probe array中的元素是否在緩存中，進而改變接收者訪問probe array不同元素的訪存時間，這樣的話接收者就可以通過測量訪問probe array不同的時間來判斷緩存情況，從而達成接受transient instructions的信息的目的。

利用漏洞讀取非法內存的方法如下圖，接收者開闢一段2^8=256個page大小的內存(256*4096)作為probe array，並保證這部分內存未被緩存。假設要訪問的非法內存的地址存在rcx, 通過mov指令讀取位於rcx地址的內存中的一個位元組，存在rax中，這條指令將來會產生異常，然而在異常產生前，就可以通過transient instructions把讀取的內容發送出去：假設讀取的值是i，那麼就在transient instructions裡面訪問probe array的第i*4096個元素，這會導致第i*4096個元素被緩存。接收者通過測量所有的256個page的內存的訪問時間，就可以知道i的值了。

================

Spectre的論文我也看了一下，感覺跟Meltdown有著異曲同工之妙，都是利用speculation的設計缺陷通過緩存的訪問時間來實現發送信息的問題。不同的地方在用，Spectre利用的是分支預測失敗來實現內存越界訪問。很多腳本語言，不管解釋器，還是JIT編譯器，都是通過數組訪問越界檢查來阻止用戶程序訪問不該訪問到的內存的（比如說Chrome裡面運行的JavaScript是不應該訪問到Chrome存儲的用戶名密碼的），腳本語言裡面的x = a[i]，具體實現起來，等價於類似這樣的code：

if (i &< a.length) x = a[i]

通過提前訓練branch predictor，可以讓處理器的分分支預測失敗，x = a[i]這條越界訪存的指令被speculative execution，進而可以通過跟Meltdown相同的方法把越界訪存的結果通過緩存訪問時間發送出去，達到越界讀取內存的目的

最近業界爆出了Intel處理器猜測執行導致的漏洞。其實這個漏洞並非能夠被輕易利用的那種，只是降低了黑客們侵入的門檻。

本文組織：

內核相關基本知識回顧
如何繞過ASLR機制
如何從用戶態直接dump內核代碼

按照原生態思維，OS內核數據和代碼區應該與用戶區完全隔離，用戶程序看到和訪問的所有地址應該都是用戶態地址，但是當用戶程序執行系統調用時，進程會切入到內核態訪問內核代碼和數據，此時頁表也需要從用戶態頁表切到內核態頁表，這樣性能比較差，因為頁表在RAM中，縱使有TLB緩存，頁表切換時之前TLB緩存的內容也會失效，要重新預熱。於是目前主流OS都是將內核代碼和數據區放置到每個用戶進程虛擬地址空間中的高位區，32bit系統放到3~4G，windows則默認佔用2~4G區，可以改為3~4G。64bit系統也放在高位。每個進程空間的內核區都被映射到同樣的物理內存區中，這樣，進程的切換並不會導致TLB中之前緩存的那些針對內核區的頁表條目作廢，保證了性能。

進程無法訪問內核區，因為強行訪問的話，頁表條目中會有許可權位，進程當前的許可權被保存在CS寄存器的CPL欄位中，為Ring3，而內核頁表項的許可權為Ring0，CPU會禁止訪問並報缺頁異常。

假設，OS內核爆出了某個漏洞，如果黑客向某個地址掛接或者注入代碼則將取得Ring0許可權。即便OS修復了該漏洞，但是有眾多用戶不希望打補丁，或者各種原因吧，繼續裸跑，那麼就有可能中招。為了「一勞永逸」的解決這個問題，或者說提高黑客們的侵入門檻，OS提供了一種機制，每次啟動時，內核的代碼和數據會被隨機的放置在內核區，每次啟動都有不同的布局，這樣，即便某個漏洞被發現存在於某某地址，但是其他機器上的可不一定也是這個地址，這樣，侵入程序就失去了通用性。該技術被稱為ASLR（Address Space Layout Randomization）。

道高一尺魔高一丈。黑客們自有辦法旁敲側擊。比如一個不透明的箱子（內核區），你想知道箱子左下角放的是什麼數據，有沒有數據，怎麼辦？敲一下聽聽聲音，晃晃試試輕重。是的，黑客們也這麼干。比如，先執行一個系統調用，sys_fork( )創建新任務，此時，CPU的TLB、L1/2/3 Cache中可能會充滿與fork有關的代碼和數據，調用返回後，這些內容並不會立即就被清掉，而是繼續待在TLB和Cache中。然後，該程序嘗試訪問內核區某地址，當然這個訪問會被禁止並報缺頁異常。但是在被禁止之前，CPU其實是將對應地址的頁表條目載入TLB，然後檢查其許可權發現不通過，然後才報異常。

如果程序接連發出多次訪存請求訪問內核區，由於目前處理器內部普遍採用提前執行的深流水線，所有這些指令都會被提前執行，提前將頁表條目載入TLB，然後檢查許可權，不匹配則會在指令執行結果提交時報異常。但是其執行痕迹卻留在了緩存中。如果程序嘗試訪問的內核區恰恰就是剛才所執行的系統調用相關的內容，那麼緩存命中，對應條目並不會被清掉，此時程序可以嘗試再次發送同樣系統調用，此時會發現這個調用返回的比之前更快，這就說明了，該內核區域存放的可能就是sys_fork相關的代碼和數據。如果再通過進一步的不斷嘗試，旁敲側擊，就可以精確判斷出哪塊內核代碼、數據在內核虛擬區的哪裡，這樣，ASLR的效果就被繞過了，也就形成了漏洞。程序可以把整個內核區域都測試一遍，然後不斷的分析，得出最終結論。

Intel本次爆出的漏洞，是提前執行漏洞。其與上述過程的區別在於，Intel在提前執行時，不禁將頁表載入了TLB，而且連對應地址上的數據都被載入了緩存，這雖然不違反用戶態永遠無法直接訪問內核態的原則，因為數據最終必須被載入寄存器才會被判定為「訪問」，程序無法直接訪問緩存，但是敏感數據已經進入了緩存，這說明Intel提前執行的力度太高。那麼，這又有什麼問題呢？

如果不提前執行，該越權訪存指令並不會導致真的去訪存，從而數據也就不會進入緩存，因為看到tlb許可權不匹配就不會再去訪存了，而Intel的提前執行被設計的太過激進，執行時甚至都不去檢查許可權，因為檢查的話會增加開銷，到最後檢查也來得及，所以直接就去訪存了，因為訪存這一步比較慢，提前訪存可以屏蔽訪存的時延。所以，如果不提前執行，緩存中並不會有該內核地址的數據被存入，那又有什麼可推斷出來的結論？

如果由於提前執行而導致了有數據被存入，那麼之前程序的猜測會更加精準。比如用戶程序先發起一系列越權訪問，導致內核某塊數據載入cache，然後程序通過改變一系列調用方式重新向內核發起調用，根據調用返回時間判斷本次調用是否命中了cache中的這塊數據，命中了則返回更快。那麼用戶改變了這個參數會導致內核載入哪塊數據，這個是可以通過閱讀內核源碼來分析出來的（Linux躺槍），在根據之前越權訪問的是哪個地址？那麼就可以更精準的才出來，哪塊地址上存儲的是哪塊內核數據/代碼。

所以說，Intel過於激進的提前執行，連訪存都真的發生了，進入緩存了，從而讓黑客有更大的可乘之機，這就是這個漏洞的技術本質。

解決辦法：改硬體，提前執行不訪存（性能太差），或者提前執行時就檢查許可權，要麼就是提交時發現要回退則清除執行痕迹（Ivalid對應緩存行）。要麼，該軟體，OS切換為KPTI（KernelPage Table Isolation）模式，也就是重新回到原生態思維下的內核與用戶態完全隔離，這樣，用戶態程序訪問的任何地址都是用戶地址，訪問不了內核區（準確的說應該留一小點內核區在用戶區，因為用戶態執行了系統調用之後，由於目前的x86處理器並不是自己切換CR3，而是通過指令切換，那麼這個指令必須位於當前地址空間中，該指令執行之後，即徹底切換到了內核空間）。

冬瓜哥也給出一個處理方式：是不是可以在cpu內加一個寄存器用來記錄內核虛擬地址邊界，凡是嘗試訪問的，一開始就給禁掉，而不是去讀頁表，進tlb，檢測許可權。比如拿32bit OS來說，內核區位於3~4G，那麼內核初始化時將3G這個邊界寫入該寄存器，這樣，Ring3代碼凡是訪問超過3G的地址，在流水線早期就給禁掉，代價非常低，新設置一個比較器，將該寄存器與指令寄存器中地址欄位連接到該比較器，將比較器輸出信號輸出給流水線總控模塊決定是否暫停預先執行。

那麼，用戶態到底是怎麼直接拿到內核態數據的呢？在這個方法簡直巧妙的令人難以置信。請看下面代碼，摘自谷歌博客。其基本思想是，先越界訪問，用一個越界的變數去定址內核態數據，將讀出的數據當做一個索引，與1按位與之後去定址一個用戶態的數組。讓CPU的猜測執行將該數組的數據載入cache，然後考察讀取兩個不同數組元素，第（value1）==0項以及（value1）==1項，例子中就是0x200和0x300處的值，看看這兩個誰返回的快，就證明value的第1個bit是1還是0，value就是內核數據。這樣不斷的per bit的嘗試，最終dump出全部內核數據，內核裸奔~~淚嘩嘩的流！

如視頻所示，hack了用於存放密碼字元的地址，隨著密碼的輸入，直接dump出來顯示給你看，細思恐極啊。

更多細節邀請關注鄙人公眾號：「大話存儲」

一月四日更新：

Google Zero團隊發布了文章，其中的第三個bug (meltdown) 就是所說的bug
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
AMD的官方申明：An Update on AMD Processor Security （見表格的第三行，AMD不受改bug影響）

BUG大概是這個樣子的（詳情見Google Zero Blog）：

Mov rax, [somekerneladdress]
And rax, 1
Mov rbx,[rax+Someusermodeaddress]

這樣三條指令，理論上第一條load kernel address會interrupt

但是CPU會預測執行，在最後把不應該執行的結果discard掉；也就是說第三條指令的地址可能會被load，但是不會進入rbx，因為CPU後來發現第一條指令就interrupt了

但是，第三條執行的時候這個地址進入cache了，後續可以用時間來判斷cache里有哪些地址

所以就得到了kernel address的數據

---

上午在HN看到了相關討論，自己搜了點相關信息，補充一下（不完全確定（可能現階段只有Intel/Microsoft/Google/Apple等大廠才有人清楚情況））：

Fact: Kernel page-table isolation (KPTI, 之前叫KAISER) （wiki）在 kernel 4.15 被merge了

KPTI是KASLR的進階版本（內核內存地址隨機化），KASLR使得內核數據結構所在地址每次啟動隨機，目的是基本防禦通過類似overflow的方式改寫內存的攻擊；後來提出了一些通過side-channel（比如看執行時間來判斷內存是否在cache里）繞過KASLR的攻擊，於是提出了KPTI
KPTI是給每個進程兩張memory map，一塊只有user space memory，一塊包含kernel space memory，在進入內核態後使用後者，來進一步防止這種攻擊；但是顯然會帶來很大的開銷，每次syscall都會flush TLB，改CR3，這就是其他回答提到的性能下降5%-30%，但是對於沒什麼syscall的程序（比如純計算）顯然沒什麼影響

KPTI理應是一個「並沒有什麼用」的patch：它對kernel做的是防護其他漏洞出現之後增加kernel被攻擊的難度，並且開銷很大，理應要很久之後才merge或者根本不進入mainline。但是，這個patch在出現三個月就被merge了。
所以，大家就猜測（現在基本證實了，不過細節還是不清楚），一定是發生了一些不好的事情，比如CPU出現嚴重的安全性Bug了，必須要通過這個方式繞過（所以雖然KPTI很早就開始寫了，但是可能最近才發現有bug使得必須要上這個patch），並且這個猜測有很多依據：

kernel的cpu features里加了一個flag叫做X86_BUG_CPU_INSECURE
代碼注釋被刪掉了
微軟也在著急干一樣的事情
(AMD說他家的CPU不受影響…Do not enable PTI on AMD processors) （話說這個patch也是迷… if (vector != AMD) set_unsecure() ... ）

(非第一手資料) 據說郵件列表裡Google和Amazon的人尤其活躍，所以猜測主要會影響虛擬機的安全性

暫時沒有什麼其他消息，估計要等一段時間直到幾大操作系統都更新後在披露細節吧，無論如何應該會是一件非常值得期待的有趣的事情…

2018年1月4日補充：

看來AMD也難逃一劫？附微軟公告截圖。

原答案：

前天給老家父母訂的G4560+B150+4G還在路上，原本準備年後收個二手七代U換上，這下可好，直接退了上銳龍？