打造完全自主可控的云操作系统-云平台

［完仝目主可控云操作系

打造完全自主可控的

云操作系统

可行性分析与设计

王智民2015-3

［完仝目主可控云操作系统可行性分析5殳计］--------------------------------------------------

目录

目录..................................................................................2

1云计算带来的历史机遇...............................................................1

2云操作系统安全自主可控的必要性....................................................2

3自主安全可控的可行性分析...........................................................3

3.1自主安全可控云操作系统定位....................................................34

3.2自主开发的可行性分析..........................................................34

3.3安全可控的可行性分析..........................................................98

4云操作系统设计...................................................................108

4.1计算机操作系统...............................................................1Q8

4.2云操作系统与云角色...........................................................119

4.3体系结构....................................................................1240

4.3.1总体设计....................................................................1240

4.3.2运行部署....................................................................1342

4.3.3组件通信....................................................................1443

4.3.4微内核........................................................................16

4.3.5云控制.....................................................................3132

4.3.6云交付.....................................................................4346

4.3.7云管理.....................................................................46&1-

4.4安全可控设计...............................................................

4.4.1安全风险分析................................................................5165

4.4.2安全可控评估模型...........................................................5459

4.4.3如何做到安全可控...........................................................5459

5总结............................................................................7585

6附录............................................................................Z585

6.1KVM运行原理...............................................................76&5

6.1.1基本术语....................................................错误!未定义书签。85

1

［完仝目主可控云操作系统可行性分析5殳计］

6.1.2KVM框架Z687

6.1.3KVM运行视图............................ZZ88

6.1.4KVM内核模块,错误!未定义书签。9Q

6.2VIRTIO性能数据...........................7990

621性能测试环境7990

6.2.2性能数据7994

7参考资料.......................................................................Z994

4

［完仝自主可控云操作系统可行性分析与i殳计］------------------------------------------------

1云计算带来的历史机遇

中国IT产业的发展大致经历了三个阶段：

第一个阶段是80年代中期90年代的个人计算机时代，这个时代将昂贵的大型的计算机变

成个人可负担的电脑，极大的提高了个人劳动效率。

第二个阶段是90年代中期到20世纪的互联网时代，这个时代将各种信息孤岛汇成非常庞

大网络，解决了人与人、人与物的有效沟通、共享与协作的效率。

第三个阶段是云计算时代，这个时代将IT资源从分散再次回归到集中的模式，通过提高IT

资源的利用率从而极大的降低了II消费的成本。

那么云计算发展给中国带来了哪些重大历史机遇呢？

1.云计算的规模效应会更加显著

传统数据中心的IT资源利用率目前大多不到50%,通过云计算技术可以使得服务器的利用

率提升到80%以上。

中国人口众多，高峰时段对服务资源的需求与正常时段之间的差距会非常大，相比欧美等其

他国家，在服务需求的低峰时段，我们国家会有更过的资源被闲置，这样造成了资源的大量

浪费。如果利用云计算的技术，实现资源的集中和共享，把空闲时段的资源补充到其他需要

的服务上，那么资源利用率提升的规模效应相对欧美等人口较少的国家就大得多。

2.云计算发展推动中国自主创新，缩短中国与欧美国家的差距

现在不论在国内还是在国外，云计算还处于起步阶段，云计算的技术在逐步完善，云计算之

上的应用在不断增多。云计算作为一种创新的IT基础架构管理方法和创新的商业模式，代

表了未来IT发展的方向。如果我们国家能赶在其他国家之前，加大云计算的投资，培养云

计算相关人才，建立云计算标准，推动云计算技术的发展，将会在未来IT竞争中，缩短与

欧美国家之间的差距，并在国家竞争中占据一定的有利地位。

3.云计算的高效与弹性将加速我国关系国计民生的重大行业的信息化建设

4-

［完仝自主可控云操作系统可行性分析与i殳计］

在中国，关系国计民生的重大行业包括银行、交通、能源、医疗等等，每个行业都面临信息

化建设的变革，以提升服务效率。

云计算技术方便的实现现有IT资源的重新利用，现有应用向云平滑迁移，同时在自动化、

弹性、控制等方面具有先天的优势，可以使得云计算技术、产品、服务大规模应用在国家重

大行业，加速这些行业的信息化建设与变更，以适应中国当前高速发展的需要。

2云操作系统安全自主可控的必要性

信息技术的前两个阶段，中国由于受限于当时的国情和历史背景都未能把握。这在客观上也

