(2018/01/06 更新 v2) Intel 爆發史上影響範圍最廣的處理器安全漏洞事件，解決方案可能造成性能下降

(2018/01/06 更新)
蘋果已針對此次事件旗下產品之受影響情形發出聲明故本文內容已進行修正、Intel 已經發佈本次問題的安全性通報 (INTEL-SA-00088)，以下內文依據 Intel 公告之受影響產品清單修正。

---

(2018/01/04 更新)
在各國網路輿論延燒之後，各大廠商與當初發現此問題的 Google Project Zero 等單位已經陸續發表關於此次發現漏洞的初步資訊與修正程式並各自發出新聞稿聲明，根據 Google Project Zero 發佈的說明，本次同時間發現的漏洞實際上有三個，分別是 CVE-2017-5753 (跳過邊界檢查)、CVE-2017-5715 (分支目標注入)、CVE-2017-5754 (惡意資料快取存取) 三種，其中前兩個被命名為 Spectre，第三個則是被命名為 Meltdown，因此本文內容將根據逐步揭露的消息陸續進行更新與修正。

這兩類漏洞都是與記憶體隔離有關，其中 Meltdown 由於牽涉到核心記憶體隔離的機制可能被繞過，因此對於安全性的影響較為直接且嚴重，但可透過核心記憶體隔離 KPTI 緩解，因此現階段各家作業系統的修正主要是針對 Meltdown 的部分，此項主要受影響的為歷代 Intel CPU 與極少數 ARM CPU，至於 AMD 部分只要 Linux Kernel 沒特別打開 BPF JIT 就不會受影響。

至於 Spectre 則是影響應用程式間的記憶體隔離，使得攻擊者有可能藉此攻擊正常運作的程式並從中竊取私密資料，不過在攻擊實作上較為困難，原理較為複雜同時也較難根治，接下來估計會以對已被發現的惡意程式進行針對性防護為主，此項則是幾乎所有近代 CPU 都受到影響了，這也就是 Intel 新聞稿聲稱各家都有類似問題的原因。

Linux 之父 Linus Torvalds 在郵件列表當中寫到他認為 Intel 應該認真看看他們的 CPU，並且承認問題而不是透過公關話術來說服大家「一切都如同設計般正常運作」，而這些緩解措施與修補在設計時應該記得「並非所有 CPU 都是一坨屎」，也許 Intel 只是表明「我們堅持在可預見的未來裡賣垃圾給你，而且永遠不會修好任何問題」，若是那樣，或許我們該認真考慮與 ARM64 陣營走得更近。

本文原先所提及的內容與這兩天網路討論、新聞都是以 Meltdown 此問題為主。

---

雖然站長最近不太有時間可以更新網站的內容，但是在 2018 年的一開始就爆發這麼大的事件，實在是不得不動筆一下了呢，這次事件在前天開始被外國媒體報導之後引發大量的相關文章出現，在這兩天也傳回國內在 PTT、Facebook 等地引起討論，稍早也已經登上各大新聞版面，根據目前已知的說法，當前所發現的問題是發生在 Intel x86 處理器的基礎設計有缺失導致產生嚴重的安全問題所致，同時這也是 Intel 在三個月內的第二次重大出包。

設計缺失導致的安全問題

此次爆發的問題主要是肇因於 Intel 在設計處理器架構時的缺失 (由於此缺失的詳情基於安全考量仍然由 Intel 保密，因此確切的內容與原理尚無法得知，目前主要的猜測是 Intel 處理器的推測執行 Speculative Execution 功能採用的設計方式可能允許由 Ring 3 往 Ring 0 的越權記憶體參照所造成) 導致一般運作於使用者層的應用程式 (舉凡商業領域應用或伺服器上的資料庫軟體、網頁伺服器軟體或是個人用戶使用的瀏覽器、javascript、遊戲軟體均屬之) 可以有機會窺探受保護的核心記憶體區塊 (Protected Kernel Memory) 的部分分佈地址。

值得注意的是，AMD 處理器由於在架構上並不允許由高 Ring (Ring 3，低權限) 往低 Ring (Ring 0，高權限) 的的記憶體參照 (包含推測參照 Speculative Reference)，而在類似情況的存取 (由使用者層嘗試存取核心記憶體) 操作發生時在 AMD 系統上時將會直接導致分頁錯誤，因此 AMD 處理器並沒有這次被發現的問題，此事已由 AMD 的工程師 Tom Lendacky 確認 (2018/01/04 AMD 也已經發出官方聲明)。

可能造成核心記憶體洩漏 (Kernel Memory Leak)

