CPU漏洞頻現(xiàn)，如何不在性能和安全之間二選一？

盡管Meltdown和Spectre兩大CPU漏洞發(fā)生在2018年年初，但近半年的時間并沒有讓其帶來的影響完全消除。一是因為這兩個漏洞本身帶來的影響足夠大，甚至可以用掀起IT界的“地震”來形容；二是自從1月份以來，新的CPU漏洞不斷被曝出，不論是英特爾、AMD、ARM、Power等無一幸免，“下一代Spectre”、“Meltdown-Spectre變種”等字眼不斷出現(xiàn)在各大科技媒體頭條。

如此形勢下，如何降低甚至消除Meltdown和Spectre帶來的影響，成為廣大用戶尤其是企業(yè)級IT用戶討論的熱點。在芯片供應(yīng)商、OS廠商、應(yīng)用提供商已經(jīng)紛紛發(fā)布針對漏洞補丁的今天，為什么Meltdown和Spectre還能引發(fā)討論？實際上，這里存在一個不可消除的矛盾點，也就是在安全性和性能之間如何選擇。

修補漏洞對應(yīng)用性能造成的影響

為了不對安全帶來影響，解決Meltdown和Spectre漏洞最直接的方法就是打補丁。然而這一方法卻導(dǎo)致應(yīng)用性能顯著下降，這也是英特爾等公司備受詬病與壓力的原因。

這里有必要再提下Meltdown和Spectre漏洞產(chǎn)生的原因，其中亂序執(zhí)行（Out-of-order Execution）、推測執(zhí)行（Speculative Execution）和分支預(yù)測（Branch Prediction）三大CPU采用的技術(shù)是造成漏洞產(chǎn)生的根本原因。簡單理解，Meltdown破壞了位于用戶應(yīng)用和操作系統(tǒng)之間的基本隔離，導(dǎo)致程序可能訪問其他程序和操作系統(tǒng)內(nèi)存，從而產(chǎn)生敏感信息會被竊取的可能性。Spectre則是破壞了不同應(yīng)用程序之間的隔離， 處理器會推測在未來有用的數(shù)據(jù)并執(zhí)行計算，當(dāng)這些數(shù)據(jù)被需要時可立即使用。但是處理器沒有很好地將低權(quán)限的應(yīng)用程序與訪問內(nèi)核內(nèi)存分開，這意味著攻擊者可以使用惡意應(yīng)用程序來獲取應(yīng)該被隔離的私有數(shù)據(jù)。

然而為了應(yīng)對這一問題，目前的補丁技術(shù)只能是使用軟件來降低黑客利用預(yù)測執(zhí)行來入侵內(nèi)核內(nèi)存，主要的補丁是將每個進程的內(nèi)核地址和用戶地址共享映射表改為內(nèi)核地址和用戶地址各有自己獨立的映射表PGD（Page Global Directory），這樣一來在用戶空間根本沒有內(nèi)核空間的映射表，即使漏洞存在，黑客也不會從內(nèi)核獲得數(shù)據(jù)。但是這樣的代價就是每次系統(tǒng)調(diào)用或者中斷發(fā)生時都需要切換映射表，這無疑會影響應(yīng)用的性能。

因為Meltdown和Spectre主要是產(chǎn)生于用戶態(tài)和內(nèi)核態(tài)交互之間，黑客利用用戶態(tài)和內(nèi)核態(tài)之間的短暫未保護狀態(tài)的瞬間竊取信息。所以從應(yīng)用角度來看，如果應(yīng)用有很多用戶態(tài)和內(nèi)核態(tài)之間的交互，顯然受漏洞影響就比較大。如果應(yīng)用在內(nèi)核態(tài)和用戶態(tài)之間的操作比較少，它受漏洞的影響也就比較小。

從對于業(yè)界應(yīng)用的影響來看，英特爾確認性能損失取決于工作負載。比如常見的OLTP應(yīng)用，為了提升效率，往往需要將資料緩存到內(nèi)存中，所有的OLTP操作都是由內(nèi)核來完成，如果不使用Meltdown和Spectre的補丁，應(yīng)用很容易被黑客攻擊；如果使用補丁，根據(jù)第三方測試數(shù)據(jù)，應(yīng)用性能可能會有8% 到19%的損失。對于一些內(nèi)核層和用戶層很少通訊的應(yīng)用來講，性能影響就會小些甚至不受影響。

根據(jù)業(yè)內(nèi)分析發(fā)現(xiàn)，應(yīng)用修復(fù)所產(chǎn)生的系統(tǒng)性能影響如下所示：

? 模擬常見企業(yè)和云工作負載的基準(zhǔn)測試顯示， 性能降低 2% 至 5%。
? 數(shù)據(jù)庫分析和Java VM 基準(zhǔn)測試顯示，性能降低 3% 至 7%。
? 在線交易類的 OLTP 基準(zhǔn)測試顯示，性能降低 8% 至 19%。
? 使用了支持加速器技術(shù)（包括 DPDK、RDMA 等） 網(wǎng)卡的應(yīng)用性能退化微乎其微，甚至完全不受影響。