造成了中国信息产业当下仍落后于发达国家的现状。而第三次浪潮一云计算变革则方兴未

艾，处于发展初期。中国应当保持高度敏锐的“嗅觉”，在已经具备▼相当的信息产业的基

础上，密切跟踪云计算变革的发展情况，紧跟产业发展潮流，提前进行产业规划和引导，积

极制定云计算服务标准，力争在本次信息产业变革的浪潮中夺取主动地位，促进中国经济结

构的调整，摆脱长期以来在全球经济分工中的被动地位。

未来信息服务竞争的关键是“效率”之争，而提升效率的技术路径无外乎硬件和软件。云计

算浪潮则从硬件和软件两个方面同时推动信息技术和服务效率达到前所未有的高度。

云计算变革势不可挡，对中国来说是一次重大的商业机会，但同时也是一次重大的国家战略

布局的机会。云计算的特点是数据的大集中，所有的应用都要通过云平台与硬件进行交互，

所以它需要一个超大规模的、高效的云操作系统。但是如果中国没有自主的云操作系统，中

国企业80%-90%的应用都运行在别人的云操作系统上，会是什么结吴？我们失掉的恐怕不

仅仅是市场，而是国家战略。

所以中国在这个技术变革的关键历史时刻，需要有自主的云操作系统，而且是“完全自主知

识产权的”、“安全可控的”云操作系统。

所以相对云服务提供商的系统管理员来说，需要安全可控的云操作系统，因为系统管理员需

要确保云服务可持续提供、高质量提供、确保云不被利用等安全性；

相对于信息安全官员、审计者来说，需要安全可控的云操作系统，因为他需要对云的可控性、

可信性、可靠性和安全性进行全面的关注；

相对于信息技术编程者来说，需要安全可控的云操作系统,一方面底层编程者通过自己设计、

4-

［完仝自主可控云操作系统可行性分析与i殳计］

编码、测试确保云操作系统是完全自主可控的，另一方面云服务编程者需要底层操作系统提

供的支撑是可信的、可靠的、安全的；

相对于政府信息技术服务采购者来说，需要安全可控的云操作系统，需要确保采购使用的云

服务是在国家层面绝对可控的、可信的。

相对于公共云服务使用者来说,需要安全可控的云操作系统，因为他们更关注云服务的可信、

可靠。

3自主安全可控的可行性分析

3.1自主安全可控云操作系统定位

1）能够适应私有云、公有云、社区云和混合云等几种云部署模式

2）能够适应laaS、PaaSsSaaS等几种云服务模式

3.2自主开发的可行性分析

3.2.1计算机操作系统的运行原理

计算机操作系统是计算机中最基本的系统软件，它控制计算机的所有资源并提供应用程序开

发和运行的基础。所以操作系统的两个基本功能就在于“资源控制”与“为应用程序提供开

发和运行的环境”。

从不同的角度来看，操作系统所表现的形式是不同的。从用户的角度看，操作系统所体现是

它所提供的各式各样的服务；从程序员的角度来看，操作系统体现的是提供给用户的界面和

接口；而从设计人员的角度来看，操作系统又是一大堆模块和它们之间的相互联系［1］。

资源控制

资源控制一般涉及到资源的申请、释放与使用，而资源使用则会涉及到资源的分割、重组、

调配。

计算机资源一般包括计算、存储和网络，所以计算机操作系统的资源控制基本都困绕这三个

方面来进行的。

［完仝自主可控云操作系统可行性分

为应用程序提供开发与运行环境

计算机应用程序是利用计算机资源完成特定工作的计算机程序。所以应用程序一方面会使用

计算机操作系统提供的接口申请、使用和释放计算、网络和存储资源，另一方面会使用计算

机操作系统提供的接口与用户进行交互，交互的界面有多种，比如字符视窗界面、声音光电、

网络等。

对于计算机操作系统来说，可能服务多个应用程序，所以操作系统还需要考虑多个应用程序

的资源竞争的协调与调度。

我们知道，计算机操作系统经历了简单结构、单体内核结构、层次式结构、微内核结构、外

核结构等发展过程，但是计算机操作系统的核心组件仍然是CPU调度、内存管理、进程调

度、文件系统、网络管理、设备驱动等。下图是单体内核结构的操作系统结构图：

CPUMemoryNetworkDiskI/O

图单体结构计算机操作系统示意图

3.2.2云操作系统的核心部件

云操作系统与计算机操作系统在一定程度上具有较大的相似性，从资源的角度来看，云操作

