热修复Xen高危安全漏洞
  深度解析阿里云Hypervisor
 Ho+ix技术

旭卿（张献涛） Email: xiantao.zxt@alibaba-inc.com

自我介绍

• 张献涛，花名旭卿，毕业于武汉⼤大学，获信息安全博⼠士学位。

• 多个开源虚拟化项目Xen、Linux/KVM的主要贡献者。曾担任 Xen项目⼦子系统的Maintainer，并为KVM虚拟化项目增加了跨 平台支持。独立实现了KVM在IA64平台的支持，并担任Linux 内核KVM/IA64项目的Maintainer。

• 供职于阿里巴巴集团，任阿里云资深专家、虚拟化技术总监， 主导阿里云下⼀一代虚拟化架构的设计与研发⼯工作。

• 加⼊入阿里巴巴之前，供职于英特尔亚太研发中⼼心虚拟化部门， 有9年的虚拟化项目经验，先后担任⾼高级⼯工程师、主任⼯工程师、 虚拟化架构师等职位，并获得英特尔最⾼高成就奖(IAA)。ﾊ

• 在国内外发表虚拟化相关论⽂文多篇以及拥有多项美国专利。

Agenda

• Xen
 Hypervisor的相关知识
  • Hypervisor
 Ho1ix的技术挑战
  • 解析XSA-­‐123高危漏洞
  • 回顾XSA-­‐123的应急过程
  • 总结和展望
 

Xen
 Hypervisor相关知识

Xen Hypervisor 发展历程



• 由剑桥大学计算机实验室发起



• Xen是公有云云计算的重要基石



• Type-1开源Hypervisor软件



– 代码开源、社区活跃、多家大



• 2003年，发布了第一个公开版本



公司参与项目研发



– 仅支持Para-virtualized 虚拟机



– 被亚马逊、阿里云、 Linode



• 2005年底，Xen 3.0发布



Rackspace、Softlayer，公有 云计算公司采用



– Intel/AMD添加对VT-x/AMD-V支持



– 支撑全球过半的云计算业务



– 完成Full-virtualization 支持



• Xen安全问题



• 2007年，Citrix 收购XenSource



– 由Xen社区的专门安全团队负责



– 标志着Xen全面商业化的开始



– 安全漏洞会提前10-14天通知Pre-



• 2010年，发布Xen-4.0

– 全面支持Linux内核的PVOps接口

• 2015年1月17日，发布Xen 4.5



disclosure List成员 – 阿里云是国内唯一一家进入Pre-

disclosure list的公司 – http://www.xenproject.org/security-



– 最新的一次稳定版发布



policy.html

Xen 安全漏洞概要



• 总共发布125个安全漏洞

– http://xenbits.xen.org/xsa/ – 其中xsa-108和xsa-123是高危漏洞

• XSA-108

– 2014年10月1日公布 – 可导致Hypervisor内存泄漏给客户机 – 可导致32位Hypervisor Crash – 导致主流云计算运营商大规模

重启服务器

• XSA-123

– 2015年3月10日公布 – 可以导致客户机指令提权 – 影响全球的基于Xen的公有云运营商 – 造成多家云运营商重启所有物理修复



140
  120
  100
 

80
  60
  40
  20
 

0
 



系列

系统软件安全漏洞统计对比



1800
  1600
  1400
  1200
  1000
 

800
  600
  400
  200
 

0
 



1005
 

599
  MS
 Windows
 



近五年多的数据分 析(2010-­‐2015)



121
  555
  Linux
 



高危安全漏洞 普通安全漏洞

929
 
  Xen
 



Xen的安全性还是有保证的！

Xen安全漏洞的修复方式



冷补丁方式 热补丁方式



打补丁后重启服务器生效 全部客户VM必须Shutdown 所有VM会被中断10-30分钟 多半Xen的运营商在使用

动态应用补丁修复漏洞 客户VM不用重启或关闭

客户VM对修复过程无感知

阿里云掌握热补丁技术

Linux内核Hotfix技术



• 业界较成熟的内核Hotfix方案

– Ksplice by Oracle



Pre-­‐Defined
 接口



– Kgraft by Suse – Kpatch by Redhat



允许插入内核Module



– Alihotfix by Alibaba



有权访问内核内存



– Linux 4.0 原生支持内核Hotfix

• 基本原理（Kpatch为例）



函数级别的替换



– 基于函数动态替换技术 – 新函数会以模块内函数的形式链接入内核



易确定被修复函数的位置



– 旧函数的第一个指令改成强制跳转指令指向新函数



– 在替换过程中需要暂停所有CPU，切到一个内核线程并关闭本地中断。



– 刷新指令缓存，重新让CPU恢复执行



与内核Hotfix相比，Xen Hypervisor Hotfix技术挑战极大

Hypervisor
 Ho1ix及挑战

Xen Hypervisor 底层架构



Userspace Kernel



IAAS
  控制系统
 

分布式
  存储

管理员 可访问 的区域



Dom0



Tapdisk2



Libvirt Xend



Blktap2



Blkback



Netback



HVM

Ne1ront Blkfront
 



Xen
 Hypervisor

Intel
 Hardware
 
 with
 VT-­‐x,
 ETP,
 SR-­‐IOV等

Hypervisor Hotfix的挑战

Xen是Type-1 Hypervisor，内存被严格隔离 Xen Hypervisor被装载的地址是动态的 Xen Hypervisor不支持Module插入 无法进行源码级别的Hotfix 线上系统无法新增Hotfix接口

