?硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（上）

? by 癡漢水球 ? 2018.02.09 10:00AM

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 科學(xué)新知 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 硬科技 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intel ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 處理器 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 資安 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? 最近數(shù)天內(nèi)實在歡樂異常，拜Google Project Zero計畫背書之所賜，持續(xù)「炎上」火勢越燒越大，還一路延燒「好厝邊」AMD和ARM的Intel處理器漏洞事件，應(yīng)該是資訊業(yè)界時下最夯的熱門話題，為嶄新的2018年打響了擾人清夢的第一砲，而Intel執(zhí)行長在這極度敏感的心裡關(guān)鍵時刻，將手上的持股出清到公司董事會規(guī)定的低標(biāo)，所引發(fā)的爭議，更是跳到太平洋也洗不清，反正現(xiàn)在太平洋也沒多乾淨(jìng)。 總之，唯一可以肯定的是，一路觀察下來，真正有看懂Google那篇官方部落格文的媒體，恐怕僅為鳳毛鱗爪，但惟恐天下不亂大肆散播恐慌，東拼西湊出一篇篇看似連筆者都看不懂的「有字天書」報導(dǎo)者，絕對有如過江之鯽，然後又一票科技文青繼續(xù)一如往昔的驚呆了。 但相信各位科科們絕對不會滿足於坊間多數(shù)媒體捉風(fēng)補影繪聲繪影的報導(dǎo)中，僅僅那句比較有意義的「利用處理器預(yù)測執(zhí)行機制，先斬後奏提前存取記憶體，又沒做好權(quán)限安全性檢驗的漏洞」和一票看不懂的聖經(jīng)密碼像KPTI ?KASLR KAISER Spectre ?Meltdown等，而是希望能在腦中描繪出整個命案現(xiàn)場的全貌與畫在馬路上的人形粉筆圈，所以你才會勉力爬文爬到這裡。 我們先回到原點，從基本觀念—近代作業(yè)系統(tǒng)的兩大重要元素「保護模式」與「虛擬記憶體」—為起點，一步一腳印的踏入迷宮的最深處，最起碼了解為何作業(yè)系統(tǒng)修正此漏洞後，那號稱造成最多30%的效能損失，到底兇手是誰，人是誰殺的，誰是在畫面中全身一直塗成黑色還不停奸笑著的黑衣人。 多工作業(yè)系統(tǒng)或任何虛擬化環(huán)境的兩種基本運作權(quán)限 如同現(xiàn)實世界對公用資源的保防措施，為了確保多工作業(yè)系統(tǒng) (或虛擬機器) 的正常運作，隔離不同應(yīng)用程式 (或作業(yè)系統(tǒng)) ?所使用的系統(tǒng)資源，免於來自錯誤程式的破壞，確保使用者不會互相干擾，我們必須保護作業(yè)系統(tǒng)核心與虛擬機器Hypervisor、系統(tǒng)檔案與共用資源，所以至少需要兩種不同的運作權(quán)限：「使用者模式 ?(User Mode)」 與「系統(tǒng)模式 (System Mode)」。 先回顧作業(yè)系統(tǒng)的啟動流程：按下開機按鈕，處理器先從Boot ROM擷取並執(zhí)行系統(tǒng)自我檢測程式 (也就是BIOS和UEFI的工作)，然後從大型儲存媒介讀取OS Loader，再將作業(yè)系統(tǒng)核心 (Kernel) 載入至記憶體，接著在系統(tǒng)模式執(zhí)行作業(yè)系統(tǒng)核心，開始載入裝置驅(qū)動程式，直到作業(yè)系統(tǒng)已經(jīng)可以完全管理電腦的底層硬體裝置，就進入應(yīng)用程式執(zhí)行階段，啟動使用者模式。

此外，可能「動搖國本」更動系統(tǒng)底層狀態(tài)的指令，都應(yīng)該被定義為只能在系統(tǒng)模式執(zhí)行的「特權(quán)指令 (Privileged ?Instruction)」，如在使用者模式執(zhí)行，則將觸發(fā)處理器的例外處理機制，再經(jīng)由作業(yè)系統(tǒng)的「設(shè)陷 ?(Trap，或稱為軟體中斷)」，決定是否執(zhí)行該指令，如應(yīng)用程式透過「系統(tǒng)呼叫 (System ?Call)」，要求得到更多的記憶體空間或進行I/O存取。