4-

［完仝自主可控云操作系统可行性分析与i殳计］4^

系统的资源控制仍然离不开计算、网络和存储的控制，为运行在云操作系统上的云应用提供

开发和运行的环境。但是云操作系统在这两个方面的实现方式上由于底层物质基础的不同而

有较大的差异。

一台个人计算机的内部结构图如下:

南桥

磁盘阵列控制器

VVWWV

图个人计算机结构

我们知道，云计算的本质是要求“按需”提供信息技术服务，则要求n■资源能够做到集中

控制与使用，足够的细粒度可控、足够的灵活调度，并能够做到资源调度的自动化。

为了实现云计算，人们就自然的与计算机操作系统做对比，CPU、内存、硬盘资源能否再

分割以便于做到足够的细粒度可控，CPU、内存、硬盘资源能否做到集群分布式运行以便

于做到资源的大规模集中控制与使用，CPUs内存、硬盘资源能否用灵活的网络连接以便

于做到资源的扩充或缩减；CPU、内存、硬盘资源的调度能否支撑更大规模更加有效等，

所以数据中心逐步演化为下面的逻辑结构：

4-

［完仝自主可控云操作系统可行性分析与i殳计］

图云数据中心基础设施结构

所以云操作系统的核心组件主要有：

1）计算、网络、存储的池化

2）计算、网络、存储的集群管理

3）计算、网络、存储的组装与卸载

4）资源对外交互与呈现

5）安装与部署

3.2.3参考资源

涉及领域可参考开源项目参考价值

CoreOS适用于虚拟化的专用宿主操作系统

计算机操作系统

IntelDPDK专用宾客操作系统

系统架构OpenStack整体框架的包容性、适应性

CloudStack计算虚拟化的经典模型

组件通信Message组件解耦、异步通信、并发性能提升

Queue(RabbitMQs

Qpid、ZeroMQ)

FMN基于信令凭证的一种高速通信方式

计算虚拟化KVMsXEN经典Hypervisor

libvirt多hypervisor的控制与管理

［完仝自主可控云操作系统可行性分析与i殳计］4^

namespaceLinux容器实现的基础

virtioI/O设备虚拟化

SR-IOVsmacvtapI/Opass-through

KVMGTIntel@GVT-g在kvm上实现的一个完整GPU

虚拟化解决方案

FreeRDP开源的远程桌面显示协议

spice开源的远程桌面显示协议

网络虚拟化OpenFlow基于流表实现网络路径的虚拟化

Overlay基于隧道实现网络路径的虚拟化

OpenvSwitch一种虚拟交换机的实现

存储虚拟化LVMsCLVMLinux集成的逻辑卷管理

资源管理与运行控制OpenStack计算:Nova

网络：Neutron

块存储：Cinder

对象存储：Swift

身份管理：KeyStone

镜像管理:Glance

度量监控：Ceilometer

部署编排:Heat

大数据：Sahara

OpenDaylightSDNcontroller的一个实现

OpenContrail借鉴MPLS的一种SDN实现

LXCLinux实现的应用容器引擎

DockerdotCloud开源的一个基于LXC的高级容器

引擎

KubernetesGoogle开源的Docker容器集群管理系统

Niagara物联网自动化控制系统之一

Sedonac开源的用于嵌入式设备编程和开发的软件平台

1

［完仝自主可控云操作系统可行性分析与i殳计］------------------------------------------------

3.2.4人才基础

自主开发完成云操作系统，主要的人才需求与现状分析:

角色技能要求主要职责我国人才现状

系统架至少10年以上直接参从顶层设计云操作系统的已经具备相当数量

构师与设计代码规模超过体系结构

100万行大型软件项

目经历

掌握云计算、基础网

络、信息安全相关领

域的知识

项目经至少10年以上直接参组建、主导、指导、计划、已经具备相当数量

理与管理人员规模超过监控整个云操作系统开发

100人的项目团队经项目

历

熟练掌握与应用项目

管理技能

软件工至少2年以上自主设云操作系统相关开发大量

程师计、编码、测试代码

规模累计超过10万行

软件模块经历

熟练掌握云计算、基

础网络、信息安全相

关领域之一的知识

测试工至少2年以上主导测云操作系统的集成、系统、大量

程师试超过10万行软件模验收测试，为交付的质量把

块的测试经历关

4-

［完仝自主可控云操作系统可行性分析与i殳计］

熟练掌握云计算、基

