一、引言
麒麟操作系统是由国防科技大学、中软公司、联想公司、浪潮公司和民族恒星公司五家单位合作研制的服务器操作系统。按照麒麟官方的说法:
“Kylin服务器操作系统是国家863计划的重大研究成果,拥有完全自主版权的内核,与Linux在应用上二进制兼容,并支持64位,是中国独立研发成功的、具有完全自主知识产权的服务器操作系统。”
[1] —— 来自麒麟官方网站 http://www.kylin.org.cn/news.htm和 863计划官方网站
[2] http://www.863.org.cn/863_105/indust/indust_news/200409160008.html
“银河麒麟操作系统是针对未来的主流网络服务和高性能计算服务的需求,参照国际主流标准,参考Darwin、 FreeBSD、Linux和其它商用操作系统,借鉴UNIX操作系统和微内核操作系统的设计思想,设计并实现具有自主版权的、可支持多种CPU芯片和多种计算机体系结构的、具有高性能、高可用性与高安全性的、并与Linux应用和设备驱动二进制兼容的中文服务器操作系统,” ——摘自麒麟操作系统2.0.21内自带的帮助文档
近日,有不少人对麒麟操作系统宣称的“完全自主版权”和“中国独立研发成功”这两个核心问题产生了质疑。随着麒麟2.0.14和2.0.21系统可以通过麒麟的官方网站下载后( http://www.kylin.org.cn/download.htm ),这种质疑的声音越来越大。麒麟除内核以外的应用大部分都来自自由组织GNU的代码,这些代码并不属于“中国独立研发”,而且他们的版权也不属于麒麟操作系统的开发者。更有甚者,有人开始通过反汇编麒麟操作系统内核发现和美国的FreeBSD开放源代码操作系统非常相似。随后又有人成功的用 FreeBSD的内核启动了麒麟操作系统。按照麒麟官方的介绍,麒麟具有Linux的二进制兼容的能力,可是丝毫没有提及与FreeBSD的兼容性,使得麒麟内核与FreeBSD的关系变得比较引人注目。在官方介绍中的简简单单的“参考”是无法解释这种相似程度的。
在强烈的关注声中,麒麟开发人员在2006年2月16日,给出了一个说明,《关于银河麒麟操作系统的说明》[3],发布在 http://www.kylin.org.cn/download.htm .其中提到了和FreeBSD的关系:
“课题组通过评测和分析,认为当时正在研发中的FreeBSD 5.0 具有比Unix SVR4.2 更好的发展势头,特别是SMPng 项目的开展,为FreeBSD 5.0 支持SMP 对称多处理器系统奠定了良好的基础,因此银河麒麟操作系统的系统服务层从SVR4.2 升级到当时正在研发中的FreeBSD 5.0.”
声明发出后一定程度上得到了大家谅解,可是虽然提及和FreeBSD的关系,却又十分隐晦,既没有明确的对官方网站新闻中的报道失实承认错误,没有明确阐述麒麟的操作系统是否具有“完全知识产权”以及是否是“中国独立研发”,甚至也没有对官方页面上的事实报道进行修正。而且,既然说明使用了FreeBSD 5.0的代码,却又说仅限于系统服务层,而丝毫未提及所占比例。这依旧让人们对这个获得863计划软件重大专项的资助的操作系统到底有多少创新产生一个大大的疑问。
为了调查清楚麒麟操作系统内核自主创新的百分比,以及与其它操作系统之间的关系,我将麒麟操作系统内核与FreeBSD、NetBSD、OpenBSD、 Linux和Solaris的内核进行了可执行代码的相似度分析。
在整个过程中,我将尽量保持客观的原则进行分析。由于麒麟操作系统属于封闭源代码系统,因此在无法获得内核源代码的情况下,我将只进行二进制可执行代码文件的相似度分析。由于可执行代码受编译环境、内存分布情况以及模块的变动的影响很大,因此,会产生即使采用同一套代码,却产生很低的相似度情况。但是,对操作系统内核这种大型软件系统来说,却不会因为不同的代码而产生很高的相似度的情况。因此,我们将这次对二进制可执行代码分析所得的相似度作为相似度的下限。换句话说,真实的相似度应该会高于此次分析结果,但是由于分析方法的局限性,无法取得上限。
二、可执行文件的相似度比较
二进制可执行文件的相似度分析一直是一个难题。大家都知道,即使是同一份源代码,使用同一个编译器,可用不同的编译参数进行编译后,代码也会产生极大的差异。当发生有人因为盗用别人的源代码而产生的侵权后,如果不能够将二者的源代码拿出进行比较的话,判断是否抄袭非常困难。因此,一直以来或多或少,总会有人无所顾忌的将开放源代码的软件拿来加入到自己的软件中,或者干脆就是在那些源代码的基础上稍加修改和更换了版权信息就宣称是自己研发的。因为他们知道,只要不把自己的源代码公诸于众,那么抄袭就很难判定。下面我就详细说一下我采用的分析方法。
2.1 ELF可执行文件相似度分析方法
这次分析起始,我就碰到了一些难题。如果对二进制可执行文件进行基于字节的相似性分析,即使匹配上某些字节,也很难说明两段代码的相似性,另外匹配也很容易受到各种噪音的干扰而产生很低的相似度,可是噪音却无法被去除。因此,使最小比较单元具有明确的语义和合理的过滤噪音是我首先要解决的问题。
2.1.1 反汇编
二进制文件的比较难以确定最小单元语义的根本问题在于二进制文件是以字节为单位,然而每个字节却没有特定的含义。你很难说89 e5和83 EC 89中的89相同说明什么,在这个例子中,前者的89 e5是i386的一条指令,而后者的89则是一个立即数,所以他们相同实际上什么都不说明。针对这次分析,由于都是可执行代码,而且都采用了ELF的文件格式。由于这个特点,我首先将所有操作系统的内核通过objdump反汇编成汇编代码。这样做有一个直接的好处,就是每一行都是一条汇编语句,而每一条汇编语句又是一个程序不可分的最小逻辑单元。这样,接下来的分析就可以基于行来进行相似性的分析,因为每出现一行相同就说明有一个最小的逻辑单元相同,如果出现连续的行相似,那么就说明有连续的代码段相似。相同的行越多两个内核就越相似。并且经过反汇编后,就避免了因文件内包含的其他无关信息,如字符串、资源文件、数据文件等,对分析结果产生的影响。这个方法依旧无法避免因编译参数差异所造成的相似度下降的影响。虽然如此,但是我很幸运,从这次分析的结果看,依旧得到了不低的相似度。
2.1.2 过滤噪音
噪音的出现有很多原因,可能是内存分布不同、代码的增删导致的偏移地址的变化,对相同含义的常量而数值却不同等等。这些值的差异,可能会造成不同的执行结果,但是却对两段代码的相似性比较影响不大。请看下列两个代码段:
c043e9e8 |
|
begin(): < mov {Address},%eax < lea {Offset}(%eax),%esp < xor %ebp,%ebp < mov {Address},%esi < mov %esi,{Offset}(%eax) < pushl {Address} < call |
begin(): begin(): mov {Address},%eax mov {Address},%eax lea {Offset}(%eax),%esp lea {Offset}(%eax),%esp xor %ebp,%ebp xor %ebp,%ebp mov {Address},%esi mov {Address},%esi mov %esi,{Offset}(%eax) mov %esi,{Offset}(%eax) pushl {Address} pushl {Address} call |
[1] [2] [3] [4] 下一页