【转】被Intel處理器漏洞嚇傻前 科科們要先知道的事
硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（上）
by 痴漢水球 2018.02.09 10:00AM
最近數天內實在歡樂異常，拜Google Project Zero計畫背書之所賜，持續「炎上」火勢越燒越大，還一路延燒「好厝邊」AMD和ARM的Intel處理器漏洞事件，應該是資訊業界時下最夯的熱門話題，為嶄新的2018年打響了擾人清夢的第一砲，而Intel執行長在這極度敏感的心裡關鍵時刻，將手上的持股出清到公司董事會規定的低標，所引發的爭議，更是跳到太平洋也洗不清，反正現在太平洋也沒多乾淨。 總之，唯一可以肯定的是，一路觀察下來，真正有看懂Google那篇官方部落格文的媒體，恐怕僅為鳳毛鱗爪，但惟恐天下不亂大肆散播恐慌，東拼西湊出一篇篇看似連筆者都看不懂的「有字天書」報導者，絕對有如過江之鯽，然後又一票科技文青繼續一如往昔的驚呆了。 但相信各位科科們絕對不會滿足於坊間多數媒體捉風補影繪聲繪影的報導中，僅僅那句比較有意義的「利用處理器預測執行機制，先斬後奏提前存取記憶體，又沒做好權限安全性檢驗的漏洞」和一票看不懂的聖經密碼像KPTI KASLR KAISER Spectre Meltdown等，而是希望能在腦中描繪出整個命案現場的全貌與畫在馬路上的人形粉筆圈，所以你才會勉力爬文爬到這裡。 我們先回到原點，從基本觀念—近代作業系統的兩大重要元素「保護模式」與「虛擬記憶體」—為起點，一步一腳印的踏入迷宮的最深處，最起碼了解為何作業系統修正此漏洞後，那號稱造成最多30%的效能損失，到底兇手是誰，人是誰殺的，誰是在畫面中全身一直塗成黑色還不停奸笑著的黑衣人。 多工作業系統或任何虛擬化環境的兩種基本運作權限 如同現實世界對公用資源的保防措施，為了確保多工作業系統 (或虛擬機器) 的正常運作，隔離不同應用程式 (或作業系統) 所使用的系統資源，免於來自錯誤程式的破壞，確保使用者不會互相干擾，我們必須保護作業系統核心與虛擬機器Hypervisor、系統檔案與共用資源，所以至少需要兩種不同的運作權限：「使用者模式 (User Mode)」 與「系統模式 (System Mode)」。 先回顧作業系統的啟動流程：按下開機按鈕，處理器先從Boot ROM擷取並執行系統自我檢測程式 (也就是BIOS和UEFI的工作)，然後從大型儲存媒介讀取OS Loader，再將作業系統核心 (Kernel) 載入至記憶體，接著在系統模式執行作業系統核心，開始載入裝置驅動程式，直到作業系統已經可以完全管理電腦的底層硬體裝置，就進入應用程式執行階段，啟動使用者模式。
此外，可能「動搖國本」更動系統底層狀態的指令，都應該被定義為只能在系統模式執行的「特權指令 (Privileged Instruction)」，如在使用者模式執行，則將觸發處理器的例外處理機制，再經由作業系統的「設陷 (Trap，或稱為軟體中斷)」，決定是否執行該指令，如應用程式透過「系統呼叫 (System Call)」，要求得到更多的記憶體空間或進行I/O存取。
奠定多工作業系統精巧記憶體保護的虛擬記憶體 一般電腦玩家對「虛擬記憶體」的認知多半僅限於「主記憶體不夠時，電腦將塞不下的東西丟到硬碟，然後就開始聽著硬碟發出陣陣的哀號」，但這就太過小看虛擬記憶體對近代多工作業系統那舉足輕重的重要性了，甚至說虛擬記憶體是當代汎用型作業系統的地基也不為過。
由小到大，虛擬記憶體的重點如下：
- 程式不再受限於可用的實體記憶體總量，並將實際上四散各處的實體記憶體位址 (Physical Address)，轉化為一整塊連續可用的虛擬記憶體空間，簡化程式開發的工作。
- 所謂的「虛擬位址 (Virtual Address)」也就是應用程式眼中所看到的記憶體位址。值得注意的是，越接近處理器核心的快取記憶體，越傾向使用虛擬位址進行索引 (Index)，原因不言可喻。
- 主記憶體只須包含被程式使用到的部份，不必整個塞進去，意味更多程式可一起獨樂樂不如眾樂樂。
- 允許大量的應用程式同時在同一台電腦上執行，並減少載入與置換每個程式的I/O負擔。(不過在記憶體貴的要命的年代，沒事一直聽硬碟慘叫的老玩家可能感受不到)
- 每個行程 (Process) 都享有自己的虛擬位址空間，不同的虛擬頁 (Page) 會映射到不同的實體記憶體位址。
- 提供更精巧的記憶體保護，如透過前述的保護模式、系統呼叫，與虛擬分頁中的權限位元，作業系統可透過改變分頁表 (Page Table) ，對執行中的眾多應用程式號令天下「朕給你的，才是你的，朕不給你的，你不能搶」。如發生分頁錯誤 (Page Fault)，應用程式所需要的分頁不位於主記憶體，此時就須啟動例外處理以中斷執行中的行程並「處理後事」。
換言之，經由虛擬記憶體的管理，作業系統核心和應用程式所佔用的實體記憶體位址與分佈方式，並非井水不犯河水，現實上是有可能「水乳交融」在一起的。 此外，為了加速虛擬位址與實體位址之間的轉換，處理器通常內建了一個稱為TLB (Translation Lookaside Buffer)的小型快取記憶體，不同的分頁表管理策略，如同迥異的記憶體存取模式，對其命中率都會產生極大的影響，而且因為TLB算是分頁表的子集合，TLB誤失和分頁錯誤一樣的不好應付，頻繁的「刷洗 (Flush)」TLB內容對整體效能的傷害，有如深度指令管線發生預測執行錯誤般的「火燒摩天樓」一樣的可怕，甚至有過之而無不及。 開始冒煙但尚未起火的關鍵線索 科科們也許已經抱怨著「這些不都是爾孰能詳」的計算機組織基礎知識嗎？但恭喜各位，你們其實已經開始誤入真正的雷區了。
- 既然系統權限已經受到重重保護，為何還會被「僭越」？
- 要如何旁敲側擊出享受分頁表庇蔭的作業系統核心的實體記憶體位址？
- 為何這些作業系統的補洞程式會造成大量TLB Flush，並增加執行系統呼叫的成本？
後面我們就來開始踩地雷，瞧瞧Google團隊是如何對當代非循序執行 (Out-Of-Order Execution) 處理器上下其手，祝各位科科不要被炸上天呀。ㄎㄎ。
硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（中）
by 痴漢水球 2018.02.10 08:00AM
這次Google Project Zero引爆的深水炸彈，也意外的讓「預測執行 (Speculative Execution)」、「非循序執行 (Out-Of-Order Execution)」和「分支預測 (Branch Prediction)」這些歷史悠久的計算機結構專有名詞，再度成為網路論壇的熱門關鍵字。 為了方便各位科科瞬間理解上面三個名詞的關係，請記得以下恆等式，不必謝我。 「預測執行 = 分支預測 + 非循序執行」，根據分支預測的結果，先斬後奏賭博性的執行指令，再藉由非循序執行引擎維持指令執行順序的一致性，與回復當預測錯誤時的處理器狀態，各位只要知道這些就夠了。
如果一時之間還搞不懂為何要這樣作，請重新想清楚「電腦 (Computer)」和「計算器 (Calculator)」最大的不同之處：電腦最重要特徵在於「條件判斷」的能力，根據不同的條件，執行不同的指令流。 如果你不想看到整條指令管線，因為等待確認條件判斷的結果而停擺，就需要設計一個紀錄分支歷史的小型快取記憶體，根據其內容「以古鑑今」去預測分支是否發生，或著發生後會跳到哪個記憶體位址，再繼續擷取並預測性的執行指令。 分支預測當然也有可能發生錯誤，像迴圈 (Loop) 就是一例，反覆發生 (Taken) 後，起碼最後一次就不會發生 (Not Taken)，這也暗示了我們可以藉由「訓練」分支預測，使其錯誤地預測執行不應被執行的程式碼。 既然系統權限已經受到重重保護，為何還會被「僭越」？ 我們前面有看到處理器會有不同的程式執行權限與記憶體保護機制，但為何還會發生「下犯上」使用者模式可以讀取到系統核心資訊的慘劇，原因很簡單，因為預測執行「衝過頭」了，將不應該被應用程式存取到的記憶體位置，跳過權限檢查，被預先載入快取記憶體，即使此預測執行作廢，該記憶體位址區段仍在快取內，此時此刻有心人就有上下其手的機會，例如可「旁敲側擊」觀察記憶體存取的反應時間 (被快取到當然會更短)，判斷這段記憶體位址是否屬於系統核心。 事實上，近代高效能處理器的預測與非循序執行，並非僅限於指令，連記憶體存取這檔事都可雨露均霑，不按牌理出牌，在x86世界源自於Intel Core微架構「Merom」的「記憶體資料相依性預測功能 (Memory Disambiguation)」即為最好的範例，根據預測，承受後面的記憶體載入指令、可能需要前面載入執行結果的相依性風險，不等待前面回存 (Store) 指令完成工作，大膽的提前載入 (Load) 記憶體位址，以確保指令管線不停頓的順暢運轉。 一圖勝千言，直接引用Intel當年介紹Merom的簡報。原本Load4要等待Store3完成。
▲有了記憶體資料相依性預測功能，不等Store3，Load4就賭下去了。當然，如果賭錯了，後頭要收拾殘局的成本就非常的高，大約40個時脈週期就飛了，但看在賭對了就賺翻了的份上，硬著頭皮還要給他賭下去。
▲有沒有突然感覺到，這些處理器設計者好像都蠻「賭性堅強」？ 很不幸的，Intel剛剛好就是這群賭徒中，特別敢冒險的那位 (Intel其實在微架構設計上一直蠻激進的)，有時候還真心覺得夜路走多了真的會碰到鬼，的確不是騙人的，Google Project Zero就活見「鬼」了。 成本高昂的分頁表隔離 前一篇有提到透過分頁表管理虛擬記憶體的配置，需要權限保護的作業系統核心，與一般使用者的應用程式，實際上是會有可能混在一起的。以32位元Linux為例，理論上應用程式可以看到4GB的虛擬位址，但其實最上面1GB的屬於系統核心；32位元Windows也有類似的限制，1GB或2GB切給作業系統核心與驅動程式，所以應用程式只能使用到3GB或2GB。
簡而言之，應用程式的確有機會利用某些漏洞，存取本應不該被允許的系統核心資訊。 那你也許會問：既然如此，為何我們不堅壁清野，維護兩份獨立的分頁表，一份系統核心，一份使用者，不就功德圓滿了？ 但每次系統呼叫，都需要反覆切換分頁表並搬移大量的資料，尤其用來加速虛擬位址轉換實體位址的TLB (Translation Lookaside Buffer) 會一直「上沖下洗 (Flush)」，等於每次系統呼叫都要重建快取資料，想閃也閃不開，導致嚴重的效能損失，這也是為何主流作業系統都將敏感的系統核心資訊，安置在虛擬位址的高位，並透過將程式碼與資料「隨機性」的散布其內，以避免當某個漏洞被發現時，被用來「一招半式打天下」，難以採用通用手段危害作業系統的強固性。 但很不幸的，Google Project Zero的研究成果，終究還是將作業系統廠商逼回成本高昂的「隔離」手段，最起碼眼前的短期方案僅限於此，能否有更低成本的手段，還在未定之天。往好處想，無須系統呼叫的純運算工作，效能應該不會受到什麼影響，也許吧。 對x86處理器來說，問題就更大條了，兩份獨立的分頁表，意味著避開昔日16位元時代遺產「節區 (Segment) 記憶體定址」的「平面 (Flat) 記憶體模式」就此破功，對於那些早已「放生」老舊記憶體定址模式效能的新型x86處理器微架構來說，實在是不堪回首的嚴酷考驗，這就像一道旋轉們，你越積極的拋棄遺產讓微架構針對未來最佳化，你背後被老舊包袱狠狠集中的後座力也越大，所謂「牙膏擠了原來還能吸回去」，大概就是這麼一回事。 硬科技：被Intel處理器漏洞嚇傻前 科科們要先知道的事（下）
by 痴漢水球 2018.02.13 01:05PM
現在也差不多是各位科科們該好好瞧瞧Google Project Zero公佈的「幽靈 (Spectre)」和「熔斷 (Meltdown)」的時候了。 還是一句老話，一個簡單的比較表，總是勝過千言萬語不著邊際的廢話。
天底下所有的技術，終究都是為了解決人類碰到的問題，關於這兩個命名看起來很恐怖的攻擊手段，也自然可以用生活化的比喻來解釋。目前網路上已不乏諸多「文科生」的野人獻曝，同樣文組背景的筆者，參考了某些頗具創意的解釋，自己也來掰一個。 看來依然無解的「幽靈 (Spectre)」 小明每天固定都在同一間金拱門... M記... 算了，不重要，買一樣的漢堡，他的愛慕者小強也想知道他吃哪種漢堡，所以喬裝路人「尾行」在後，進行調查。 小明對收銀員說：「點和昨天一樣的」，然後就付錢拿走漢堡 (密碼) 閃人了。 小強接著就對收銀員講：「我要點和前面一樣的。(非法讀取)」 收銀員：「你不能窺探他人隱私！」，然後就把小強轟出去了。(被執行權限擋下，停止執行)」 隔天，小強就找了另一位幫手，跟在他的後面排隊 (旁路攻擊)。 小強在小明點餐時，一直高喊「我要點和前面一樣的。(非法讀取)」，然後就被轟出去了 (被執行權限擋下，停止執行)，但是廚房裡面做漢堡的廚師聽到了 (製造錯誤分支預測)，為了提昇工作效率，多做了一個漢堡丟到空蕩蕩的輸送台上 (預測執行錯誤的指令，將不該被存取的記憶體位址載入快取內)。 輪到幫手時：「我餓死了，我要點店內全部的漢堡，但是哪個最快就先給我。(旁敲側擊)」 最後幫手就拿到了和小明一樣種類的漢堡 (因為資料已經在快取內，讀取最快)，小強也就搞清楚小明吃的到底是什麼了，真是可喜可賀。至於小強有沒有塞給幫手足夠的漢堡錢，我們就不得而知了。 更糟糕的是，這奇計淫巧在Google引發大爆炸時，乍看之下沒有啥有效的處理方法，但後來Google又宣稱已經找出不傷害效能的完美解決之道，看來秘訣是「在廚房和櫃台中間，插入一位假裝廚師的中間人，或著弄出個假廚房，隔離兩者 (設置「陷阱 (Trap)」，讓預測執行跳到人畜無害的位址)」，無法直接騙到廚師。效果如何，我們可以繼續觀望。 「幽靈 (Spectre)」：透過欺騙手法，讓其他應用程式能進入記憶體內的任意位置存取內容，Intel AMD ARM都集體躺著中槍，現在就看Google公佈的「絕招」到底有沒有那麼神。 只有Intel獨享的「熔斷 (Meltdown)」 假設某位不良男子大學生想知道暗戀的對象在不在系學會，但對方和友人早已對他的痴漢行徑深感反感，根本寧願打死他也不讓他知道倒楣的女主角身處校園的何處，所以他就打電話去系學會問助教： 「請幫我查詢XXX (被騷擾的女主角) 在系學會幫忙的日程表，看看她是不是在系辦幫忙 (非法存取)。如果在的話，也請一併協助我有哪些科目已經快要被當了，需要我去跑系辦一個一個對教授磕頭跪算盤求Pass，這些可能需要請她幫忙講好話der。」 助教一時不察，先看了系學會義工的日程表，嗯，她的確正在系學會，然後又花了不少時間去查詢這在系上惡名昭彰無聊男子快要掛掉的科目。(預測執行) 但助教隨後突然反應過來：我沒事去幫這快被二一的痴漢幹嘛 (察覺侵犯權限)？於是就在電話的另一端回覆：「你去死吧，打死不讓你去騷擾XXX。」(被執行權限擋下，停止執行) 「那好吧，就請助教大人告訴我有哪些科目需要在教授前面跪算盤的？」(旁敲側擊) 因為助教已經花了不少時間查詢到這些資訊，而且這傢伙就算再該死，也總得有權知道自己是怎麼死的，所以就「你快被死當的科目總計有....」 (預測執行錯誤的指令，將不該被存取的記憶體位址載入快取內)。 通常要找出這些資料需要好幾分鐘，但助教很快就告訴你答案，代表她真的有幫你處理，足以推測倒楣的XXX的確正在系辦，恭喜他，這位不良男子大學生可以準備拔腿衝過去了。 這招也不限只找一個人，假如他不想看到女主角身邊的姊妹掏親衛隊礙事，他也可以設定一份名單 (索引範圍) 和不同的衍生條件，去嘗試推敲出系辦現在到底有哪些討厭鬼，只是助教可能會先想砍死他，像「你現在給我來系辦，我保證不會打死你 (我並沒有違反我不殺的誓言，只是把你活活打個半死)」之類的。 這招的解法也很簡單：聘請另一位根本不認識系上同學的臨時工，專職負責查學生成績 (隔離分頁表)，讓助教連「預測執行」的機會都沒有，但代價就是要多花錢僱用另一個人，助教要查成績時也只能請他查，提高時間成本。 「熔斷 (Meltdown)」：打破應用程式被禁止任意存取系統記憶體的保護機制，讓應用程式也能跟著存取到記憶體內的內容，目前僅Intel受害，透過隔離分頁表可以處理，只是成本很高。 面對排山倒海的媒體報導，莫驚慌、莫緊張、莫害怕 世上多數媒體的基因總是內建惟恐天下不亂的本能，但我們回到原點，這些利用處理器預測執行缺陷的攻擊手段，真的如部份媒體繪聲繪影般的可怕嗎？筆者覺得：不會。
- 這都是「本地端」的攻擊手段，並不是駭客遠在地球的另一端按下按鍵、你的電腦就瞬間自爆的遠端攻擊。
- 現階段只有資料被不當讀取的風險 (讀出來也不見得有用)，但不會破壞現有運行中系統的強固性。
- 成功的攻擊都需要搭配大量的「助攻」，現實世界不太可能出現如此理想的環境。講的更白一點，無論是幽靈還是熔斷，其實際危險性恐怕不會比十多年前Intel HyperThreading旁路攻擊的安全性事件嚴重到哪裡去。
目前最積極介入此事的Google和Amazon，其最擔憂的莫過於資料中心內虛擬機器Hypervisor被用戶端作業系統偷讀重要資料、導致影響虛擬機安全性這檔事，對人類最大的衝擊也就是數以萬計的伺服器要安裝修正檔並重新開機，進而衝擊雲端服務的總體效能吧。手機的話，再看看。總之，靜觀其變即可，為了這種蠢事而驚呆，不是站在時代浪頭的科科們該有的作為。 但這次所有晶片廠商的反應與危機處理，特別是首當其衝的Intel，過程和態度是否「社會觀感不佳」，那又是另外的故事了。不過，難道你不會好奇，既然Intel AMD ARM的非循序執行處理器都中槍了，難道IBM Oracle Fujitsu的，就能保證全身而退嗎？ 至於這兩種攻擊的根除之道，不學無術的筆者已經想到了完美的解決方案，但如同費瑪最後定理，礙於文章字數限制寫不出來，我們下次有機會再好好談談，科科。