如何访问Hypervisor内存？



Dom0



HVM Domain



HVM 内存



Dom0 CPU



Guest Mode Host Mode



Kernel



Kernel



Xen Hypervisor



系 统 Dom0 内 内存 存

Xen内存



Xen Hypervisor 内存访问安全模型

Dom0无法通过CPU访问Xen hypervisor内存



Dom0可通过设备DMA方式访问 Xen hypervisor 内存



设备

通过DMA访问Xen内存

• 如何构造DMA请求

– 不能随意构造不存在的DMA请求 – 截获一个特定DMA请求，修改DMA的目的地址，以及要写入的数据 – 选取哪个硬件设备， 网卡 ？硬盘？其它？

• 截获DMA请求的方法

– DMA请求的内存管理来自于两个函数 • dma_map_sg_attrs/dma_unmap_sg_attrs

– 利用内核Hotfix替换Dom0内核的这两个函数 – 在新的map_sg/unmap_sg中加入过滤逻辑 – 筛选出特定的DMA请求，修改DMA目的地址



利用硬盘DMA请求Hotfiﾞx Hypervisor 内存

正常的文件读操作流程

用户态分配内存buffer准备读⽂文件 用户态发起read系统调用

内核态把buffer挂⼊入map_sg_list

内核态调用驱动接⼝口触发DMA操作

内存

Hotfix时文件读流程

用户态分配内存buffer准备读⽂文件

用户态把buffer地址以及hotfiﾞx信息传⼊入内核

用户态发起read系统调用

内核态把buffer挂⼊入map_sg_list

过滤DMA请求，修改DMA目的地址

内核态调用驱动接⼝口触发DMA操作



Hypervisor 内存



内存

计算修复代码的地址

• 设备DMA只能使用物理地址

– 有别于CPU使用虚拟地址访存

• Hypervisor 加载过程

– Hypervisor首先会被Load到低端地址 – Hypervisor会把自己Relocate到高端地址 – Hypervisor 高端地址的计算由系统的E820表决定

• Hypervisor Hotfix 物理地址计算公式

– 假设需要fix的Hypervisor 函数 地址为VA – Hotfix点在Hypervisor内核实际偏移则为 PA’=VA & 0xffffff – 获得4G以下最后一个E820表项（>16M）

• BIOS-e820: pa_start – pa_end (usable) – 则要Hotfix函数的物理地址为：

• PA= f (pa_end, PA’)

能否获得机器的E820 Memory Map是修复的关键

XSA-­‐123
 漏洞分析

XSA-123

– 2月28日，安全团队发布给Pre-disclosure List成员 – IMPACT
 

======
  A
 malicious
 guest
 might
 be
 able
 to
 read
 sensi]ve
 data
 rela]ng
 to
 other
  guests,
 or
 to
 cause
 denial
 of
 service
 on
 the
 host.
 Arbitrary
 code
  execu]on,
 and
 therefore
 privilege
 escala]on,
 cannot
 be
 excluded.
  
  
 


 

2015年3月10 12：00 公布

各家云计算公司响应

• AWS：
 

• Rackspace:
  • Aliyun:
 

冷修复前后汇编代码对比

修复后机器码被编译器优化严重

分析、解决过程

• 通过分析汇编修复相关逻辑

– 18000多条指令，复杂性较高 – 编译器优化导致难度增加 – 需要找到足够的可用空间承载新增代码


 


 

手工修复后的机器码对比

生成机器码补丁

• Seg0.10
  
 
 

• Seg1.50
  
 


 
 

把对应的机器码写入文件生成Patch

机器码补丁注入流程

• 流程：

① 确定要注入代码的物理地址 ② 从Hypervisor读出相关代码的机器码(4K) ③ 和期待的Pattern比较是否一致 ④ 如一致，把机器码Patch和读出代码Merge，生成新

的Patch ⑤ 暂停所有VM运行 ⑥ 把新的Patch通过DMA写回到Hypervisor ⑦ 恢复所有VM运行

VM被暂停的时间越短越好

压力测试结果

• 软硬件情况

– 抽调一个演练集群 – 部署线上相同的软件环境

• 实验一：手动编辑hypervisor代码测试

– 通过16进制编辑器静态修复 – 24小时压测未发现问题

• 实验二： 热修复压力测试

– 每台连续做修复动作100次 – 超过数万次实验 – 无宕机发生 – 所有被测试机器均修复成功

线上系统修复结果

线上机器全部修复 未引发⼀一例宕机 未引发⼀一例⼯工单

XSA-­‐123应急过程回顾

漏洞修复应急过程

2月28日收到Xen安全团队通知 3月2日上午漏洞评估完成：高危 3月2日下午确定重启和热修复两个方向 3月5日晚第一版热修复方案Ready 3月6日晚第二版热修复方案Ready

3月6日晚发布到部分机器中 3月9日发布挂出公告开始发全集群

3月10日漏洞公开前发布完成

紧密的团队协作非常重要！！



开发 运维 测试 安全 技术服务 产品

总结和展望

• 云计算业务中安全是头等大事

– 数据安全是高压线

• 完善的安全问题处理预案

– 响应、执行也需要及时和迅速

• 热修复技术对安全运营至关重要

– 重启修复对客户的业务影响不可估量

• 多团队协作尤为重要

– 技术重要，但强大的团队协作更重要

Xen依然是世界上最安全的系统软件之一！！

Q&A

招聘进行……
  
 Email:
 xiantao.zxt@alibaba-­‐inc.com

@InfoQ
 



infoqchina