阿里云工程師張獻濤深度解析熱修復xen漏洞

2015 年 3 月，開源軟件 Xen 接連發布了 6 個安全漏洞，從 XSA-119 到 XSA-113，稱由于 Xen 存在部分漏洞，建議所有相關的服務器進行重啟來修復這些漏洞。其中對于公有云業務造成潛在風險最大的漏洞是 3 月 10 號公開的，從理論上來說，這個漏洞會造成個別精心設計的指令提權，從而導致客戶數據泄密。

我們先通過百度百科了解下 Xen 的定義：

Xen 是一個開放源代碼虛擬機監視器，由劍橋大學開發。它打算在單個計算機上運行多達 100 個滿特征的操作系統。操作系統必須進行顯式地修改（“移植”）以在 Xen 上運行（但是提供對用戶應用的兼容性）。這使得 Xen 無需特殊硬件支持，就能達到高性能的虛擬化。 

Xen 在云計算行業為人熟知，由劍橋大學開發。使用者包括亞馬遜 EC2、阿里云 ECS、IBM SoftLayer、Linode 及 Rackspace Cloud 等主流廠商。

目前來看，多數云計算廠商采用了服務器重啟的解決方式，但這樣將中斷云計算服務，使得客戶業務無法開展。這個漏洞是什么？通常修復有哪些辦 法？……另外，國外多數重啟、阿里云在公布前已熱修復，緣何如此，讓我們聽一下阿里云資深專家、主導阿里云下一代虛擬化架構的設計與研發工作張獻濤博士的 回答。

以下為正文： 

1. Xen 漏洞是什么？一般會有哪些漏洞類型？此次事件中，Xen 漏洞有哪些？會對服務器帶來哪些影響？影響有多深？對用戶的業務有哪些影響？

張獻濤：說到 Xen 漏洞，不得不先介紹一下 Xen Hypervisor 項目。Xen 項目是劍橋大學發起的一個開源 Hypervisor 軟件，是實現云計算虛擬化的基礎，現在被亞馬遜、阿里云、rackspace 等公司作為公有云的基礎系統軟件，承載著全球大部分的公有云計算業務。Xen 安全漏洞是指 Hypervisor 自身出了安全問題，可能會造成數據泄漏風險，漏洞披露由 Xen 安全團隊會負責。從披露流程上來說，Xen 安全團隊會在公布漏洞前，提前 10-14 天發給全球的關鍵公司做預披露相關的動作，這些公司都簽訂了嚴格的 NDA 協議，以留出時間給這些公司做線上系統安全漏洞的修復，阿里巴巴是國內唯一一家進入 Xen 安全漏洞預披露列表的公司，因此阿里云可以提前得之漏洞的相關信息，然后做相應的安全防范動作，比如重啟機器或者熱修復漏洞。

近期 Xen 接連發布了 6 個安全漏洞，從 XSA-119 到 XSA-113，但能對公有云業務造成潛在風險的漏洞只有 3 月 10 號公開的這個，因為從理論上來說，這個漏洞會造成個別精心設計的指令提權，但從目前分析來看，僅僅是理論上的可能，漏洞被利用的難度非常大。但大家也知 道，安全問題是一個道高一尺魔高一丈的博弈過程，因此只要是理論上的風險，對于公有云廠商來說，都是必須是要修復的。一旦這個漏洞在公開前不被修復，理論 上會造成數據泄漏的潛在風險。

最后，對于一個龐大的軟件系統來說，出安全漏洞是必然的事情，關鍵是否能否在漏洞被公開前快速修復。這次漏洞波及全球的主流云計算運營商，但負責人的云運營商都會從數據安全角度出發，在漏洞公開前修復掉。

2. 修復 Xen 漏洞的一般方法有哪些？

張獻濤：Xen 作為一個底層 Hypervisor 軟件，為了安全考慮，它被設計成一個安全域。我們知道，如果想修復一個系統軟件漏洞，必須能夠訪問系統軟件所用到的內存，否則修復無從談起。就像我剛剛提 到的，Xen Hypervisor 被設計成一個安全域，所謂安全域，它的內存是 Xen 的控制域 Dom0 無法訪問的，那么熱修復最大的難度就在這里。一旦這個難題解決不了，就不可能最熱修復，只能老老實實打上補丁冷重啟讓補丁生效，比如這次其它廠商采用的修 復方法。阿里云在虛擬化方面有比較深厚的技術積累，解決了這個業界難題，實現了熱修復，并且這個修復過程采用了極其精細化的設計，讓客戶的虛擬機徹底無感 知，最后的結果也是未造成一臺 VM 宕機，未影響用戶的業務。因此，從這個角度來看， 修復此類漏洞的方法有兩種，冷啟動修復和熱修復。從對用戶影響程度來說，冷啟動會造成用戶業務數分鐘服務不可用，而熱修復做到用戶業務對修復過程無感知。

3. 阿里云采用的方法是什么？具體做法的步驟是？是否會對用戶產生影響？