這個問題將使核心記憶體位置隨機分配 (Kernel Address Space Layout Randomization, KASLR) 這項透過將核心記憶體區塊分散到虛擬記憶體的隨機位置從而避免轉傳或重複使用電腦指令的惡意行為 (惡意程式將因此很難猜到其所需關鍵資料的實際記憶體位置) 之保護機制產生得以被繞過的可能，使得使用者層程式越權存取核心記憶體內容的成功機率大幅提升，這將使得惡意程式得以透過攻擊作業系統核心進而由底層向上影響整個系統的攻擊行為之可能性大幅提高。

除此之外還有可能有更嚴重的影響，然而因為目前此設計缺失的詳情仍然屬於 Intel 的內部機密，因此尚無從得知，但根據國外報導，從兩大主要作業系統近期快速且強烈的反映來看，實際上問題可能更加嚴重。

對雲端服務商帶來嚴重安全隱患

如同前述，此問題導致了相當大的安全隱患，但目前而言對一般個人電腦使用者來說尚無立即的危險性，但對於雲端服務商 (例如 VPS 廠商) 而言就非常嚴重了，此問題有可能導致惡意用戶得以利用此漏洞跨越虛擬化技術對各個運算執行個體之間的分隔從而達到攻擊同台主機上其他虛擬機器個體甚至竊取其他用戶資料的目的。

這或許合理解釋了前幾天 Amazon Web Services 與微軟 Azure 等雲端服務業者突然發出虛擬機器維護通告的原因，不過兩大廠商截至目前為止都未正面回答本次維護的內容。

---

(2018/01/04 更新)
隨著漏洞的相關資訊已經提早開始陸續公佈，Azure 已經在數個小時前發出通知將不再提供用戶自行提前維護的選項，並且將原先排定在下個禮拜的維護重新啟動作業提前到今天立刻開始進行。

根據微軟在信中的說法，他們已經盡可能將此次修正之後對虛擬機器性能造成的影響降到最低，應只有少部分用戶可能會注意到網路性能受到一些影響，但可以透過 Azure 加速網路這項免費服務解決，而本次修補是在 Azure 機房端的實體伺服器上所執行的 Hypervisor 進行，因此虛擬機器中執行的作業系統不需要進行特殊調整，只需要配合微軟的維護時程重新啟動即可。

史上影響範圍最廣的處理器 bug

(2018/01/05 更新)
以下紅字部分係依據 2018/01/05 Intel 發佈之安全性通告 INTEL-SA-00088 的內容增加。

(2018/01/04 更新)
目前已知 Meltdown 問題除了下列 Intel 處理器之外，ARM Cortex A75 也會受到影響 (ARM 官方表示 Cortex A72、Cortex A57、Cortex A15 也有使用類似的機制，但由於可以從中獲取的資料並不會揭露禁止存取暫存器的結構，因此被認為不需要進行修正)，而 AMD 的部分則是只在 Linux 核心開啟 BPF JIT 的情況下才會受影響，至於 Specture 問題則是近代處理器幾乎通通有獎。

---

此問題目前已知影響近十年內所有的 Intel x86 處理器，考慮到 Intel x86 處理器在個人電腦與伺服器領域的龐大市占率，這很有可能是近年來影響範圍最廣的硬體錯誤 (而且由於影響年代比上次 Management Engine 出問題還廣，加上又是處理器架構本身的問題，因此受影響的電腦數量必定更多)，目前已知受到影響的處理器系列有下列這些 (包含伺服器各版本、桌上型電腦各版本、筆記型電腦各電壓版本)：

• Core 架構 (Intel 未將其列入受影響清單中)
  Core Solo、Core 2 Duo、Core 2 Quad、Core 2 Extreme 等
• Westmere 架構
  第一代 Core 系列、Xeon E7 系列、Xeon 5600 系列、Xeon 3600 系列、Xeon 3400 系列、Xeon 5500 系列、Xeon 6500 系列、Xeon 7500 系列
• Sandy Bridge 架構
  第二代 Core 系列、Xeon E5 系列、Xeon E3 系列、第三代 Core HEDT 系列
• Ivy Bridge 架構
  第三代 Core 系列、Xeon E5 v2 系列、Xeon E3 v2 系列、Xeon E7 v2 系列、第四代 Core HEDT 系列
• Haswell 架構
  第四代 Core 系列、Xeon E5 v3 系列、Xeon E3 v3 系列、Xeon E7 v3 系列、第五代 Core HEDT 系列
• Broadwell 架構
  第五代 Core 系列、Xeon E5 v4 系列、Xeon E3 v4 系列、第六代 Core HEDT 系列、Core M 系列
• Skylake 架構
  第六代 Core 系列、Xeon 可擴展處理器系列 (Xeon Scalable Family)、Xeon E3 v5 系列、第七代 Core X-Series 系列、Xeon W 系列、Core M 系列
• Kaby Lake 架構
  第七代 Core 系列、Xeon E3 v6 系列、第七代 Core X-Series 系列、Core M 系列
• Coffee Lake 架構
  第八代 Core 系列、Xeon E 系列