础网络、信息安仝相

关领域之一的知识

质量保至少5年以上主导过项目过程中流程引导、工程人才稍微欠缺，大部分集中

障员超过10万行软件模块方法指导、质量监控与审计在大型民营企业中

的质量保障工作

熟练掌握软件质量保

障的相关知识与技能

安全保至少2年以上主导过体系框架、设计、代码等领人才相对比较短缺

障员超过10万行软件模块域的漏洞挖掘、脆弱性分

的漏洞挖掘、脆性性析，将安全意识和措施落实

分析与测试等工作到从设计到交付整个过程，

熟练掌握代码审计、尽可能减少系统的安全漏

脆弱性分析等的相关洞、不安全因素

知识与工具

3.3安全可控的可行性分析

3.3.1开源代码的参考与使用

在参考和使用开源代码的过程中，我们需要坚持几个原则:

D参考但不照搬

2）先消化吸收，经过加固后有选择的采纳

3）逐步重构，达到所有组件自主可控

4-

［完仝自主可控云操作系统可行性分析与i殳计］------------------------------------------------

3.3.2系统本身的安全性评估与加固

针对系统本身的安全性评估，从以下三个方面加以评估和着手解决：

①对操作系统代码本身的安全审计，即代码静态审查”

可以组件攻防实验里，定期地对云操作系统代码进行安全审计，并及时整改。

②漏洞主动挖掘

建立完善的系统运行漏洞检测机制，即“动态审查”，运用漏洞扫描平台、攻击扫描平台主

动挖掘潜在的安全漏洞。

③加固采纳的开源代码

有些开源项目已经比较成熟、稳定、没有太多必要再次开发，所以可能会直接采纳使用，但

无论开源代码是否存在不为人知的“后门”，都给云操作系统的安全带来隐患。为此，对于

所有采纳的开源组件，需要进行组件“加固”。

4云操作系统设计

4.1计算机操作系统

云计算涉及到的操作系统有：

1）服务器节点底层支持虚拟化的操作系统，通常称之为宿主操作系统（hostos）

2）运行在虚机里面的操作系统，通常称之为宾客操作系统（guestos）

3）支持远程桌面的操作系统，可能是常见的嵌入式操作系统，也可能是普通的个人电脑操

作系统

宿主操作系统，大部分情况下使用Linux操作系统，但如果要考虑安全可控和性能因素，则

需要专门的宿主操作系统：

1）国产操作系统比如詹其麟操作系统，可以从理论上确保宿主操作系统的安全可控

［完仝自主可控云操作系统可行性分析与i殳计］

2)专门用于云的宿主操作系统，针对云计算的特定需求做裁剪和优化，以便于更好的支持

KVM.,XEN-.容器等虚拟化需求

运行在虚机里面的宾客操作系统通常情况下与个人电脑操作系统无异，但由于底层的各种资

源都是虚拟的，性能相对运行在实体物理机器上下降很多，特别是一些I。密集型应用性能

更是下降得厉害，所以针对特定的应用，也有必要专门的宾客操作系统。

一些运行在虚机里面的网络吞吐密集型的应用，比如交换机、防火墙、负载均衡等需要网络

10性能相对物理机不能下降太多：甚至要求无损耗，则需要采取一些优化措施，比如宾客

操作系统绕过宿主操作系统，甚至是hypervisor,直接与网卡(HBA或以太网卡)通信，Intel

的DPDK技术就是这种优化方式的代表，国内汉柏安全操作系统ISOS也采用了类似的优

化思路。

通常云应用程序更新都比较快，但底层的操作系统千差万别，就windows操作系统版本差

异也较大，给云应用程序开发带来不小的负担，于是就出现一种诉求，希望能够有一个软件

层屏蔽底层操作系统的差异，这样应用程序开发不考虑底层操作系统差异，大大简化和加快

了云应用程序的开发和上线。Java虚拟机JVM是一个不错的选择，但JVM由于在宾客操

作系统上又加了一层封装，所以应用运行性能再次下降，在一些对性能要求较高的场景下，

JVM就无法适应。最近的“容器'：技术又开始受到关注，并得到逐步的认可。

容器的基本思想是给应用程序提供基本运行环境，这个环境不是一个完整的操作系统，而是

一个父进程，应用程序当做它的子进程运行。Docker.GoogleAppEngine(GAE)都是应

用容器实现的代表。所以容器在一定程度上可以看做是一个轻量级的应用操作系统。

4.2云操作系统与云角色