奠定多工作業(yè)系統(tǒng)精巧記憶體保護的虛擬記憶體 一般電腦玩家對「虛擬記憶體」的認知多半僅限於「主記憶體不夠時，電腦將塞不下的東西丟到硬碟，然後就開始聽著硬碟發(fā)出陣陣的哀號」，但這就太過小看虛擬記憶體對近代多工作業(yè)系統(tǒng)那舉足輕重的重要性了，甚至說虛擬記憶體是當(dāng)代汎用型作業(yè)系統(tǒng)的地基也不為過。

由小到大，虛擬記憶體的重點如下：

• 程式不再受限於可用的實體記憶體總量，並將實際上四散各處的實體記憶體位址 (Physical Address)，轉(zhuǎn)化為一整塊連續(xù)可用的虛擬記憶體空間，簡化程式開發(fā)的工作。

• 所謂的「虛擬位址 (Virtual Address)」也就是應(yīng)用程式眼中所看到的記憶體位址。值得注意的是，越接近處理器核心的快取記憶體，越傾向使用虛擬位址進行索引 (Index)，原因不言可喻。

• 主記憶體只須包含被程式使用到的部份，不必整個塞進去，意味更多程式可一起獨樂樂不如眾樂樂。

• 允許大量的應(yīng)用程式同時在同一臺電腦上執(zhí)行，並減少載入與置換每個程式的I/O負擔(dān)。(不過在記憶體貴的要命的年代，沒事一直聽硬碟慘叫的老玩家可能感受不到)

• 每個行程 (Process) 都享有自己的虛擬位址空間，不同的虛擬頁 (Page) 會映射到不同的實體記憶體位址。

• 提供更精巧的記憶體保護，如透過前述的保護模式、系統(tǒng)呼叫，與虛擬分頁中的權(quán)限位元，作業(yè)系統(tǒng)可透過改變分頁表 (Page Table) ?，對執(zhí)行中的眾多應(yīng)用程式號令天下「朕給你的，才是你的，朕不給你的，你不能搶」。如發(fā)生分頁錯誤 (Page ?Fault)，應(yīng)用程式所需要的分頁不位於主記憶體，此時就須啟動例外處理以中斷執(zhí)行中的行程並「處理後事」。

換言之，經(jīng)由虛擬記憶體的管理，作業(yè)系統(tǒng)核心和應(yīng)用程式所佔用的實體記憶體位址與分佈方式，並非井水不犯河水，現(xiàn)實上是有可能「水乳交融」在一起的。 此外，為了加速虛擬位址與實體位址之間的轉(zhuǎn)換，處理器通常內(nèi)建了一個稱為TLB (Translation Lookaside ?Buffer)的小型快取記憶體，不同的分頁表管理策略，如同迥異的記憶體存取模式，對其命中率都會產(chǎn)生極大的影響，而且因為TLB算是分頁表的子集合，TLB誤失和分頁錯誤一樣的不好應(yīng)付，頻繁的「刷洗 ?(Flush)」TLB內(nèi)容對整體效能的傷害，有如深度指令管線發(fā)生預(yù)測執(zhí)行錯誤般的「火燒摩天樓」一樣的可怕，甚至有過之而無不及。 開始冒煙但尚未起火的關(guān)鍵線索 科科們也許已經(jīng)抱怨著「這些不都是爾孰能詳」的計算機組織基礎(chǔ)知識嗎？但恭喜各位，你們其實已經(jīng)開始誤入真正的雷區(qū)了。

• 既然系統(tǒng)權(quán)限已經(jīng)受到重重保護，為何還會被「僭越」？

• 要如何旁敲側(cè)擊出享受分頁表庇蔭的作業(yè)系統(tǒng)核心的實體記憶體位址？

• 為何這些作業(yè)系統(tǒng)的補洞程式會造成大量TLB Flush，並增加執(zhí)行系統(tǒng)呼叫的成本？

