阿里云工程师张献涛深度解析热修复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。