美国国家标准与技术研究院NIST制定的《云计算参考架构》将云角色分为云消费者(Cloud

Consumer)、云审计者(CloudAuditor)、云服务提供商(CloudProvider)、云管道提

供商(CloudCarrier)和云经纪商(CloudBroker)等角色⑴。

本文设计的云操作系统定位在云服务提供商提供云服务的操作系统，功能覆盖云计算参考模

型中的ServiceLayer、ResourceAbstractionandControlLayer和CloudService

Management11^

［完仝自主可控云操作系统可行性分析与i殳计］

云操作系统

CloudOS

CloudProvider

Cloud

ServiceOrchestrationBroker

CloudService

Management

Service

IntermediationI

Business

Support

Service

Aggregation)

ResourceAbstractionandProvisioning/

ControlLayer

ConfigurationService

Arbitrage

PhysicalResourceLayer

Portability/

Interoperability

z

CloudCarrier

图云操作系统在云计算参考模型中的位置

云操作系统直接或间接的与其他几个云角色都有交互。

云操作系统不像计算机操作系统大多运行在单台个人电脑或服务器上面，而是运行在大规模

的服务器、网络设备、存储设备、安全设备等硬件基础设施之上，云服务消费者主要有个人

用户、程序员、企业用户、第三方应用程序等。

4.3体系结构

本文设计的云操作系统不仅实现通用云操作系统的基本需求，还需要做到安全可控，所以在

进行体系结构设计的时候必须将此要求考虑进入。

431总体设计

为了更好的设计适用于云计算的操作系统，我们先简单的回顾一下计算机操作系统的体系结

构。计算机操作系统体系结构大致有简单结构、单体内核结构、层次式结构、微内核结构、

外核结构等⑶。层次式结构减少了各模块之间的紧密依赖、相互调用的关系，特别是消除循

环调用现象，实现有序调用。微内核结构的思想是尽可能减少操作系统的组件，只是留下必

须的组件以内核态运行，确保核心基础的高稳定性。

所以，我们参考计算机操作系统的层次式和微内核结构，将云操作系统的核心组件以微内核

的方式设计（微内核设计借鉴计算机微内核操作系统在系统健壮性方面设计理念，单并不代

表一定运行在内核态），扩展组件放在微内核之外。扩展组件与核心组件之间、扩展组件之

4-

［完仝自主可控云操作系统可行性分析与i殳计］

间采用半序层次结构。

下图是云操作系统的休系结构:

合作伙食程序开发由

公操作系统

交忖Delivery

laaSPaaSSaaSSecaaS

虚机、桌面交付API、容器交付应用交付安全交付

控制Controller

计算资源控制网络资源控制存储资源控制安全资源控制

做内核Microkernel

计算虚拟化网络虚拟化存砧虚拟化安全虚拟化

本文设计的云操作系统底层硬件只支持X86服务器，以太网交换机，以太网络共享存储与

分布式存储，以太网络防火墙。

微内核Microkernel是整个云操作系统的最小可运行单元,对外以各种接口提供支撑和服务,

即使外部组件出现问题，也不会影响到微内核的运行。

控制Controller组件负责云操作系统各种资源池管理和运行控制，比如资源池的分配、调度

等，其并行计算和分布式计算是此组件的重要要素。

交付Delivery组件负责利用控制组件提供的资源管理接口，按照云消费者的要求以服务形

式提供，比如基础设施即服务laaS等。

管理Management组件负责云的所有层面的管理，包括云基础设施运维管理、云服务支撑

系统管理、云服务界面等。

安全Security组件确保云操作系统可控、可靠、可信及安全。

各个组件可以单独部署，每个组件内部会有大量的服务进程，每个服务进程至少有三个实例

以分布式方式运行，防止服务进程的单点故障。

4.3.2运行部署

4-

［完仝自主可控云操作系统可行性分析与i殳计］

本文设计的云操作系统由一群相对独立的服务进程通过逻辑处理构成的，这些服务进程按照

作用功能划分为微内核、控制、交付、管理和安全五个组件。每个服务进程至少运行三个实

例，所以理论上每个服务进程都可以任意运行在数据中心的节点上，服务进程之间通过网络

或计算机内部总线通信。不过为了减少复杂度，最好按照组件为大类来部署运行。

建议运行部署参照下面两种，图模式有管理控制集中的思维，将控制、交付、管理、安全

组件的服务集中部署，为了避免单节点故障，建议集群部署，至少三台物理节点。