後面我們就來開始踩地雷，瞧瞧Google團隊是如何對當(dāng)代非循序執(zhí)行 (Out-Of-Order Execution) 處理器上下其手，祝各位科科不要被炸上天呀。ㄎㄎ。

硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（中）

? by 癡漢水球 ? 2018.02.10 08:00AM

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 科學(xué)新知 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 硬科技 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intel ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 安全漏洞 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 漏洞 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? 這次Google Project Zero引爆的深水炸彈，也意外的讓「預(yù)測執(zhí)行 (Speculative Execution)」、「非循序執(zhí)行 (Out-Of-Order Execution)」和「分支預(yù)測 (Branch Prediction)」這些歷史悠久的計算機結(jié)構(gòu)專有名詞，再度成為網(wǎng)路論壇的熱門關(guān)鍵字。 為了方便各位科科瞬間理解上面三個名詞的關(guān)係，請記得以下恆等式，不必謝我。 「預(yù)測執(zhí)行 = 分支預(yù)測 + 非循序執(zhí)行」，根據(jù)分支預(yù)測的結(jié)果，先斬後奏賭博性的執(zhí)行指令，再藉由非循序執(zhí)行引擎維持指令執(zhí)行順序的一致性，與回復(fù)當(dāng)預(yù)測錯誤時的處理器狀態(tài)，各位只要知道這些就夠了。

如果一時之間還搞不懂為何要這樣作，請重新想清楚「電腦 (Computer)」和「計算器 (Calculator)」最大的不同之處：電腦最重要特徵在於「條件判斷」的能力，根據(jù)不同的條件，執(zhí)行不同的指令流。 如果你不想看到整條指令管線，因為等待確認條件判斷的結(jié)果而停擺，就需要設(shè)計一個紀(jì)錄分支歷史的小型快取記憶體，根據(jù)其內(nèi)容「以古鑑今」去預(yù)測分支是否發(fā)生，或著發(fā)生後會跳到哪個記憶體位址，再繼續(xù)擷取並預(yù)測性的執(zhí)行指令。 分支預(yù)測當(dāng)然也有可能發(fā)生錯誤，像迴圈 (Loop) 就是一例，反覆發(fā)生 (Taken) 後，起碼最後一次就不會發(fā)生 (Not Taken)，這也暗示了我們可以藉由「訓(xùn)練」分支預(yù)測，使其錯誤地預(yù)測執(zhí)行不應(yīng)被執(zhí)行的程式碼。 既然系統(tǒng)權(quán)限已經(jīng)受到重重保護，為何還會被「僭越」？ 我們前面有看到處理器會有不同的程式執(zhí)行權(quán)限與記憶體保護機制，但為何還會發(fā)生「下犯上」使用者模式可以讀取到系統(tǒng)核心資訊的慘劇，原因很簡單，因為預(yù)測執(zhí)行「衝過頭」了，將不應(yīng)該被應(yīng)用程式存取到的記憶體位置，跳過權(quán)限檢查，被預(yù)先載入快取記憶體，即使此預(yù)測執(zhí)行作廢，該記憶體位址區(qū)段仍在快取內(nèi)，此時此刻有心人就有上下其手的機會，例如可「旁敲側(cè)擊」觀察記憶體存取的反應(yīng)時間 ?(被快取到當(dāng)然會更短)，判斷這段記憶體位址是否屬於系統(tǒng)核心。 事實上，近代高效能處理器的預(yù)測與非循序執(zhí)行，並非僅限於指令，連記憶體存取這檔事都可雨露均霑，不按牌理出牌，在x86世界源自於Intel ?Core微架構(gòu)「Merom」的「記憶體資料相依性預(yù)測功能 (Memory ?Disambiguation)」即為最好的範(fàn)例，根據(jù)預(yù)測，承受後面的記憶體載入指令、可能需要前面載入執(zhí)行結(jié)果的相依性風(fēng)險，不等待前面回存 ?(Store) 指令完成工作，大膽的提前載入 (Load) 記憶體位址，以確保指令管線不停頓的順暢運轉(zhuǎn)。 一圖勝千言，直接引用Intel當(dāng)年介紹Merom的簡報。原本Load4要等待Store3完成。