• Intel Atom 部分產品
  Intel Atom C、E、A、Z、x3 系列
• Intel Celeron、Pentium 部分產品
  Intel Celeron J、N 系列、Intel Pentium J、N 系列
• Intel Xeon Phi 部分產品 (Knights Landing 架構)
  Intel Xeon Phi 3200 系列、Intel Xeon Phi 5200 系列、Intel Xeon Phi 7200 系列

從上面的清單看起來這個問題很有可能早在 2006 年推出的 Core 架構當中就已經存在，甚至還有傳聞表示此問題有可能來自於 Core 架構的直系先祖 Pentium III 或是 Pentium III 的根源 Pentium Pro (P6 微架構)，若是如此將意味著僅有基於 Netburst 的 Pentium 4、Pentium D 等系列與基於 Pentium (P5) 改良而來的 Xeon Phi 沒有這個問題。

修復上的困難與影響

實際上由於現代處理器非常複雜，因此處理器本身出現 bug 的情況其實是稀鬆平常的事情，特別是在開發階段 (例如 ES1 通常有大量錯誤甚至根本不堪用、ES2 階段則勉強堪用或是接近穩定，到了 Pre-QS 都還可能有一些會影響使用的問題)，然而通常處理器廠商直到處理器上市 (QS 階段) 都不會完全將所有 bug 除去 (原則上只會將 bug 減少到不影響使用、在使用上感受不到的程度)，舉例來說你可以在這裡看到 Skylake 架構的已知問題 (Errata)，目前就已經有超過 150 個已知問題，其中絕大多數在使用中是感受不到或在軟體開發過程中能被避開的。

而當有足以影響使用的 bug 被發現時，由於大型積體電路光刻模板修改的成本非常高，加上產品已經推出市面不可能全數召回，矽晶片也無法事後修改等因素，因此在 CISC 架構的處理器當中便設計了微碼 (microcode) 架構來將機器指令與電路實作分離，使得若不是太嚴重的問題通常可以透過在 BIOS 內加入微碼 (microcode) 的更新進行解決，而不會直接更改光刻模板、改變步進 (Stepping)。

不幸的是，由於這次的問題是出現在 CPU 架構 (與電路設計直接相關) 上，加上影響層面過於廣泛因此沒有辦法使用以往慣用的微碼更新方式解決，而是只能透過修改作業系統 (因為本次出問題的部分主要由作業系統掌管) 或是更換處理器的方式進行解決。

目前的解決方案

目前作業系統開發者想出用來解決這個問題的方式是在作業系統核心引入一項稱為「核心分頁表隔離 (Kernel Page Table Isolation, KPTI)」(前身為 KAISER) 的特性。

如同我們所知道的，現代電腦系統在運作時主要可以分為 User Mode (x86 架構中為 Ring 3) 與 Kernel Mode (x86 架構中為 Ring 0) 兩種執行模式，其中應用程式與作業系統的一部分運作於 User Mode，而 Kernel Mode 則由作業系統核心獨佔，這樣的區分主要是為了避免一般程式能夠凌駕作業系統直接控制硬體造成衝突或嚴重的安全性問題與避免特定程式出錯時導致整個系統停擺而設計的，而當應用程式需要執行這類操作的時候就需要透過轉交具有 Kernel Mode 權限的作業系統核心進行 (處理器會接收到插斷訊號 interrupt 然後把控制權交給作業系統核心主控，也就是切換到 Kernel Mode)。

因此在日常運作中處理器會經常需要在 Kernel Mode 與 User Mode 之間切換，為了避免切換過程花掉太多資源 (在切換時 CPU 須將目前工作的狀態保存，在結束切換時 CPU 又必須將先前保存的狀態取回繼續使用，稱之為上下文交換 Context Switching)，因此作業系統會在 User Mode 程式的分頁表當中保留完整的核心記憶體分頁表 (但是 User Mode 程式並無權存取也看不見其存在)，從而節省 CPU 用於處理 TLB 重新整理等操作時所消耗的資源與時間。

而 KPTI 的做法則是取消前述的措施，改將核心記憶體放入一個完全獨立分割出來的記憶體位置區塊，從而完全根絕 User Mode 程式存取核心記憶體的可能性，因此前面提到的越權存取可能也就不存在了。

各家作業系統處理現況

Linux
目前 Linux 核心 4.15 的開發版本 (rc6) 當中已經將 KPTI 相關的代碼整合進來，同時這項特性也被反向移植 (backported) 到 Linux Kernel 4.14 上。

Windows
至於 Windows 的部分則是從公眾預覽版本 Build 17035 開始具備類似特性，現有各正式發行版本的更新檔案也已經發佈，請參考本站文章「微軟針對各版本 Windows 釋出修補 CPU Meltdown 漏洞的緊急更新 (內附注意事項與載點)」。