闺ntEj

x86取务潜

X86服务器X86服务器交换机防火墙磁盘阵列

图运行部署模式1

图以完全分布式的方式部署,以B/S或C/S方式访问云操作系统。

浏览器或客户桀

冉口10

X86服务器X86服务器x86服务器x86服务潺x86服务揩X86服务器

图运行部署模式2

这两种部署方式都涉及到对传统交换机、防火墙的管理控制。将云操作系统的组件部署到传

统交换机或防火墙系统上是不现实的，除非要求交换机或防火墙软件系统做改造。所以在设

计云操作系统的时候需要考虑如何兼容传统硬件交换机、硬件防火墙，甚至硬件存储设备。

4.3.3组件通信

4-

［完仝自主可控云操作系统可行性分析与i殳计］4^]

OpenStack为了减少组件之间耦合度，同时能够高效的交互通信，专门设计了Message

Queue蛆件，实现方式有多种，比如RabbitMQ、Qpid、ZeroMQ等。

本文设计的云操作系统针对组件之间通信，借鉴消息环的设计理念，所有需要通信的组件或

服务进程向消息环MR(MessageRing)注册成为一个站点(Station),如下图所示:

图组件通信消息环MR

Station管理

图MR管理

MRController负责各个Station之间通信拥塞控制、状态监控等。Station负责消息的发送

和接收处理。

通信方式

Station是组件向MR注册的组件标识，是通信双方的地址。

Station之间通信是双向的，每个Station会拥有两个队列，一个接收队列，一个发送队列。为了

实现拥塞控制，发送队列分配一定凭证Credit,当Credit使用完毕后就k能再发送消息。

由于注册到MR的组件内部可能还会有更小的模块，更小模块或程序服务之间也可能需要通信,

4-

［完仝自主可控云操作系统可行性分析与i殳计］

所以在接收队列里面又设置了256个令牌桶Bucket,一个或多个Bucket分配给更小模块使用。

在组件注册的时候设置.

StaHon之间通信通道可能共享内存（比如多个station在同一台物理节点上运行），也可能是以

太网（比如多个station运行在不同的物理节点上）。

其处理逻辑如下图所示：

MRController

图Station通信

拥塞控制

MR通道的带宽总是有限，为了避免拥塞，MR通道带宽会在系统初始化阶段按照预先设定好的

策略分配给各个Station,各个Station自动管理分配给自己的带宽。

消息流量控制基于凭证credit,Stalion必须拥有足够的credit才能够发送消息。每个Station都

会针对每个目的bucket维护一定量的credito

在每个Station中都有一个发送凭证credit管理器，负责管理属于每个目的bucket的credito整

个MR会有固定数量的bucket,每个Station会维护相同数量的credit计算器，其决定该Station

是否拥有足够的credit可以发送消息。每个消息对应一个credit。当发送消息的时候，credit管

理器会检查credit个数是否大于待发送的消息个数，如果大于，则可以发送，否则会继续重试,

直到有足够credit时。

当发送成功，目的Station并成功接收到消息后，目的Station需要将相同数目的credit还给源

Station<,

4.3.4微内核

微内核是云操作系统的最小运行单元，主要有四个组件，如下图所示:

4-

［完仝自主可控云操作系统可行性分析与i殳计］------------------------------------------------

微内核Microkernel

广―卜，—「丁―

图微内核结构

计算虚拟化负责计算所涉及的CPU、内存、I/O等资源的分割、调度、管理等，以对外提供

计算资源池。

网络虚拟化负责网络所涉及的网络I/。、网络带宽、网络功能、网络延迟等资源的分割、调

度、管理等，以对外提供网络资源池。

存储虚拟化负责存储所涉及的存储I/O、存储块设备、存储对象、存储文件等资源的分割、

调度、管理等，以对外提供存储资源池。

安全虚拟化负责信息安全所涉及的安全策略、安全防护功能等浇源的分割、调度、管理等，

以对外提供安全资源池。

每个组件都会提供API,供其他组件使用。处于安全性考虑，这些API都会有调用认证、授

权和审计的设计。

4.3.4.1计算虚拟化

前期计算虚拟化后提供的主要是虚拟计算机，简称虚机（VM）,当前容器成为另外一种发

展比较快的虚拟技术。

1.虚机

计算虚拟化当前技术发展比较成熟，开源系统主要有XEN和KVM,商业系统主要有vmware

的vSphere、Microsoft的Hyper-Vo