▲有了記憶體資料相依性預(yù)測功能，不等Store3，Load4就賭下去了。當(dāng)然，如果賭錯了，後頭要收拾殘局的成本就非常的高，大約40個時脈週期就飛了，但看在賭對了就賺翻了的份上，硬著頭皮還要給他賭下去。

▲有沒有突然感覺到，這些處理器設(shè)計者好像都蠻「賭性堅強」？ 很不幸的，Intel剛剛好就是這群賭徒中，特別敢冒險的那位 (Intel其實在微架構(gòu)設(shè)計上一直蠻激進的)，有時候還真心覺得夜路走多了真的會碰到鬼，的確不是騙人的，Google Project Zero就活見「鬼」了。 成本高昂的分頁表隔離 前一篇有提到透過分頁表管理虛擬記憶體的配置，需要權(quán)限保護的作業(yè)系統(tǒng)核心，與一般使用者的應(yīng)用程式，實際上是會有可能混在一起的。以32位元Linux為例，理論上應(yīng)用程式可以看到4GB的虛擬位址，但其實最上面1GB的屬於系統(tǒng)核心；32位元Windows也有類似的限制，1GB或2GB切給作業(yè)系統(tǒng)核心與驅(qū)動程式，所以應(yīng)用程式只能使用到3GB或2GB。

簡而言之，應(yīng)用程式的確有機會利用某些漏洞，存取本應(yīng)不該被允許的系統(tǒng)核心資訊。 那你也許會問：既然如此，為何我們不堅壁清野，維護兩份獨立的分頁表，一份系統(tǒng)核心，一份使用者，不就功德圓滿了？ 但每次系統(tǒng)呼叫，都需要反覆切換分頁表並搬移大量的資料，尤其用來加速虛擬位址轉(zhuǎn)換實體位址的TLB (Translation ?Lookaside Buffer) 會一直「上沖下洗 ?(Flush)」，等於每次系統(tǒng)呼叫都要重建快取資料，想閃也閃不開，導(dǎo)致嚴重的效能損失，這也是為何主流作業(yè)系統(tǒng)都將敏感的系統(tǒng)核心資訊，安置在虛擬位址的高位，並透過將程式碼與資料「隨機性」的散布其內(nèi)，以避免當(dāng)某個漏洞被發(fā)現(xiàn)時，被用來「一招半式打天下」，難以採用通用手段危害作業(yè)系統(tǒng)的強固性。 但很不幸的，Google Project Zero的研究成果，終究還是將作業(yè)系統(tǒng)廠商逼回成本高昂的「隔離」手段，最起碼眼前的短期方案僅限於此，能否有更低成本的手段，還在未定之天。往好處想，無須系統(tǒng)呼叫的純運算工作，效能應(yīng)該不會受到什麼影響，也許吧。 對x86處理器來說，問題就更大條了，兩份獨立的分頁表，意味著避開昔日16位元時代遺產(chǎn)「節(jié)區(qū) (Segment) 記憶體定址」的「平面 ?(Flat) ?記憶體模式」就此破功，對於那些早已「放生」老舊記憶體定址模式效能的新型x86處理器微架構(gòu)來說，實在是不堪回首的嚴酷考驗，這就像一道旋轉(zhuǎn)們，你越積極的拋棄遺產(chǎn)讓微架構(gòu)針對未來最佳化，你背後被老舊包袱狠狠集中的後座力也越大，所謂「牙膏擠了原來還能吸回去」，大概就是這麼一回事。 ?硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（下）

? by 癡漢水球 ? 2018.02.13 01:05PM

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 科學(xué)新知 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 硬科技 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intel ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 安全漏洞 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 漏洞 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

• ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? intel漏洞 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? 現(xiàn)在也差不多是各位科科們該好好瞧瞧Google Project Zero公佈的「幽靈 (Spectre)」和「熔斷 (Meltdown)」的時候了。 還是一句老話，一個簡單的比較表，總是勝過千言萬語不著邊際的廢話。