（圖）修復(fù)后的不同類型應(yīng)用的平均性能損失

所以，總體看來，使用犧牲性能的方式來解決問題，無疑不是一個好的方案。

如何不在安全與性能之間二選一

由于Meltdown和Spectre問題來源于CPU，最根本的解決辦法就是改變CPU從內(nèi)存和磁盤讀取數(shù)據(jù)的方式，實現(xiàn)既不損失性能又有安全保障。但是這是一個很艱巨的任務(wù)，很難在短期內(nèi)實現(xiàn)。

Mellanox公司亞太及中國區(qū)市場開發(fā)高級總監(jiān)宋慶春在接受至頂網(wǎng)采訪時表示，“當(dāng)前的最佳解決方案就是盡量做到CPU Offload，減少內(nèi)核層和用戶層之間的溝通， 比如使用RDMA技術(shù)來Bypass CPU，使用NVMe over Fabric Offload來將CPU操作的內(nèi)核拷貝跳過，使用GPU Direct RDMA技術(shù)跳過GPU內(nèi)存和CPU內(nèi)存的拷貝等。另外使用網(wǎng)卡硬件來做應(yīng)用和應(yīng)用之間的安全隔離來避免使用CPU來做軟件隔離，也是預(yù)防漏洞的有效方法之一?！?/p>

所以，解決Meltdown和Spectre問題的關(guān)鍵就是減少CPU和應(yīng)用的溝通，RDMA和智能網(wǎng)卡做的就是讓CPU盡量只做計算，所有通訊和安全的操作由網(wǎng)絡(luò)來做，從而切斷黑客訪問應(yīng)用的途徑。此外，還包括DPDK技術(shù)，“它們實際是把原來由內(nèi)核操作的很多工作放到用戶態(tài)去做，這樣很多操作就跟內(nèi)核態(tài)沒有關(guān)系了。通過在用戶態(tài)之間建立應(yīng)用和應(yīng)用之間隔離，避免和內(nèi)核態(tài)之間的交互，來降低這些漏洞帶來的風(fēng)險?，F(xiàn)在RDMA技術(shù)已經(jīng)被廣泛應(yīng)用到了各種各樣的應(yīng)用當(dāng)中，從很多采用RDMA的應(yīng)用來看，可以看到它被Meltdown和Spectre這兩個漏洞影響的機會非常小，而且對性能的影響非常低，甚至做到?jīng)]有影響?！?宋慶春說。

所以，這在另一個層面又回到了卸載技術(shù)與加載技術(shù)的爭論。卸載技術(shù)尋求克服CPU的性能瓶頸，主要方式是對在集群內(nèi)移動的數(shù)據(jù)執(zhí)行各種網(wǎng)絡(luò)功能以及復(fù)雜的通信操作，如協(xié)同操作和數(shù)據(jù)聚集操作。以Mellanox為代表的網(wǎng)絡(luò)廠商推出了卸載技術(shù)（如 RDMA 和 DPDK）， 將處理TCP/IP和存儲堆棧的重任轉(zhuǎn)移至網(wǎng)絡(luò)適配器，緩解主要系統(tǒng)處理器的壓力。這樣可以提升性能，并緩解了修補Spectre 和Meltdown 后通常造成的性能損失。

主流應(yīng)用享受RDMA帶來的安全與性能提升

現(xiàn)在包括計算、存儲、大數(shù)據(jù)、虛擬化等諸多市場上的主流應(yīng)用已經(jīng)應(yīng)用RDMA、DPDK等Kernel Bypass的技術(shù)來規(guī)避和降低Spectre 和Meltdown帶來的影響，并提升性能。

宋慶春指出，在存儲方面，無論是對象存儲的CEPH、塊存儲的iSCSI、文件存儲的Cluster File System以及NVMe over Fabric等等，都已經(jīng)有RDMA的版本。此外，在各種人工智能的主流框架中，包括TensorFlow、CNTK、Caffe2、MXNet、PaddlePaddle，以及商湯科技、Face++等公司的私有框架，也都有了基于RDMA的實現(xiàn)。還包括大數(shù)據(jù)處理的主流框架Spark以及虛擬化方面，都諸多應(yīng)用到了RDMA或者DPDK的技術(shù)，以CPU Offload減少內(nèi)核層和用戶層之間的溝通，預(yù)防漏洞的同時，同時性能得到顯著提升。

小結(jié)

所以，以CPU Offload如RDMA 和 DPDK的方案帶來的明顯價值是讓用戶不用在安全性和在應(yīng)用性能之間做權(quán)衡。以往來說，在面對Spectre 和Meltdown時，如果選擇性能不打補丁，就可能帶來安全隱患的影響。如果選擇打補丁，則導(dǎo)致應(yīng)用性能受到影響。

其實，可以不必在性能與安全之間二選一，你有一個更好的選擇！

生成海報

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責(zé)任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。