开源的XEN和KVM开源，经过多年的发展和完善，实践证明已经比较稳定。本文设计的

云操作系统必须安全、可控，如果直接采用KVM或XEN会存在诸多安全性风险，但如果

重新开发也没有太多的必要，所以我们采用“加固”思路来设计计算虚拟化：

1）采用硬件辅助的完全虚拟化模型，当前只是支持Intel和AMD公司的x86指令体系

2）计算虚拟化涉及的CPU、内存、设备虚拟化直接使用KVM已有的代码

3）屏蔽KVM原始对外的所有API,重新封装计算虚拟化对外提供的API,称之为s-API,

［完仝自主可控云操作系统可行性分析与i殳计］4^

同时最小化API集，即只是对外提供必要的S-API

4)S-API是KVM被动对外提供的API,为了防范KVM主动向外提供“接口”，比如利用

某些不可知的硬件组件或特性主动向外发送信息，主动或被动触发向外发送加密信息等，设

计一个“安全监控”模块，一旦发现除了S-API交互通道之外的信息传输，则立即阻断并报

警

5)qemu-kvm是KVM为了提供完整的虚拟化而基于标准QEMU,纭合KVM特点做的针

对性改进的一个用户态组件。所以我们可以参考qemu-kvm,自主开发类似的功能模块

s-qemu-kvm,做到虚机运行行为的完全可控。

下图是本文设计的云操作系统计算虚拟化的逻辑结构：

VMVM_VM

virtiovirtiovirtio

frontenddriverfrontenddriverfrontenddriver

hypervisor

Hardware(VT-x)Hardware(SVM)

图计算虚拟化逻辑结构

KVM运行机制请阅读附录KVM运行原理章节，这里重点介绍自主开发的S-API、安全监控

和s-qemu-kvm三个模块的设计思路。

KVM的框架如下图：

4-

［完仝自主可控云操作系统可行性分析与i殳计］

VMVM

virtio

frontenddri^rfrontenddriver

hypervisor

LinuxkernelwithKVM

Hardware(VT-x)Hardware(SVM)

图KVM逻辑框架

对比上图可知，本设计用s-API替换/dev/kvm以及KVM处理有关I/O请求处理接口，用

s-qemu-kvm替换标准的qemu-kvm,同时在linux内核增加“安全监控”模块。

s-API

s-API设计的目的有三个：

♦屏蔽原来KVM对外提供的所有接口

♦加固KVM对外提供的必要接口

♦更紧密与安全地与s-qemu-kvm组件进行适配与融合

KVM对用户态暴漏一个字符文件；dev/kvm,qemu-kvm通过操作文件和ioctl方式与KVM

交互，KVM不提供针对/dev/kvm的read和write接口，只提供文件wen和close的接口,

其他的都是通过ioctl接口交自。

s-API为了加固接口，提高安全性，封装单独的ioctl接口，在封装ioctl接口中确保按照既

定的定义执行相应的操作。

s-API需要针对下面三类操作做封装：

•system指令，针对虚拟化系统的全局性参数设置和控制

KVM_CREATE_VM仓ij建KVM虚拟机

KVM_GET_API_VERSION查询当前KVMAPI版本

KVM_GET_MSR_INDEX_LIST获得MSR索弓|列表

［完仝自主可控云操作系统可行性分析与i殳计］---------------------------------------------------

KVM_CHECK_EXTENSION检查扩展支持情况

KVM_GET_VCPU_MMAP_SIZE运行虚拟机和用户态空间共享的一片内存区域的大小

•VM指令，针对VM虚拟机进行控制，如：内存设置、创建VCPU等

KVM_CREATE_VCPU为虚拟机仓U建VCPU

KVM_RUN根据kvmjun结构体信息，运行VM虚拟机

KVM_CREATE_IRQCHIP创建虚拟APIC,且随后创建的VCPU都关联到此APIC

KVM」RQ_LINE对某虚拟APIC发出中断信号

KVM_GET_IRQCHIP读取APIC的中断标志信息

KVM_SET_IRQCHIP写入APIC的中断标志信息

KVM_GET_DIRTY_LOG返回脏内存页的位图

•VCPU指令，针对具体的VCPU进行参数设置。如：相关寄存器的读写、中断控制等

寄存器控制相关，包括：

KVM_GET_REGS获取通用寄存器信息

KVM_SET_REGS设置通用寄存器信息

KVM_GET_SREGS获取特殊寄存器信息

KVM_SET_SREGS设置特殊寄存器信息