天底下所有的技術(shù)，終究都是為了解決人類碰到的問題，關(guān)於這兩個命名看起來很恐怖的攻擊手段，也自然可以用生活化的比喻來解釋。目前網(wǎng)路上已不乏諸多「文科生」的野人獻曝，同樣文組背景的筆者，參考了某些頗具創(chuàng)意的解釋，自己也來掰一個。 看來依然無解的「幽靈 (Spectre)」 小明每天固定都在同一間金拱門... M記... 算了，不重要，買一樣的漢堡，他的愛慕者小強也想知道他吃哪種漢堡，所以喬裝路人「尾行」在後，進行調(diào)查。 小明對收銀員說：「點和昨天一樣的」，然後就付錢拿走漢堡 (密碼) 閃人了。 小強接著就對收銀員講：「我要點和前面一樣的。(非法讀取)」 收銀員：「你不能窺探他人隱私！」，然後就把小強轟出去了。(被執(zhí)行權(quán)限擋下，停止執(zhí)行)」 隔天，小強就找了另一位幫手，跟在他的後面排隊 (旁路攻擊)。 小強在小明點餐時，一直高喊「我要點和前面一樣的。(非法讀取)」，然後就被轟出去了 ?(被執(zhí)行權(quán)限擋下，停止執(zhí)行)，但是廚房裡面做漢堡的廚師聽到了 (製造錯誤分支預(yù)測)，為了提昇工作效率，多做了一個漢堡丟到空蕩蕩的輸送臺上 ?(預(yù)測執(zhí)行錯誤的指令，將不該被存取的記憶體位址載入快取內(nèi))。 輪到幫手時：「我餓死了，我要點店內(nèi)全部的漢堡，但是哪個最快就先給我。(旁敲側(cè)擊)」 最後幫手就拿到了和小明一樣種類的漢堡 (因為資料已經(jīng)在快取內(nèi)，讀取最快)，小強也就搞清楚小明吃的到底是什麼了，真是可喜可賀。至於小強有沒有塞給幫手足夠的漢堡錢，我們就不得而知了。 更糟糕的是，這奇計淫巧在Google引發(fā)大爆炸時，乍看之下沒有啥有效的處理方法，但後來Google又宣稱已經(jīng)找出不傷害效能的完美解決之道，看來秘訣是「在廚房和櫃臺中間，插入一位假裝廚師的中間人，或著弄出個假廚房，隔離兩者 ?(設(shè)置「陷阱 (Trap)」，讓預(yù)測執(zhí)行跳到人畜無害的位址)」，無法直接騙到廚師。效果如何，我們可以繼續(xù)觀望。 ?「幽靈 (Spectre)」：透過欺騙手法，讓其他應(yīng)用程式能進入記憶體內(nèi)的任意位置存取內(nèi)容，Intel AMD ARM都集體躺著中槍，現(xiàn)在就看Google公佈的「絕招」到底有沒有那麼神。 只有Intel獨享的「熔斷 (Meltdown)」 假設(shè)某位不良男子大學(xué)生想知道暗戀的對象在不在系學(xué)會，但對方和友人早已對他的癡漢行徑深感反感，根本寧願打死他也不讓他知道倒楣的女主角身處校園的何處，所以他就打電話去系學(xué)會問助教： 「請幫我查詢XXX (被騷擾的女主角) 在系學(xué)會幫忙的日程表，看看她是不是在系辦幫忙 (非法存取)。如果在的話，也請一併協(xié)助我有哪些科目已經(jīng)快要被當(dāng)了，需要我去跑系辦一個一個對教授磕頭跪算盤求Pass，這些可能需要請她幫忙講好話der?！? 助教一時不察，先看了系學(xué)會義工的日程表，嗯，她的確正在系學(xué)會，然後又花了不少時間去查詢這在系上惡名昭彰無聊男子快要掛掉的科目。(預(yù)測執(zhí)行) 但助教隨後突然反應(yīng)過來：我沒事去幫這快被二一的癡漢幹嘛 (察覺侵犯權(quán)限)？於是就在電話的另一端回覆：「你去死吧，打死不讓你去騷擾XXX。」(被執(zhí)行權(quán)限擋下，停止執(zhí)行) 「那好吧，就請助教大人告訴我有哪些科目需要在教授前面跪算盤的？」(旁敲側(cè)擊) 因為助教已經(jīng)花了不少時間查詢到這些資訊，而且這傢伙就算再該死，也總得有權(quán)知道自己是怎麼死的，所以就「你快被死當(dāng)?shù)目颇靠傆嬘?...」 (預(yù)測執(zhí)行錯誤的指令，將不該被存取的記憶體位址載入快取內(nèi))。 通常要找出這些資料需要好幾分鐘，但助教很快就告訴你答案，代表她真的有幫你處理，足以推測倒楣的XXX的確正在系辦，恭喜他，這位不良男子大學(xué)生可以準(zhǔn)備拔腿衝過去了。 這招也不限只找一個人，假如他不想看到女主角身邊的姊妹掏親衛(wèi)隊礙事，他也可以設(shè)定一份名單 (索引範(fàn)圍) ?和不同的衍生條件，去嘗試推敲出系辦現(xiàn)在到底有哪些討厭鬼，只是助教可能會先想砍死他，像「你現(xiàn)在給我來系辦，我保證不會打死你 ?(我並沒有違反我不殺的誓言，只是把你活活打個半死)」之類的。 這招的解法也很簡單：聘請另一位根本不認識系上同學(xué)的臨時工，專職負責(zé)查學(xué)生成績 (隔離分頁表)，讓助教連「預(yù)測執(zhí)行」的機會都沒有，但代價就是要多花錢僱用另一個人，助教要查成績時也只能請他查，提高時間成本。 ?「熔斷 (Meltdown)」：打破應(yīng)用程式被禁止任意存取系統(tǒng)記憶體的保護機制，讓應(yīng)用程式也能跟著存取到記憶體內(nèi)的內(nèi)容，目前僅Intel受害，透過隔離分頁表可以處理，只是成本很高。 面對排山倒海的媒體報導(dǎo)，莫驚慌、莫緊張、莫害怕 世上多數(shù)媒體的基因總是內(nèi)建惟恐天下不亂的本能，但我們回到原點，這些利用處理器預(yù)測執(zhí)行缺陷的攻擊手段，真的如部份媒體繪聲繪影般的可怕嗎？筆者覺得：不會。