張獻濤：就像我剛才談到的，阿里云采用的是熱修復過程，首先，突破了從控制域 Dom0 不能訪問 Xen Hypervisor 內存的限制，在確保上層用戶業務不受影響的前提下，動態替換 Xen Hypervisor 中有問題的指令。這個過程說起來相對簡單，但真正實施起來，過程及其復雜，需要各方面都比較精準的控制。

4. 阿里云是如何想到熱升級的方法？為何其他云服務商不會進行熱升級？技術能力不夠還是其他原因？熱升級需要哪些門檻？

張獻濤：就像我剛才談到的，阿里云在虛擬化領域有較深厚的技術積累，當然愿意為客戶利益最大化挑戰技術上面 臨的巨大困難。從客戶角度說，沒有一個用戶愿意自己的業務被中斷數分鐘。從阿里云角度來說，客戶利益永遠是第一位的，只要能幫用戶從技術上解決免受損失， 那么阿里云的技術團隊將義不容辭去承擔。

對于您的第二個問題，我想談談云服務提供商和用戶簽訂的服務協議，從協議中都可以看出，每年是允許一些停機發生的，因為軟硬件系統總是要停機維 護的，比如做修復漏洞之類的事情。冷啟動沒有任何技術挑戰，在滿足協議的基礎上可以選擇重啟機器，但我們要看到一旦這樣做勢必會影響到客戶的業務，有些甚 至是致命的影響。要想解決 Xen Hypervisor 熱升級，面臨的挑戰非常多，真正能解決這個問題的人在全球范圍內都是屈指可數的，因此幾乎所有公司都不具備熱修復 Hypervisor 的能力，所以沒辦法熱升級。

談到熱修復門檻問題，我也想拿 Xen Hypervisor 熱修復過程和 Linux 內核熱修復過程做對比，從分析中就應該可以看出門檻在哪里。

首先，Linux 內核是很容易支持熱修復的，并且主流公司也都有自己的熱修復實現，新的 Linux 內核都原生支持，方法也相對簡單直接，把問題的函數替換掉就行了，基本上沒什么門檻。其次，從修復過程上看，Linux 系統的管理員可以訪問系統的所有內存，并且內核天生支持模塊插入，在這兩個前提下，一旦某個函數出現漏洞，很簡單地用C語言寫個新的函數以模塊形式插入內 核，然后把所有對有問題函數的訪問跳轉到新的函數就可以修復了。

然而，Xen Hypervisor 作為一個安全域，它不允許任何用戶，甚至是云運營商管理員訪問器器內存，并且為了安全考慮，不支持任何的模塊插入。缺失這兩個條件的情況下，要想熱修復 Xen Hypervisor 其難度可想而知。如果想做熱修復，就要解決云運營商管理云訪問 Hypervisor 內存的問題，如何計算有問題指令的物理地址問題，動態地修復有問題的機器指令的問題以及修復過程讓用戶業務無感知的問題。對于第一個最難的問題，在 CPU 不能訪問內存的情況下，我們另辟蹊徑利用設備 DMA 去讀寫內存，這個方法需要精準的操作，因為一個異常的 DMA 請求會導致 Hypervisor 內存污染或者設備異常，最終導致物理機宕機。具體的細節，我們考慮在下個月舉行的 QCON2005 會議上披露。

5. 亞馬遜也采用了熱升級的方式，為何仍有 0.1% 的服務器需要重啟，而阿里云的服務器則全部不會受到影響？

張獻濤：熱修復 Hypervisor 技術門檻很高，各種各樣的軟硬件組合都需要考慮，問題比較復雜，不是所有的公司都能解決所有問題。阿里云第一版修復方案也只能解決了 99.97 %左右的客戶，但我們沒有滿足于這個成績，而是連夜分析方案的缺陷，分析問題所在，最終達到了 100% 用戶不用重啟的目標。

6. 在熱升級過程，是否會對阿里云的其他產品產生有影響？阿里云做了哪些預案來避免用戶服務受到影響？

張獻濤：這個修復過程對用戶的業務完全無感知，不會對用戶的業務造成任何影響，更不會對阿里云其它產品造成 影響。就像我們公告中說的一樣，我們雖有 100% 的修復能力和信心，但線上環境也在千變萬化，為防止萬一出現意外，從團隊組織上，我們組成了故障應急團隊，修復過程中一旦出現問題，馬上和客戶溝通，降低 業務受影響的程度。從修復節奏上來看，我們采用了全自動、逐臺機器修復的策略，一旦出現意外，只會影響一臺機器，修復會馬上停止，然后讓技術人員分析問 題，還有其它一些應急預案，我這里就不詳細說了。

結果大家也看到了，我們的修復是平滑的，對用戶業務無感知的，沒有接到一個由于修復導致的問題工單。當然，我們的應急預案也沒有用上。

7. 阿里云也提出了風險賠償預案，具體賠償細則有哪些？

張獻濤：阿里云一直秉承百倍賠償的原則，具體是阿里云用戶的業務由于我們的系統問題導致中斷，阿里云將提供 100 倍的故障時間賠償，所有賠償會在兩個工作日內處理完成。當然，這個賠償原則也適用于這次系統的熱修復，從這次的公告中也可以看出來。