KVM_GET_MSRS获取MSR寄存器信息

KVMSETMSRS设置MSR寄存器信息

KVMGETFPU获取浮点寄存器信息

KVM_SET_FPU设置浮点寄存器信息

KVM_GET_XSAVE获取VCBU的xsavc奇存器信息

KVM_SET_XSAVE设置VCPU的xsave寄存器信息

KVM_GET_XCRS获取VCPU的xcr寄存器信息

KVM_SET_XCRS设置VCPU的xcr寄存器信息

中断和事件管理相关，包括：

KVM_INTERRUPT在VCPU上产生中断（当APTC无效时）

KVM_SET_SIGNAL_MASK设置某个VCPU的中断信号屏蔽掩码

KVM_GET_CPU_EVENTS获取VCPU中被挂起待延时处理的事件，如中断、NMI或异常

4-

［完仝自主可控云操作系统可行性分析与段计］---------------------------------------------------

KVM_SET_CPU_EVENTS设置VCPU的事件，如中断、NMI或异常

内存管理相关，包括：

KVM_TRANSLATE将VCPU的物理地址翻译成HPA

KVM_SET_USER_MEMORY_REGION修改VCPI；的内存区域

KVMSETTSSADDR初始化TSS内存区域（Intel架构专用）

KVM_SET_IDENTITY_MAPADDR创建EPT页表（Intel架构专用）

其他，包括CPUID的设置、调试接口等。

凡是在s-qemu-kvm与内核KVM模块之间发生的I/。请求与反馈都需要经过s-API提供的

I/O处理接口。

安全监控

安全监控主要是防止KVM主动向外发起的不安全通信，其设计框架图如下：

图安全监控逻辑结构

从设计上说，安全监控模块不仅仅是针对KVM的监控，也会针对Linux内核的其他模块进

行外发通信的监控，毕竟Linux宿主操作系统也存在较大的不安全性，

当然开启安全监控，会影响系统的性能，可以考虑在紧急时刻开启此功能。

s-qemu-kvm

由于虚机运行的行为控制完全在qemu-kvm,所以qemu-kvm必须重新设计和开发。

s-qemu-kvm的主体框架与qemwkvm相同，只是代码重新，南向与KVM交互的接口需要

替换成s-API的相应接口，北向与虚机交互仍然用标准的virtio接口，以兼容客户机virti。

前端驱动程序。

4-

［完仝自主可控云操作系统可行性分析与i殳计］

2.容器

下图是开源LXC项目提供的基于Linux的容器解决方案:

容器1容器2容器3

容器4容器n

VMM

Linuxkernelwithnamespaceandcgroup

Hardware(VT-x)Hardware(SVM)

图LXC容器

下图是我们经过加固和重构后的容器解决方案:

Hardware(VT-x)Hardware(SVM)

图加固与重构的容器

Namespace是Linux内核原生支持，我们没有必要去修改，cgroup是内核针对一组进程的

资源进行控制，比如进程所使用的CPU、内存等资源，从代码的角度看，cgroup就是对多

个task_struct数据结构的管理。正是cgroup对进程资源进行控制，所以从安全可控的角度

来看，必须针对cgroup做重构，以确保资源使用方面绝对可控。

Lxc是用户态的一个容器管理工具，同样也涉及到资源使用控制，也必须自主开发与重构。

4-

［完仝自主可控云操作系统可行性分析与i殳计］

网络虚拟化

网络虚拟化主要包括网络I/O虚拟化、网络转发路径虚拟化、网络带宽虚拟化和网络功能虚

拟化。随着云技术和云服务需求的发展，还可能要求网络转发延迟等网络属性也要做到虚拟

化，本设计暂不涉及这部分。

网络虚拟化

网络I/O虚拟化■网络转发路径虚拟化■网络带宽虚拟化I网络功能虚拟化I网络其他属性虚拟化

x86服务器以太网交换机

图网络虚拟化

网络I/O虚拟化

网络I/O虚拟化包括10速率、10带宽、10协商等虚拟化,这些属性都属于网络接口（网卡），

所以如果将网卡虚拟化后，相关属性也就做到了虚拟化，但虚拟化的‘颗粒度“不够细，不

过在绝大多数情况下已经足够。所以这里设计的网络I/。虚拟化采用网卡虚拟化的方式。

网卡虚拟化不但X86计算服务器需要，以太网交换机也可能需要，主要是看云操作系统采

用何种技术实现“软件定义网络”，这里主要说明X86