• 這都是「本地端」的攻擊手段，並不是駭客遠在地球的另一端按下按鍵、你的電腦就瞬間自爆的遠端攻擊。

• 現(xiàn)階段只有資料被不當(dāng)讀取的風(fēng)險 (讀出來也不見得有用)，但不會破壞現(xiàn)有運行中系統(tǒng)的強固性。

• 成功的攻擊都需要搭配大量的「助攻」，現(xiàn)實世界不太可能出現(xiàn)如此理想的環(huán)境。講的更白一點，無論是幽靈還是熔斷，其實際危險性恐怕不會比十多年前Intel HyperThreading旁路攻擊的安全性事件嚴重到哪裡去。

目前最積極介入此事的Google和Amazon，其最擔(dān)憂的莫過於資料中心內(nèi)虛擬機器Hypervisor被用戶端作業(yè)系統(tǒng)偷讀重要資料、導(dǎo)致影響虛擬機安全性這檔事，對人類最大的衝擊也就是數(shù)以萬計的伺服器要安裝修正檔並重新開機，進而衝擊雲(yún)端服務(wù)的總體效能吧。手機的話，再看看?？傊o觀其變即可，為了這種蠢事而驚呆，不是站在時代浪頭的科科們該有的作為。 但這次所有晶片廠商的反應(yīng)與危機處理，特別是首當(dāng)其衝的Intel，過程和態(tài)度是否「社會觀感不佳」，那又是另外的故事了。不過，難道你不會好奇，既然Intel ?AMD ARM的非循序執(zhí)行處理器都中槍了，難道IBM Oracle Fujitsu的，就能保證全身而退嗎？ 至於這兩種攻擊的根除之道，不學(xué)無術(shù)的筆者已經(jīng)想到了完美的解決方案，但如同費瑪最後定理，礙於文章字數(shù)限制寫不出來，我們下次有機會再好好談?wù)?，科科? ? ? ? ??