8. 在阿里云的公告中，需要升級 ECS 和 VPC，是否是針對此次 Xen 漏洞進行的？為何升級過程中，用戶不能進行一些列的操作？

張獻濤：您提到的這個公告和這次 Hypervisor 熱修復沒有任何關系，我們 3 月 9 號針對熱修復發布了公告，但這個公告是告訴用戶我們已經找到了應對方案，修復過程對他們業務無影響的一個通知。阿里云也一直秉承客戶利益第一的原則，我們 的產品會做快速的迭代，為用戶提供更多的增值服務。您提到公告中 ECS 和 VPC 升級是對現有系統功能的改進和擴展，是為用戶提供更加好用戶體驗的一次升級。雖然沒辦法做到用戶無感知，比如需要關閉售賣系統一段時間，但不會對用戶正在 運行的業務造成干擾，并且發布過程也一般會選在夜間的業務低峰進行。同時提前發公告出來，讓用戶有足夠時間提前做預案。

9. Xen 是開源軟件，開源組織重視程度不夠，更新也少，阿里云使用了 Xen，是通過哪些技術和方法來保證安全性？

張獻濤：Xen 開源軟件誕生于 10 多年前，被大量公司所采用組建公有云和私有云的解決方案，并且是 Type-1 的 Hypervisor，其安全性不容置疑。很多業界主流公司都是它的開源貢獻者，比如 Intel、Citrix、AMD IBM、Redhat、Oracle 以及 Novell 等公司都投入了大量的人力物力進行開發。從這個意義上來說，不能說重視度不夠，而是系統太過底層，真正能理解清楚的公司和個人都不多。

阿里云誕生于 2009 年，Xen 作為公有云的組建方案那個時候已經相當成熟，這些年阿里云投入了大量的精力在云安全領域，包括代碼漏洞分析、漏洞掃描，引入一些業界 Xen 方面的頂級專家，以及保持和 Xen 安全團隊良好的互動關系等，這些措施保證了阿里云在面對漏洞時可以預先發現，預先修復，提前預防。

我想再強調下，復雜的系統都會有安全漏洞，就像我們用的 Windows 隔三差五就會要求安全更新一樣，關鍵是對于漏洞否能提前發現、提前知道、提前修復。如果能做到，這就是核心競爭力。

10. 去年 9 月，也同樣因為 Xen 漏洞，導致很多云服務商停機維護，為何對阿里云沒有影響？這樣的漏洞，阿里云一般是怎樣避免的？

張獻濤：去年 9 月底，Xen 確實爆發了一個高危漏洞 xsa-108，幾乎所有的基于 Xen 的云服務商都做了停機維護。我記得比較清楚，某公司還寫了一篇文章分析 Xen 在安全漏洞上上演了帽子戲法，但它分析的是 xsa-105，xsa-106 以及 xsa-107，壓根沒提 xsa-108，借用比較時髦的話所，他們跑偏了。

那么我們來分析下 XSA-108 到底是一個什么樣的漏洞，其實這個漏洞只要能突破剛才我提到的熱修復挑戰中的第一個就可以了，就是解決運營商管理員能訪問 Hypervisor 內存的問題，而這一難題我們去年 7 月份就解決了。然后，通過技術手段修復掉內存中的有問題的兩個字節就行了，但顯然去年這些云運營商還都不具備這個能力。

對于此類安全問題的問題，特別是涉及到數據安全的問題，阿里云一直放在最高優先級進行分析，比如去年 11 月份的時候，Xen 安全委員會提前把 XSA-112 預發布給我們，并且說會造成數據風險，我們的專家分析 Xen 代碼相關代碼邏輯后，發現這個描述是不準確的，及時給了 Xen 安全團隊反饋，他們也認可我們專家的分析，直接把 xsa-112 降級到存在 DDos 風險。

最后，我還想說一句，云計算業務數據安全可靠絕對是最重要的事情，作為國內云計算的領頭羊，阿里云一直把客戶利益，客戶數據安全放在首要的位置。

張獻濤簡介：博士，阿里云資深專家，主導阿里云下一代虛擬化架構的設計與研發工作。畢業于武漢大學，獲信息安全博士學位，在國內外發表虛擬化相關論文多篇以及擁有多項美國專利。

在加入阿里云之前，他供職于英特爾亞太研發中心虛擬化部門，有 9 年的虛擬化項目經驗。2011 年，他主力研發的 HAXM 虛擬機加速器為 Android 系統模擬器插上了飛翔的翅膀，性能提升數倍，開發效率倍增，惠及數以百萬的 Android 應用開發人員，多次受到 Google 公司贊揚，并因此獲得英特爾最高成就獎(IAA)。

研究方向涉及服務器虛擬化，客戶機虛擬化以及移動虛擬化多個領域。在開源虛擬化項目 Xen、Linux/KVM 等社區貢獻頗多，曾擔任 Xen 項目子系統的 Maintainer，并為 KVM 虛擬化項目增加了跨平臺支持，獨立實現了 KVM 在 IA64 平臺的支持，并擔任 KVM/IA64 項目的 Maintainer。