macOS 與 iOS
蘋果聲明旗下 iOS 裝置、Mac 與 Apple TV 全數受到影響，且其已經在 iOS 11.2、macOS 10.13.2 與 tvOS 11.2 當中引入針對 Meltdown 的修正措施 (Apple Watch 並未受到影響)，之後會在後續的 iOS、macOS、tvOS 與 watchOS 更新當中針對 Spectre 問題進行防堵。

Android
Google 已經在 2018 年 01 月的安全性修補中包含了對 Meltdown 問題的修正，但須等待各家手機廠商將其納入 OTA 軟體更新之中 (可能還有得等，而且會有相當大比例的裝置可能拿不到更新)。

性能上的代價

前面提過當初在 User Mode 程式的分頁表當中保留完整的核心記憶體分頁表的原因是基於性能上的考慮，因此是否採用 KPTI 勢必會對性能造成影響，如果不是 Intel 處理器本次被揭露的問題，現階段應該只需要使用 KASLR 機制就足以提供足夠的安全性而且不至於對性能帶來太大的影響。

目前已知在啟用 KPTI 機制之後性能減損最大的是具有 I/O 密集特性的伺服器應用，以 PostgreSQL 為例目前 Phoronix 所做的初步測試出現了高達 20% 的性能損失，Redis GET 測試也出現了約 5% 左右的性能損失，在極端情況下處理某些操作可能會出現高達 30% 至 50% 的性能減損，PostgreSQL 官方的郵件清單中也有開發人員表示在最糟的情況下 (關閉 PCID)，pgbench SELECT 1 測試出現了高達 23% 的性能損失。

PostgreSQL SELECT 1 with the KPTI workaround for Intel CPU vulnerability https://t.co/N9gSvML2Fo

Best case: 17% slowdown
Worst case: 23%

— The Register (@TheRegister) 2018年1月2日

此解決方案對一般電腦使用者的性能影響

然而對於一般電腦使用者而言，KPTI 對性能的影響相對而言就沒那麼明顯了，對於磁碟速度基準測試等 I/O 密集工作可能會有比較可見的影響，但在遊戲、影片轉檔與日常運用方面目前則沒有出現大幅度的性能衰退。

目前 Computerbase.de 使用 Windows 10 秋季創作者更新正式發行版本 Build 16299 (不含 KPTI) 與 Windows 10 公眾預覽版本 Build 17063 (包含 KPTI) 進行日常常用操作測試之後並沒有發現明顯的性能落差，幾乎都在誤差範圍內，因此今天網路上瘋傳的 Intel 出包性能全部打八折、Intel 處理器一口氣把近幾年的性能改進全部吐回去等描述是太過誇張了一點，實際影響程度多寡還需要等待後續更多測試出爐才能判斷。

後記

Intel 這次出的問題確實非同小可，而且對於 Intel 來說營收最大佔比其實不是個人電腦運算而是本次受影響程度最為劇烈的伺服器處理器市場，或許這對 AMD 來說是一個很好的翻身機會，畢竟對於企業運算市場來說可靠性是極端重要的因素，這樣的問題是難以被忍受的。

目前還不清楚這會對 Intel 後續的產品造成多大的影響，就以往時程來看 Cannon Lake (第九代 Core 處理器)、Cascade Lake-X (第八代 Core HEDT) 應該已經進入後期除錯階段，能不能在量產之前修正是值得觀察的事情 (稍早傳出的消息是 Cannon Lake 前面可能又會冒出一個 Whiskey Lake，或者 Whiskey Lake 可能會是 Cannon Lake 的筆記型電腦版本)，而已經量產 Coffee Lake-H (第八代 Core 筆記型電腦處理器)、Coffee Lake-G (搭配 AMD 半獨立顯示晶片的第八代 Core 筆記型電腦處理器) 應該是仍然會受到同樣問題的影響。

最尷尬的大概要屬才剛上市不久的 Xeon Scalable Family (Purley Platform) 與 Xeon W、Xeon E 系列伺服器處理器了吧？新的系列劃分已經夠亂了又遇上這次出包，最近 Intel 在本業的策略上似乎真的出了一點問題。

此外，由於本次事出突然因此目前最新測試版本的 Linux Kernel 4.15-rc6 也將 AMD 處理器列入適用 KPTI 的範圍內 (與 Intel 處理器同樣被標示為 X86_BUG_CPU_INSECURE) 而發生相同的性能下降問題，然而由於 AMD 處理器不受此漏洞影響，因此暫時解決方案為在開機時加上 nopti 參數來禁用 KPTI 特性即可避免性能損失，目前 Linus Torvalds 已經接納來自 AMD 的修改 (將 AMD CPU 排除適用 KPTI)，預計在 Linux Kernel 4.15-rc7 與 4.14.12 當中生效。