CN116775202A

CN116775202A - 模糊测试方法、装置、介质、电子设备及计算机程序产品

Info

Publication number: CN116775202A
Application number: CN202210227911.2A
Authority: CN
Inventors: 颜志强; 董志强
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-03-08
Filing date: 2022-03-08
Publication date: 2023-09-19

Abstract

本申请的实施例提供了一种云原生平台中虚拟机的模糊测试方法、装置、计算机可读介质、电子设备及计算机程序产品，该方法包括：运行云原生平台中由虚拟机模拟得到的待测试设备；获取待测试设备的目标设备标识信息和目标内存空间信息；根据目标设备标识信息获取待测试设备的设备结构体，并根据设备结构体中的可操作属性构造目标结构体；其中，设备结构体为属性集合，属性集合包括至少一个可操作属性；在目标内存空间信息指示的目标内存空间中对虚拟机执行模糊测试流程。本申请可对由虚拟机模拟的单个设备进行针对性地测试，提高了测试数据的有效性和模糊测试的效率。本申请实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。

Description

模糊测试方法、装置、介质、电子设备及计算机程序产品

技术领域

本申请涉及软件测试技术领域，具体而言，涉及一种云原生平台中虚拟机的模糊测试方法、装置、计算机可读介质、电子设备及计算机程序产品。

背景技术

随着虚拟化技术的发展，虚拟机的应用越来越广泛。以QEMU为代表的虚拟机已经普遍应用于云计算领域中，因此，对虚拟机进行测试来挖掘虚拟机的漏洞是保证云安全的重要手段之一。

然而，虚拟机通常能够同时模拟多个设备，现有的测试方案只能实现通用测试，无法对虚拟机模拟的单个设备进行针对性地测试，这会导致测试过程中无法及时触发某个设备的代码，这就导致了测试效率十分低下。

发明内容

本申请的实施例提供了一种云原生平台中虚拟机的模糊测试方法、装置、计算机可读介质、电子设备及计算机程序产品，进而至少在一定程度上可以对由虚拟机模拟的设备进行针对性地测试，并提高模糊测试的效率。

本申请的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。

根据本申请实施例的一个方面，提供了一种云原生平台中虚拟机的模糊测试方法，所述方法包括：运行云原生平台中由虚拟机模拟得到的待测试设备；获取所述待测试设备的目标设备标识信息和目标内存空间信息；根据所述目标设备标识信息获取所述待测试设备的设备结构体，并根据所述设备结构体中的可操作属性构造目标结构体；其中，所述设备结构体为属性集合，所述属性集合包括至少一个可操作属性；在所述待测试设备的目标内存空间信息指示的目标内存空间中对所述虚拟机执行模糊测试流程；其中，所述模糊测试流程包括：获取随机种子数据；基于所述随机种子数据对所述目标结构体进行赋值来得到赋值后目标结构体；根据所述赋值后目标结构体随机执行所述待测试设备的设备处理流程。

根据本申请实施例的一个方面，提供了一种云原生平台中虚拟机的模糊测试装置，所述装置包括：运行单元，用于运行云原生平台中由虚拟机模拟得到的待测试设备；信息获取单元，用于获取所述待测试设备的目标设备标识信息和目标内存空间信息；获取和构造单元，用于根据所述目标设备标识信息获取所述待测试设备的设备结构体，并根据所述设备结构体中的可操作属性构造目标结构体；其中，所述设备结构体为属性集合，所述属性集合包括至少一个可操作属性；执行单元，用于在所述待测试设备的目标内存空间信息指示的目标内存空间中对所述虚拟机执行模糊测试流程；其中，所述模糊测试流程包括：获取随机种子数据；基于所述随机种子数据对所述目标结构体进行赋值来得到赋值后目标结构体；根据所述赋值后目标结构体随机执行所述待测试设备的设备处理流程。

在本申请的一些实施例中，基于前述方案，所述执行单元配置为：获取与当前模糊测试流程中待执行的设备处理流程匹配的随机种子数据。

在本申请的一些实施例中，基于前述方案，所述模糊测试流程是重复执行的，所述执行单元配置为：对目标随机种子数据进行随机变异，得到新随机种子数据，其中，所述目标随机种子数据是在目标模糊测试流程中获取到的随机种子数据，所述目标模糊测试流程是已经执行完成的模糊测试流程；基于所述新随机种子数据对所述目标结构体进行赋值，得到赋值后目标结构体。

在本申请的一些实施例中，基于前述方案，所述执行单元配置为：若在执行所述目标模糊测试流程时覆盖到的代码为首次覆盖到的代码，则对所述目标随机种子数据中的目标部分进行随机变异，其中，所述目标部分是所述目标随机种子数据中对所述目标结构体进行赋值的部分。

在本申请的一些实施例中，基于前述方案，所述执行单元还用于：在所述模糊测试流程的执行时长达到预定最大等待时间时，若所述虚拟机仍未发生崩溃，则重新执行所述模糊测试流程。

在本申请的一些实施例中，基于前述方案，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，所述信息获取单元还用于：判断系统环境参数的参数值中是否包括所述预定最大等待时间，其中，获取所述待测试设备的目标设备标识信息和目标内存空间信息是在所述系统环境参数的参数值中包括所述预定最大等待时间的情况下进行的。

在本申请的一些实施例中，基于前述方案，所述执行单元还用于：获取随机种子数据，并确定所述随机种子数据的数据长度；若所述随机种子数据的数据长度未达到预定最小数据长度，则重新获取随机种子数据，直至获取到的随机种子数据的数据长度达到所述预定最小数据长度。

在本申请的一些实施例中，基于前述方案，所述信息获取单元配置为：获取测试设备标识信息和与所述测试设备标识信息对应的内存空间标识信息；通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息；根据所述内存空间标识信息获取所述待测试设备的内存空间信息，并从所述内存空间信息中获取目标内存空间信息。

在本申请的一些实施例中，基于前述方案，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，所述信息获取单元还用于：判断系统环境参数的参数值中是否包括测试设备标识信息，其中，通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息是在所述系统环境参数的参数值中包括测试设备标识信息的情况下进行的。

在本申请的一些实施例中，基于前述方案，在执行模糊测试流程之前，所述信息获取单元还用于：获取直接存储器访问读写空间的基地址，所述直接存储器访问读写空间用于存储随机种子数据；所述执行单元配置为：根据所述基地址从所述直接存储器访问读写空间获取随机种子数据。

在本申请的一些实施例中，基于前述方案，所述执行单元配置为：获取随机数；根据所述随机数随机进入所述待测试设备的设备处理流程，并根据所述赋值后目标结构体执行所述设备处理流程。

根据本申请实施例的一个方面，提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述实施例中所述的云原生平台中虚拟机的模糊测试方法。

根据本申请实施例的一个方面，提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如上述实施例中所述的云原生平台中虚拟机的模糊测试方法。

根据本申请实施例的一个方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如上述实施例中所述的云原生平台中虚拟机的模糊测试方法。

在本申请的一些实施例所提供的技术方案中，通过先获取由云原生平台中虚拟机模拟而成的待测试设备的目标设备标识信息和目标内存空间信息，从而能够根据目标设备标识信息得到待测试设备的设备结构体，在此基础上，继续根据设备结构体中的可操作属性构造目标结构体，并在目标内存空间信息指示的目标内存空间中执行模糊测试流程，每次执行的模糊测试流程中既包括基于获取到的随机种子数据对目标结构体进行赋值来得到赋值后目标结构体的步骤，还包括利用赋值后目标结构体随机执行待测试设备的设备处理流程步骤，进而进行对虚拟机的模糊测试。因此，整个方案能够对待测试设备的随机一个设备处理流程进行随机数据的输入，从而实现了模糊测试；在本方案中，一方面，还可以对由虚拟机模拟的单个设备进行针对性地测试，另一方面，通过先根据设备结构体中的可操作属性构造的目标结构体，并对目标结构体进行随机赋值，再利用赋值后目标结构体进行设备处理流程的执行，显著提高了测试数据的有效性，大大提高了对云原生平台中虚拟机的模糊测试的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了相关技术中对QEMU模拟的硬件设备进行测试的原理示意图；

图2示出了本申请实施例的技术方案的在具体应用场景使用模糊测试框架进行模糊测试的数据流向示意图；

图3示出了根据本申请的一个实施例的云原生平台中虚拟机的模糊测试方法的流程图；

图4示出了根据本申请的一个实施例的获取待测试设备的目标设备标识信息和目标内存空间信息的流程图；

图5示出了根据本申请的一个实施例的测试前准备阶段的流程示意图；

图6示出了根据本申请的一个实施例的测试初始化阶段的流程示意图；

图7示出了根据本申请的一个实施例的测试流程中阶段的流程示意图；

图8示出了根据本申请的一个实施例的图3中步骤340的细节的流程图；

图9示出了根据本申请的一个实施例的测试后期阶段的流程示意图；

图10示出了根据本申请的一个实施例的对虚拟机进行模糊测试的整体流程示意图；

图11示出了未经优化的原技术方案的测试效果示意图；

图12示出了根据本申请方案进行优化之后的测试效果示意图；

图13示出了根据本申请的一个实施例的云原生平台中虚拟机的模糊测试装置的框图；

图14示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本申请将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，提供许多具体细节从而给出对本申请的实施例的充分理解。然而，本领域技术人员将意识到，可以实践本申请的技术方案而没有特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知方法、装置、实现或者操作以避免模糊本申请的各方面。

附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

虚拟化是一种资源管理技术，是将计算机的各种实体资源(CPU、内存、磁盘空间、网络适配器等)，予以抽象、转换后呈现出来并可供分割、组合为一个或多个电脑配置环境。由此，打破实体结构间的不可切割的障碍，使用户可以比原本的配置更好的方式来应用这些电脑硬件资源。这些资源的新虚拟部分是不受现有资源的架设方式，地域或物理配置所限制。一般所指的虚拟化资源包括计算能力和资料存储。

QEMU是一款可执行硬件虚拟化的开源虚拟机。QEMU有整套的虚拟机实现，包括处理器虚拟化、内存虚拟化以及I/O设备的虚拟化。QEMU能够运行多种未修改的客户机OS，也能够模拟跨架构的环境，例如能够在x86架构下模拟ARM平台，运行ARM架构的程序。随着QEMU的不断发展成熟，QEMU已成为云厂商作为云平台底层虚拟化的不二选择，是云原生中不可或缺的一部分。现阶段的云安全厂商在做云服务器最底层的虚拟化的时候，采用的就是QEMU作为关键基础设施。因此QEMU的安全性不可忽视，历史上也存着部分QEMU逃逸的相关漏洞，能够导致攻击者从虚拟机中逃逸出来完全控制宿主机的权限，这种逃逸漏洞的危害是很大的。对QEMU进行漏洞挖掘并修复是保证QEMU安全的方法之一，但是由于QEMU本身的虚拟化特性，导致它与普通的软件模糊测试不同，使得现阶段虚拟化模糊测试的研究案例比较少。

模糊测试是一种软件测试技术，又可称为“fuzz”。其核心思想是将自动或半自动生成的随机数据输入到一个程序中，并监测程序异常，如崩溃，断言(assertion)失败，以发现可能的程序错误，比如内存泄漏。模糊测试常常用于检测软件或计算机系统的安全漏洞。

相关技术方案是利用了QEMU的QTest特性实现对QEMU进行测试的。QTest是QEMU的单元测试框架，主要用作对QEMU模拟的硬件设备进行单元测试。图1示出了相关技术中对QEMU模拟的硬件设备进行测试的原理示意图。请参见图1所示，Qtest包括Qtestclient(客户端)和Qtest server(服务端)，两者之间通过Unix socket通信，Qtestclient包括Qgraph、libqos、libqtest、glibtest等。QTest支持发送PIO、MMIO、中断和QMP指令等等。在QTest使用场景中，QTest是直接与虚拟硬件(HardwareEmulation)交互的，相关技术方案基于此特性实现对QEMU进行模糊测试。

具体地，相关技术方案采用了fork方法，使得输入种子进行一连串的执行后得到的结果记录下来，形成可复现的种子。并设计了十个opcode handle函数，用输入种子进行随机归类，进入handle之后根据各个handle操作，读或者写操作进行相关的种子转换操作。例如读操作，那么就将部分输入种子转变为写区域、写偏移、写数据三部分，最终达到在随机的地址写入随机的数据的效果。以此来达到模糊测试的目的。

然而，该相关技术方案存在的明显缺陷就是测试效率低下，产生该缺陷的原因有两方面：

第一，该方案采用了fork的形式，fork在程序运行过程中是非常消耗CPU性能的，经过测试，fork在整个模糊测试过程中占据了将近80％的资源，因此会导致真正在对QEMU进行测试的效率不高。

第二，相关技术方案提出的是一个通用测试框架，而在QEMU中是存在许许多多的设备的，不仅限于声卡、网卡、存储器等等，而且这些设备的结构和框架都不同。这就导致上述通用测试框架无法针对单个设备进行针对性的测试，因此会导致测试过程中即使变异了很久也无法触发到设备的某块代码，最终使得测试效率低下。

为此，本申请首先提供了一种云原生平台中虚拟机的模糊测试方法。基于本申请实施例提供的云原生平台中虚拟机的模糊测试方法可以克服上述缺陷，能够避免采用fork，实现对由云原生平台中QEMU模拟的单个设备进行针对性的测试，从而提高测试效率，最终能够实现对虚拟机中漏洞的挖掘。

本申请实施例的方案可以应用到QEMU的实际运行环境中去。例如可以应用到云环境当中，云环境采用的是子机加母机的方式，假设子机的操作系统是Ubuntu，母机采用的是KVM和QEMU的架构，母机的操作系统也为Ubuntu。那么，在基于本申请实施例的方案对QEMU进行模糊测试时，需要在QEMU代码中添加本申请所优化的测试代码，并针对想要测试的设备(假设是e1000e网卡设备)编写相应的结构化fuzz代码，随后编译启动fuzz程序，就能够自动让机器不断地测试目标设备了。

本申请实施例以基于Libfuzzer模糊测试框架实现对可执行硬件虚拟化的开源虚拟机QEMU的漏洞挖掘为例进行示例性说明。Libfuzzer模糊测试框架是一个基于覆盖率引导的模糊测试引擎。Libfuzzer要和被测试的库链接在一起，通过一个特殊的模糊测试进入点(目标函数)，用测试用例去测试被测试的库。Libfuzzer会识别出哪些代码区域已经测试过。然后在输入数据的语料库上产生变异，来最大化代码覆盖，覆盖的信息由llvm插桩提供。

图2示出了本申请实施例的技术方案的在具体应用场景使用模糊测试框架进行模糊测试的数据流向示意图。如图2所示，首先，通过模糊测试框架循环变异输入种子数据。然后，可以对QEMU模拟的各设备进行相应的结构化输入，比如，可以实现网络设备结构化输入，向虚拟网卡发送模糊测试数据；还可以实现显卡设备结构化输入，向虚拟显卡发送模糊测试数据；此外，还可以实现硬盘设备结构化输入，向虚拟硬盘发送模糊测试数据。在完成模糊测试数据的输入后，QEMU模拟的设备会进行相应的处理操作，然后系统还会对触发的代码进行覆盖率搜集；然后根据覆盖率重新进行Libfuzzer循环变异输入，继续开始下一轮测试。整个过程循环往复地执行，可以实现对单个设备的模糊测试。

图2实施例中利用QEMU这一虚拟机模拟了虚拟网卡、虚拟显卡和虚拟硬盘这三种设备，但应该理解，图2实施例中QEMU模拟的设备的数量和种类仅仅是示意性的。根据实现需要，可以采用其他类型的虚拟机，也可以模拟更多数量的其他类型的设备。

并且，易于理解，本申请实施例所提供的云原生平台中虚拟机的模糊测试方法一般由服务器执行，相应地，云原生平台中虚拟机的模糊测试装置一般设置于服务器中。但是，在本申请的其它实施例中，用户终端也可以与服务器具有相似的功能，从而执行本申请实施例所提供的云原生平台中虚拟机的模糊测试方案。

如前所述，终端或服务器均可以用来实现本申请实施例的方案。服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。终端可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

本申请实施例可以应用于云计算技术中，具体地，可以对云服务器中的虚拟机进行漏洞挖掘。云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务))平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

以下对本申请实施例的技术方案的实现细节进行详细阐述：

图3示出了根据本申请的一个实施例的云原生平台中虚拟机的模糊测试方法的流程图，该云原生平台中虚拟机的模糊测试方法可以由各种能够部署虚拟机的设备来执行，比如可以是用户终端或服务器，用户终端包括但不限于手机、电脑、智能语音交互设备、智能家电、车载终端、飞行器等。本申请实施例可应用于各种场景，包括但不限于云技术、人工智能、智慧交通、辅助驾驶等。请参照图3所示，该云原生平台中虚拟机的模糊测试方法至少包括以下步骤：

步骤310，运行云原生平台中由虚拟机模拟得到的待测试设备；

步骤320，获取待测试设备的目标设备标识信息和目标内存空间信息；

步骤330，根据目标设备标识信息获取待测试设备的设备结构体，并根据设备结构体中的可操作属性构造目标结构体；其中，设备结构体为属性集合，属性集合包括至少一个可操作属性；

步骤340，在待测试设备的目标内存空间信息指示的目标内存空间中对虚拟机执行模糊测试流程；

其中，模糊测试流程包括：获取随机种子数据；基于随机种子数据对目标结构体进行赋值来得到赋值后目标结构体；根据赋值后目标结构体随机执行待测试设备的设备处理流程。

下面，针对图3示出的各个步骤进行详述：

步骤310：运行云原生平台中由虚拟机模拟得到的待测试设备。

云原生平台是基于云原生架构建立的，在云原生架构中，采用开源堆栈进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。虚拟机以及由虚拟机模拟得到的待测试设备均位于云原生平台中。虚拟机比如可以采用QEMU，待测试设备可以是由QEMU模拟的任意类型的设备，比如可以是e1000e网卡设备。

待测试设备可以是使用PCI接口的设备，PCI接口也可以称为(PeripheralComponent Interconnect，外设部件互连标准)总线。因此，待测试设备也可以称为PCI设备。

云原生平台中的虚拟机会模拟得到多个设备，待测试设备可以是这些由虚拟机模拟得到的多个设备中的一个或多个设备。

步骤320：获取待测试设备的目标设备标识信息和目标内存空间信息。

QEMU会模拟多个设备，为了确定需要模糊测试的对象，因此需要获取待测试设备的目标设备标识信息；同理，也需要获取待测试设备的目标内存空间信息。

请一并参阅图4，其示出了根据本申请的一个实施例的获取待测试设备的目标设备标识信息和目标内存空间信息的流程图。如图4所示，获取待测试设备的目标设备标识信息和目标内存空间信息的步骤具体可以包括以下步骤：

在步骤410中，获取测试设备标识信息和与测试设备标识信息对应的内存空间标识信息。

测试设备标识信息用来标识一个设备，内存空间标识信息用来标识一个内存空间。测试设备标识信息和内存空间标识信息可以作为参数提供给能够实现本申请实施例方案的方法或函数中。

在步骤420中，通过将测试设备标识信息与由虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息。

目标设备标识信息可以是任何能够用来标识一个目标设备的信息，比如可以是设备名称。具体地，如果一个由虚拟机模拟而成的设备的标识信息与测试设备标识信息一致，则将该由虚拟机模拟而成的设备的标识信息作为目标设备标识信息。

在本申请的一个实施例中，在获取待测试设备的目标设备标识信息和目标内存空间信息之前，该云原生平台中虚拟机的模糊测试方法还包括：

判断系统环境参数的参数值中是否包括测试设备标识信息，其中，通过将测试设备标识信息与由虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息是在系统环境参数的参数值中包括测试设备标识信息的情况下进行的。

系统环境参数也可以称为系统环境变量，由于QEMU是运行在操作系统中的，因而需要在系统环境参数的参数值中设置过测试设备标识信息，才能够进行对相应的设备的模糊测试。

判断系统环境参数的参数值中是否包括测试设备标识信息这一步骤可以在本申请实施例方案的测试前准备阶段进行执行，在测试前准备阶段中，除了该步骤，还可以包括其他步骤。

在本申请的一个实施例中，在获取待测试设备的目标设备标识信息和目标内存空间信息之前，该云原生平台中虚拟机的模糊测试方法还包括：判断系统环境参数的参数值中是否包括预定最大等待时间，其中，获取待测试设备的目标设备标识信息和目标内存空间信息是在系统环境参数的参数值中包括预定最大等待时间的情况下进行的。

预定最大等待时间是预先设定的某一时长。预定最大等待时间的设置是用来避免模糊测试时出现卡死等情况，关于预定最大等待时间将在后续步骤中进行介绍。在本申请实施例中，通过预先对在系统环境参数是否设定预定最大等待时间进行判断，只有有效设定预定最大等待时间，才执行后续流程，能够在接下来的模糊测试过程中避免因卡死而导致测试效率降低的情况出现。

图5示出了根据本申请的一个实施例的测试前准备阶段的流程示意图。如图5所示，测试前准备阶段可以包括以下步骤：

步骤510，开始。

开始执行测试前准备阶段的流程。

步骤520，获取虚拟机的启动参数值。

获取QEMU启动所需的命令行参数值。以QEMU模拟e1000e网卡设备为例，启动参数值就可以是“qemu-system-i386-M q35-nodefaults-device e1000e,netdev＝net0-netdev user,id＝net0”，该启动参数值可以从一个config结构体中获得。

步骤530，判断系统环境参数中是否设定过启动参数值。

需要在系统环境参数中设定过启动参数值，虚拟机才可以正常启动。如果是，则执行步骤540，如果否，则执行步骤590。

在具体实现方面，可以通过getenv函数来获取系统环境参数中对启动参数的赋值，如果成功获取则进行下一步，如果失败，则确认异常，并退出测试。

步骤540，获取目标设备标识信息。

QEMU启动的时候会启动许多的默认设备，而有些设备并不是要测试的，因此需要排除掉。将输入的测试设备标识信息与虚拟机模拟而成的设备的标识信息进行对比，可以找到相应的目标设备标识信息。目标设备标识信息即为需要测试的目标设备的标识信息。每个设备都可以通过设备名称这一设备标识信息来进行标识。具体地，可以向object_child_foreach_recursive函数传入设备名称这一参数，该函数可以根据传入的设备名称从QEMU启动的众多设备的设备名称中筛选出需要测试的设备名称。

步骤550，判断系统环境参数中是否设定过目标设备标识信息。

判断系统环境参数的参数值中是否包括需要测试的设备名称，即判断系统环境参数的参数值是否包括目标设备标识信息，如果是，则执行步骤560，如果否，则执行步骤590。

步骤560，获取预定最大等待时间。

模糊测试引擎可能会遇到死循环或者死锁等卡死不动的情况，这些情况将会导致引擎陷入循环无法继续后续的工作。为了预防这样的情况，就需要设置预定最大等待时间，预定最大等待时间即为在得到测试结果之前允许进行模糊测试的最长时间，一旦本轮测试的持续时间达到预定最大等待时间时仍未发现虚拟机崩溃，就立即重置引擎开始新一轮的测试。预定最大等待时间可以默认设置为1000s。

步骤570，判断系统环境参数中是否设定过预定最大等待时间。

判断系统环境参数的参数值是否包括预定最大等待时间，如果是，则执行步骤580，如果否，则执行步骤590。

通过getenv函数来获取系统环境参数中对预定最大等待时间的赋值，如果成功获取则进行下一步，如果失败，则确认存在异常，并退出测试。

步骤580，结束。

正常结束测试前准备阶段的流程。

步骤590，发现异常，并退出。

请继续参见图4，在步骤430中，根据内存空间标识信息获取待测试设备的内存空间信息，并从内存空间信息中获取目标内存空间信息。

内存空间标识信息比如可以是内存空间名称。

内存空间信息可以包括内存空间的首地址和偏移量大小，偏移量大小即为内存空间大小。内存空间信息对应着内存空间，待测试设备的内存空间可能不止一个，所以内存空间信息也可能为多个。因此，需要通过获取目标内存空间信息，根据目标内存空间信息能够确定指定的目标内存空间，从而可以进行接下来的测试。目标内存空间信息也包括目标内存空间的首地址和内存空间大小。

在执行完测试前准备阶段之后，需要执行测试初始化阶段。图6示出了根据本申请的一个实施例的测试初始化阶段的流程示意图。请参见图6所示，测试初始化阶段可以包括以下步骤：

步骤610，开始。

开始执行测试初始化阶段的流程。

步骤620，初始化内存空间哈希表。

内存空间哈希表用来存储内存空间信息，初始化得到的内存空间哈希表为空表。

步骤630，初始化设备哈希表。

设备哈希表用来存储设备名称，即测试设备标识信息。初始化得到的设备哈希表也为空表。由于测试设备标识信息是PCI设备的标识信息，因此设备哈希表也可以称为PCI设备哈希表。在一些情况下，需要测试的设备不止一个，因此，通过设备哈希表可以存储多个待测试设备的设备名称。

步骤640，遍历获取待测试设备的内存空间信息。

用户需要与设备交互，因此每个设备都需要向用户提供相应的内存读写空间。

在步骤620和步骤630中已经初始化得到了两张哈希表，这时候就需要在QEMU启动的众多设备中去循环遍历出测试人员想要测试的待测试设备，遍历完待测试设备后还需遍历待测试设备相关的内存读写空间。具体地，对QEMU启动的模拟设备进行遍历，通过对比传入的设备名称来筛选出需要测试的待测试设备的设备名称，传入的设备名称即为测试设备标识信息，需要测试的待测试设备的设备名称即为目标设备标识信息；循环遍历目标设备中的所有内存读写空间，通过对比传入的内存空间名称来筛选出需要测试的待测试设备的内存空间信息。

内存读写空间是以内存空间信息的形式来记录的，而内存空间信息包括内存空间的首地址和偏移量大小。

步骤650，判断是否获取到待测试设备的内存空间信息。

判断待测试设备的内存空间的首地址和偏移量大小是否获取成功，如果成功获取则进行下一步，如果失败，则发现异常，并退出测试。

步骤660，将内存空间信息赋值给内存空间哈希表，并将目标设备标识信息赋值给设备哈希表。

在获得内存空间的首地址和偏移量大小之后，可以将内存空间的首地址和偏移量大小赋值给内存空间哈希表；在获得目标设备标识信息之后，可以将目标设备标识信息赋值给设备哈希表。

在赋值给内存空间哈希表之后，还可以判断该内存空间哈希表是否为空，如果为空，则退出测试。

步骤670，初始化用于挂载设备的总线，将虚拟机模拟的设备挂载到总线上，并开启设备。

在计算机中设备都是挂载至总线上的，因此，若要启动设备，必须先启动设备的相应PCI总线，qpci_new_pc函数就是启动和初始化总线的关键函数。在初始化PCI总线之后，便可以开启PCI设备了。

步骤680，获取目标内存空间的首地址和内存空间大小。

前面步骤已经在内存空间哈希表中存储了待测试设备的内存空间的首地址和偏移量大小，由于待测试设备可能有多个内存空间，而后续的模糊测试流程需要指定的内存空间，因此，还需要获取指定的内存空间才能够进行接下来的测试。因此，本步骤获取的目标内存空间的首地址和内存空间大小即为在步骤430中获取的目标内存空间信息。

步骤690，判断是否获取到目标内存空间的首地址和内存空间大小。

判断目标内存空间的首地址和内存空间大小是否获取成功，如果是，则执行步骤6100，如果否，则执行步骤6120。也就是说，如果获取成功，则进行下一步，如果获取失败，则退出，然后重新启动新一轮的模糊测试，即重新开始执行测试初始化阶段的步骤。

步骤6100，设定直接存储器访问读写空间的基地址，并初始化生成模糊测试所需的随机种子数据。

DMA(Direct Memory Access，直接存储器访问)是一种硬件设备绕过CPU直接读写数据的协议，是为了提升读写效率以及CPU性能的。

因为DMA协议的存储操作是需要将用户态的数据传入给QEMU中的设备的，所以需要知道DMA读写空间的基地址，这样测试人员才可以在测试开始前写入随机种子数据进DMA读写空间，方便后续的模糊测试。因此，还可以将生成的随机种子数据写入直接存储器访问读写空间。

步骤6110，结束。

测试初始化阶段的流程结束。

步骤6120，发现异常，并退出。

发现异常，退出测试。

请继续参见图3，步骤330：根据目标设备标识信息获取待测试设备的设备结构体，并根据设备结构体中的可操作属性构造目标结构体；其中，设备结构体为属性集合，属性集合包括至少一个可操作属性。

设备结构体为包括一个或多个属性的属性集合，这些属性中包括至少一个可操作属性；根据设备结构体中的可操作属性构造的目标结构体是包括一个或多个可操作属性的可操作属性集合。

可操作属性是后续执行设备处理流程需要进行操作的属性，也就是说，这些可操作属性的属性值可以作为后续需要执行的函数或方法的参数值。

步骤340：在待测试设备的目标内存空间信息指示的目标内存空间中对虚拟机执行模糊测试流程；

每次执行的模糊测试流程中都包括上述三个步骤。

在本申请前述的实施例中，随机种子数据由Libfuzzer这一模糊测试框架生成。每次执行一个模糊测试流程，均相当于进行了一次测试。在本步骤中可以重复执行模糊测试流程，直至虚拟机发生崩溃，从而可以挖掘出虚拟机发生崩溃所对应的漏洞。

在各次执行的模糊测试流程中，获取的随机种子数据和执行的设备处理流程均是独立的。因此，在各次执行的模糊测试流程中获取的随机种子数据和执行的设备处理流程可以相同，也可以不同。

待测试设备可以包括多个设备处理流程，每次执行模糊测试流程时，都会随机执行待测试设备的一个设备处理流程。目标内存空间信息包括目标内存空间的首地址和内存空间大小，因此，其用来指示目标内存空间。以待测试设备为网卡设备为例，在执行不同的设备处理流程时，需要执行不同的对寄存器的操作。将赋值后目标结构体经过设备处理流程的处理会得到相应的结果。

种子数据是模糊测试过程中的一串输入，例如在某次输入数据为“

\x00\x11\x22\x33\x44”,其中，\x表示后面的字符是十六进制数，因此，这串数据是多个十六进制数拼接而成的，这一串数据即可称为种子数据。另外，种子数据以文本数据的形式体现，也就是说前面的这串数据是以文本形式提供给模糊测试引擎的。随机种子数据便是随机生成的种子数据，其长度和内容可以是随机的。

待测试设备的设备处理流程可以为switch-case分支语句。目标内存空间位于QEMU进程空间中，进入目标内存空间可以找到待测试设备的设备处理流程，进而可以执行待测试设备的设备处理流程。

由于目标结构体是包括一个或多个可操作属性的可操作属性集合，基于随机种子数据对目标结构体进行赋值时，会对目标结构体中的各可操作属性进行赋值。可以将随机种子数据中的部分数据或全部数据赋值给目标结构体中的可操作属性。

由于目标结构体是可操作属性集合，因此通过根据赋值后目标结构体来执行设备处理流程，使得在执行设备处理流程时，可操作属性具有随机性，提高了模糊测试的精准性。

在本申请的一个实施例中，根据赋值后目标结构体随机执行待测试设备的设备处理流程，包括：获取随机数；根据随机数随机进入待测试设备的设备处理流程，并根据赋值后目标结构体执行设备处理流程。

在本申请实施例中，基于随机数实现了对设备处理流程的随机选择，保证了模糊测试的随机性。

在本申请的一个实施例中，获取随机种子数据，包括：获取与当前模糊测试流程中待执行的设备处理流程匹配的随机种子数据。

每个模糊测试流程中都包括设备处理流程，在本步骤中，在执行一个设备处理流程之前，需要获取与其匹配的随机种子数据，即生成的随机种子数据是需要与设备处理流程匹配。

如前所述，待随机执行的设备处理流程可以是某一switch-case分支语句，进而若该分支语句中存在判断某一个参数是否在某一范围内(比如，a<10)的语句，那么只有参数在相应的范围内时，才能顺利执行后续的流程。本申请实施例通过提前生成与设备处理流程匹配的种子数据，即可以使生成的种子数据满足分支语句中的判断条件，从而可以完整执行完设备处理流程，进而保证了随机种子数据的有效性，无需重新生成种子数据，提高了模糊测试的效率。

在本申请的一个实施例中，获取随机种子数据，包括：获取随机种子数据，并确定随机种子数据的数据长度；若随机种子数据的数据长度未达到预定最小数据长度，则重新获取随机种子数据，直至获取到的随机种子数据的数据长度达到预定最小数据长度。

当随机种子数据的数据长度过短时，会导致不满足数据输入要求，进而使得测试无效。本申请实施例中，通过预先对随机种子数据的数据长度进行判断，对输入数据进行限制，提高了输入的种子数据的有效性，避免了无效测试，进而提高了测试效率。

在本申请的一个实施例中，在执行模糊测试流程之前，该云原生平台中虚拟机的模糊测试方法还包括：获取直接存储器访问读写空间的基地址，直接存储器访问读写空间用于存储随机种子数据；获取随机种子数据，包括：根据基地址从直接存储器访问读写空间获取随机种子数据。

直接存储器访问读写空间即为DMA读写空间，可以将随机种子数据写入DMA读写空间，在后续进行模糊测试时需要从DMA读写空间获取随机种子数据。

在执行完测试初始化阶段之后，还需要执行测试流程中阶段。图7示出了根据本申请的一个实施例的测试流程中阶段的流程示意图。请参见图7所示，测试流程中阶段可以包括以下步骤：

步骤710，开始。

开始执行测试流程中阶段的步骤。

步骤720，获取输入的随机种子数据，并获取随机种子数据的数据长度。

随机种子数据可以由Libfuzzer生成并输入。

步骤730，判断数据长度是否达到预定最小数据长度。

如果是，则执行步骤740，如果否，则执行步骤770，结束流程，然后进行下一轮的测试，这一步能够用来防止无效测试。

具体地，设备处理流程这一case语句对应的处理语句为opcode handle函数，即opcode handle函数调用执行case语句。QEMU中设备的opcode handle函数需要传入一定长度的数据，有时候传入的数据过小就会导致测试效率过低甚至无效。为了保证每次的输入都能满足目标设备的数据长度要求，需要提前对输入的随机种子数据的长度做判断。如果随机种子数据的数据长度未达到预定最小数据长度则不进入opcode handle函数而是直接退出，因此能够有效提高测试效率。

具体地，以e1000e网卡为例，e1000e网卡处理函数为e1000e_io_write()，该网卡处理函数中包括case E1000_IOADDR和case E1000_IODATA。

若E1000_IODATA这一case中需要传入的数据至少为4字节，如果传入的数据为“\x00\x01\x02”，那么此次传入数据就无效，直接抛弃，然后开始下一轮的测试流程。

步骤740，将随机种子数据的一部分赋值给构造好的目标结构体。

目标结构体是根据待测试设备的设备结构体得到的。由于目标结构体可以包括一个或多个可操作属性，因此，需要从随机种子数据中取出一段或多段数据分别赋值给目标结构体中的可操作属性。

以e1000e网卡为例，该网卡有一个专有的网卡设备结构体，该网卡设备结构体中的部分属性是需要后续做操作的可操作属性，例如，core属性可以是一个可操作属性，那么，就可以将随机种子数据中的一部分随机数据赋值给该属性，使得该属性的值具有随机性，这样在后续对这些属性做操作的时候能够达到随机数据流的效果，从而充分发挥模糊测试的性能。

步骤750，对随机种子数据进行随机数提取操作或进行随机数生成操作，以提取或生成出供选择设备处理流程时使用的随机数。

可以选取随机种子数据的部分字节处的数据作为随机数，用来随机进入一个opcode handle函数。在本申请的其他实施例中，还可以利用rand函数来生成随机数。

步骤760，根据随机数进入随机选择的设备处理流程。

待测试设备的设备处理流程的代码如下：

设备处理流程为case，因此，随机进入一个case就相当于随机进入一个设备处理流程。上述代码中的tmp参数为步骤750所获取的一个随机数，因此，上述代码最终会根据tmp的值选取不同的case来进入不同的设备处理流程，从而达到随机触发各个设备处理流程的效果。

对于前面实施例中的E1000_IOADDR这一case，在执行测试用例进行模糊测试时，与该case对应的opcode handle函数可以为qtest_write(s,e1000e_base+E1000_IOADDR,data)，其中，s为待测试设备的名称，e1000e_base为目标内存空间信息中的首地址，E1000_IOADDR为case，data为测试时写入的数据。opcode handle函数调用执行case语句。

步骤770，结束。

结束执行测试流程中阶段的步骤。

图8示出了根据本申请的一个实施例的图3中步骤340的细节的流程图。在图8实施例中，模糊测试流程是重复执行的，如图8所示，获取随机种子数据具体可以包括以下步骤：

在步骤341中，对目标随机种子数据进行随机变异，得到新随机种子数据，其中，目标随机种子数据是在目标模糊测试流程中获取到的随机种子数据，目标模糊测试流程是已经执行完成的模糊测试流程。

变异是指将随机种子数据中的一部分变化为其他数据。如果根据当前的随机种子数据执行设备处理流程时并未挖掘出虚拟机的漏洞，那么就需要利用通过变异得到的新随机种子数据继续对虚拟机进行模糊测试。

可以通过多种方式对随机种子数据进行随机变异。假如，随机种子数据为“0x1234”，那么，可以将其变异为“0x3434”。

假如，随机种子数据为“\x00\x01\x02\x03”，那么还可以通过如下两种方式对该随机种子数据进行变异：

方式一，位翻转：在随机种子数据中随机确定若干个比特位；然后针对确定出的每一比特位，若在该比特位的值为1，则将该比特位的值置为0，若在该比特位的值为0，则将该比特位的值置为1。

方式二，随机加或随机减：对组成随机种子数据的多个数中的任意数随机加减某个数值。

例如，对于“\x00\x01\x02\x03”这一随机种子数据，若对将该随机种子数据中的第四个十六进制数加4，则随机种子数据变异为“\x00\x01\x02\x07”，该变异结果便是新随机种子数据，新随机种子数据用来作为新一轮测试的输入。

在步骤342中，基于新随机种子数据对目标结构体进行赋值，得到赋值后目标结构体。

通过将新随机种子数据赋值给目标结构体中的可操作属性，得到赋值后目标结构体。

在目标内存空间信息指示的目标内存空间中，除非虚拟机发生崩溃，否则重复执行模糊测试流程，每次执行模糊测试流程时，都需要获取随机种子数据，在后续执行的模糊测试流程中获取到的随机种子数据可以是通过对之前执行的模糊测试流程中获取的随机种子数据进行变异而得到的。

如果发现虚拟机发生崩溃，说明虚拟机出现了漏洞，因此可以挖掘出导致虚拟机发生崩溃的漏洞。

在本申请的一个实施例中，该云原生平台中虚拟机的模糊测试方法还包括：在模糊测试流程的执行时长达到预定最大等待时间时，若虚拟机仍未发生崩溃，则重新执行模糊测试流程。

具体地，当执行模糊测试流程的总时长达到预定时长时，如果虚拟机仍未发生崩溃，说明仍未发现虚拟机漏洞，这种情况可能是因为测试程序遇到死循环或者死锁等问题而导致的卡死不动的现象出现了，此时，通过重新执行模糊测试流程，可以避免测试效率降低。

在本申请的一个实施例中，对目标随机种子数据进行随机变异，包括：若在执行目标模糊测试流程时覆盖到的代码为首次覆盖到的代码，则对目标随机种子数据中的目标部分进行随机变异，其中，目标部分是目标随机种子数据中对目标结构体进行赋值的部分。

由于通过执行设备处理流程才能够实现代码覆盖，因此，执行目标模糊测试流程时所覆盖到的代码是通过执行目标模糊测试流程中的设备处理流程来覆盖的。

如前所述，目标结构体是从设备结构体解耦出来的，本申请实施例在对目标结构体进行赋值时，是将目标随机种子数据的一部分赋值给目标结构体，而该部分即为目标部分。因此通过只对该目标部分进行变异，而不是盲目变异，提高了变异的有效性，进而提高了测试效率。

只有在执行模糊测试流程时覆盖到的代码为首次覆盖到的代码，才对相应的随机种子数据进行随机变异；而如果在执行模糊测试流程时覆盖到的代码为已经覆盖到的代码，那么，在继续进行测试时，需要重新获取一个随机种子数据，并基于重新获取的随机种子数据重新随机执行模糊测试流程。

在执行完测试流程中阶段之后，还需要执行测试后期阶段。图9示出了根据本申请的一个实施例的测试后期阶段的流程示意图。请参见图9所示，测试后期阶段可以包括以下步骤：

步骤910，开始。

开始执行测试前准备阶段的流程。

步骤920，获取代码覆盖率和随机种子数据。

获取一次测试结束后或者执行完一次测试流程后的代码覆盖率和种子数据。

每次执行测试流程时会触发相应的代码，触发的代码即为覆盖的代码。代码覆盖率是整个测试过程中已经触发的代码行数与待测试设备的所有代码行数的比值，测试过程需要不断提升模糊测试引擎的代码覆盖率，以提高测试效率。

以前述实施例中的e1000e网卡处理函数为例，假设第一次测试输入随机种子数据为“\x00\x01\x02\x03”，该随机种子数据最终触发了E1000_IOADDR的case，那么在e1000e_io_write函数中就已经覆盖到了164-171行的代码；因此，后续测试需要做的就是去覆盖到剩余的未触发的172-180行代码，从而提高模糊测试引擎的代码覆盖率，提升模糊测试效率。

步骤930，根据代码覆盖率判断是否覆盖到了新的代码。

如果随机种子数据触发了新的代码，则执行步骤940，否则，执行步骤960。触发新的代码即覆盖到了新的代码，此时代码覆盖率也会提升。因此，可以根据代码覆盖率判断是否覆盖到了新的代码。当然，在本申请的其他实施例中，也可以直接根据新的代码是否被触发来确定是否覆盖到了新的代码。

步骤940，将该随机种子数据保存进数据库中。

还是以前述实施例中的e1000e网卡处理函数为例，假如第一次测试时通过“\x00\x01\x02\x03”这一随机种子数据触发了164-171行的代码，这些代码为首次覆盖到的代码，因此可以认定该随机种子数据是一个特殊的随机种子数据，可以保存起来为后续测试使用，因为这样做会最大化触发新代码的效果。假设第二次测试时输入的随机种子数据仍然为“\x00\x11\x02\x03”，仍然触发了164-171行的代码，此时没有触发新代码增加代码覆盖率，因此这个随机种子数据就可以视为普通的随机种子数据，不保存起来为后续测试使用。

步骤950，对保存在数据库中的该随机种子数据进行变异，将变异后的随机种子数据作为下一次测试的输入数据。

将变异后的随机种子数据作为新随机种子数据，基于新随机种子数据继续进行下一次测试。

步骤960，结束。

结束执行测试后期阶段的流程。

图10示出了根据本申请的一个实施例的对虚拟机进行模糊测试的整体流程示意图。下面，结合图10，进一步介绍本申请实施例的方案，如图10所示，包括以下步骤：

步骤1001，开始。

开始进行模糊测试。

步骤1002，判断系统环境参数中是否设定过启动参数值、目标设备标识信息及预定最大等待时间。

根据获取到的启动参数值、目标设备标识信息及预定最大等待时间分别判断系统环境参数的参数值中是否包括启动参数值、目标设备标识信息及预定最大等待时间；如果系统环境参数的参数值中包括启动参数值、目标设备标识信息及预定最大等待时间，则执行下一步，否则，执行步骤1010，以退出本轮模糊测试。系统环境参数可以是前面实施例中在母机的操作系统中设置的环境参数。

步骤1003，初始化内存空间哈希表和设备哈希表。

分别进行内存空间哈希表和设备哈希表的初始化操作，以生成空的内存空间哈希表和设备哈希表。内存空间哈希表用于存储内存空间信息；设备哈希表用于存储设备名称，即测试设备标识信息。

步骤1004，遍历获取待测试设备的内存空间信息。

在本步骤中，由于获取的是待测试设备的内存空间信息，因此，还可以获取到待测试设备的目标设备标识信息。

具体地，对QEMU启动的模拟设备进行遍历，通过对比传入的设备名称来筛选出需要测试的待测试设备的设备名称，传入的设备名称即为测试设备标识信息，需要测试的待测试设备的设备名称即为目标设备标识信息；循环遍历目标设备中的所有内存读写空间，通过对比传入的内存空间名称来筛选出需要测试的待测试设备的内存空间信息。

步骤1005，判断是否获取到待测试设备的内存空间信息。

内存空间信息包括内存空间的首地址和偏移量大小。因此，本步骤实际上是判断待测试设备的内存空间的首地址和偏移量大小是否获取成功，如果获取成功，则进行下一步；如果未获取到待测试设备的内存空间信息，则执行步骤1010，以退出模糊测试，从而可以开始重新进行模糊测试。

步骤1006，将内存空间信息赋值给内存空间哈希表，并将目标设备标识信息赋值给设备哈希表。

分别对空的内存空间哈希表和设备哈希表进行赋值。在获得内存空间的首地址和偏移量大小之后，将内存空间的首地址和偏移量大小赋值给内存空间哈希表；在获得目标设备标识信息之后，将目标设备标识信息赋值给设备哈希表。

步骤1007，初始化用于挂载设备的总线，将虚拟机模拟的设备挂载到总线上，并开启设备。

在服务器等各种形式的计算机上的设备均需要挂载至相应的总线上才能进行启动；本步骤先初始化以启动PCI总线，在此基础上可以启动PCI设备。

步骤1008，从内存空间哈希表获取目标内存空间的首地址和内存空间大小。

从内存空间哈希表获取目标内存空间信息。由于待测试设备可能有多个内存空间，而后续的模糊测试流程需要针对指定的内存空间进行测试，因此本步骤需要获取目标内存空间的首地址和内存空间大小作为目标内存空间信息，进一步明确要测试的目标内存空间。

步骤1009，判断是否获取到目标内存空间的首地址和内存空间大小。

判断目标内存空间的首地址和内存空间大小是否获取成功，如果否，说明无法确定要针对哪个内存空间进行测试，此时执行步骤1010，，以退出模糊测试；如果是，则继续执行步骤1011。

步骤1010，发现异常，并退出。

发现异常，并退出模糊测试，从而可以重新开始下一次的模糊测试。

步骤1011，设定直接存储器访问读写空间的基地址，初始化生成随机种子数据，并根据基地址将随机种子数据写入直接存储器访问读写空间。

在设定了DMA读写空间的基地址之后，通过模糊测试框架生成随机种子数据，然后将随机种子数据写入DMA(Direct Memory Access，直接存储器访问)读写空间以进行后续模糊测试。后续进行模糊测试时，从DMA读写空间便可以获取到随机种子数据。通过利用DMA读写空间获取随机种子数据，可以绕过CPU直接读写数据，提高了随机种子数据的获取效率，进而提高了测试效率。

步骤1012，从直接存储器访问读写空间获取随机种子数据。

根据DMA读写空间的基地址从DMA读写空间中获取已写入至DMA读写空间的随机种子数据，以为后续模糊测试提供所需输入的数据。

步骤1013，判断随机种子数据的数据长度是否达到预定最小数据长度。

如果是，则执行步骤1014；如果否，则重新执行步骤1012，以重新获取随机种子数据。

待测试设备的设备处理流程中需要传入一定长度的数据，否则可能导致测试效率过低；为了保证每次的输入都能满足待测试设备的数据长度要求，需要提前对输入的随机种子数据的数据长度做判断。如果随机种子数据的数据长度未达到预定最小数据长度则不继续进行测试，因此能够避免无效测试，有效提高测试效率。

步骤1014，将随机种子数据的一部分赋值给构造好的目标结构体，得到赋值后目标结构体。

从随机种子数据中提取出一部分数据赋值给目标结构体中的可操作属性，得到赋值后目标结构体。对于目标结构体中的每一个可操作属性，都需要从随机种子数据中提取出相应的数据来对其进行赋值。

步骤1015，对随机种子数据进行随机数提取操作或进行随机数生成操作，得到随机数。

随机数提取操作为:提取随机种子数据的部分字节处的数据作为随机数；随机数生成操作为:通过调用rand函数等随机数生成函数来生成随机数。

步骤1016，根据目标内存空间的首地址和内存空间大小访问目标内存空间，并在目标内存空间中根据随机数进入随机选择的设备处理流程，并根据赋值后目标结构体执行设备处理流程。

在步骤1008中已经获取到目标内存空间的首地址和内存空间大小，通过目标内存空间的首地址和内存空间大小可以进入目标内存空间，再根据在步骤1015中获得的随机数实现随机进入待测试设备的设备处理流程，然后根据赋值后目标结构体执行该待测试设备的设备处理流程。

步骤1017，判断虚拟机是否发生崩溃。

本申请实施例的目的是通过执行设备处理流程使虚拟机发生崩溃；如果虚拟机发生崩溃，则执行步骤1018以结束测试，从而可以挖掘出导致虚拟机发生崩溃的漏洞；如果虚拟机未发生崩溃，则需要继续执行步骤1019，以继续进行下一次测试。

步骤1018，结束。

结束模糊测试。

步骤1019，获取已执行的设备处理流程对应的代码覆盖率。

在执行完最近一个设备处理流程之后，获取代码覆盖率。代码覆盖率是整个测试过程中已经触发的代码行数与待测试设备的所有代码行数的比值，测试过程需要不断提升代码覆盖率，以提高测试效率，避免无效测试。

步骤1020，根据代码覆盖率判断是否覆盖到了新的代码。

若代码覆盖率提升，则确定覆盖到了新的代码；如果覆盖到了新的代码，则执行步骤1021；如果未覆盖到新的代码，则执行步骤1012，以重新获取随机种子数据。

步骤1021，将随机种子数据保存进数据库中。

如果上次执行设备处理流程时覆盖到了新的代码，可以认定该设备处理流程对应的随机种子数据是能够有效覆盖新代码的种子数据，则将该设备处理流程对应的随机种子数据保存进数据库中，以供后续变异使用。

步骤1022，对保存在数据库中的该随机种子数据进行变异，得到新随机种子数据。

变异是指将随机种子数据中的一部分变化为其他数据。可以通过位翻转、随机加、随机减等方式随机选择一种方式对随机种子数据进行随机变异。进一步地，可以针对随机种子数据对目标结构体进行赋值的目标部分进行变异。

在得到新随机种子数据后，需要转至执行步骤1013，以继续进行测试。

通过测试比对，在经过本申请方案进行测试方案优化之后，模糊测试效率得到了极大的提升。图11示出了未经优化的原技术方案的测试效果示意图。图12示出了根据本申请方案进行优化之后的测试效果示意图。图11和图12示出的为测试样例的输出结果，该测试样例对同一个设备进行测试，该设备存在一个明显的溢出漏洞。在基于未经优化的原技术方案进行测试时，在测试过程中的部分输出数据的截图如图11所示，可以看到，图11中并未显示漏洞信息，这说明经过长时间测试仍未发现漏洞，最终未经优化的原技术方案消耗了长达1.5个小时才发现了这个溢出漏洞。在根据本申请方案进行测试时，只用了不到1秒的时间就发现了该溢出漏洞，具体地，图12示出的一张截图便包含了从开始测试到发现漏洞的整个过程，其中，ERROR部分就是发现该溢出漏洞的预警报错信息。

综上所述，根据本申请实施例提供的云原生平台中虚拟机的模糊测试方法，针对相关技术测试效率慢的问题进行了针对性的优化。首先，本申请去除了fork的基本框架，不采用fork而是利用输入种子数据直接进行测试。其次，本申请在通用测试框架的基础上采取了针对不同设备采用不同的结构化测试方法。在每个设备的测试过程当中，都会获取设备的设备结构体，并根据设备结构体中的可操作属性构造目标结构体，从而利用随机种子数据对目标结构体进行随机赋值，最终基于随机赋值的目标结构体进行测试，在后续进行测试时，还会对随机种子数据进行结构化变异，即将变异部分与目标结构体匹配，在后续测试流程中可使用变异后的种子数据进行测试，进而在后续测试流程中提高测试效率。

以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的云原生平台中虚拟机的模糊测试方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的云原生平台中虚拟机的模糊测试方法的实施例。

图13示出了根据本申请的一个实施例的云原生平台中虚拟机的模糊测试装置的框图。

参照图13所示，根据本申请的一个实施例的云原生平台中虚拟机的模糊测试装置1300，包括：运行单元1310、信息获取单元1320、获取和构造单元1330以及执行单元1340。其中，运行单元1310用于运行云原生平台中由虚拟机模拟得到的待测试设备；信息获取单元1320用于获取所述待测试设备的目标设备标识信息和目标内存空间信息；获取和构造单元1330用于根据所述目标设备标识信息获取所述待测试设备的设备结构体，并根据所述设备结构体中的可操作属性构造目标结构体；其中，所述设备结构体为属性集合，所述属性集合包括至少一个可操作属性；执行单元1340用于在所述待测试设备的目标内存空间信息指示的目标内存空间中对所述虚拟机执行模糊测试流程；其中，所述模糊测试流程包括：获取随机种子数据；基于所述随机种子数据对所述目标结构体进行赋值来得到赋值后目标结构体；根据所述赋值后目标结构体随机执行所述待测试设备的设备处理流程。

在本申请的一些实施例中，基于前述方案，执行单元1340配置为：获取与当前模糊测试流程中待执行的设备处理流程匹配的随机种子数据。

在本申请的一些实施例中，基于前述方案，所述模糊测试流程是重复执行的，执行单元1340配置为：对目标随机种子数据进行随机变异，得到新随机种子数据，其中，所述目标随机种子数据是在目标模糊测试流程中获取到的随机种子数据，所述目标模糊测试流程是已经执行完成的模糊测试流程；基于所述新随机种子数据对所述目标结构体进行赋值，得到赋值后目标结构体。

在本申请的一些实施例中，基于前述方案，执行单元1340配置为：若在执行所述目标模糊测试流程时覆盖到的代码为首次覆盖到的代码，则对所述目标随机种子数据中的目标部分进行随机变异，其中，所述目标部分是所述目标随机种子数据中对所述目标结构体进行赋值的部分。

在本申请的一些实施例中，基于前述方案，执行单元1340还用于：在所述模糊测试流程的执行时长达到预定最大等待时间时，若所述虚拟机仍未发生崩溃，则重新执行所述模糊测试流程。

在本申请的一些实施例中，基于前述方案，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，信息获取单元1320还用于：判断系统环境参数的参数值中是否包括所述预定最大等待时间，其中，获取所述待测试设备的目标设备标识信息和目标内存空间信息是在所述系统环境参数的参数值中包括所述预定最大等待时间的情况下进行的。

在本申请的一些实施例中，基于前述方案，执行单元1340还用于：获取随机种子数据，并确定所述随机种子数据的数据长度；若所述随机种子数据的数据长度未达到预定最小数据长度，则重新获取随机种子数据，直至获取到的随机种子数据的数据长度达到所述预定最小数据长度。

在本申请的一些实施例中，基于前述方案，信息获取单元1320配置为：获取测试设备标识信息和与所述测试设备标识信息对应的内存空间标识信息；通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息；根据所述内存空间标识信息获取所述待测试设备的内存空间信息，并从所述内存空间信息中获取目标内存空间信息。

在本申请的一些实施例中，基于前述方案，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，信息获取单元1320还用于：判断系统环境参数的参数值中是否包括测试设备标识信息，其中，通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息是在所述系统环境参数的参数值中包括测试设备标识信息的情况下进行的。

在本申请的一些实施例中，基于前述方案，在执行模糊测试流程之前，信息获取单元1320还用于：获取直接存储器访问读写空间的基地址，所述直接存储器访问读写空间用于存储随机种子数据；执行单元1340配置为：根据所述基地址从所述直接存储器访问读写空间获取随机种子数据。

在本申请的一些实施例中，基于前述方案，执行单元1340配置为：获取随机数；根据所述随机数随机进入所述待测试设备的设备处理流程，并根据所述赋值后目标结构体执行所述设备处理流程。

需要说明的是，图14示出的电子设备的计算机系统1400仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图14所示，计算机系统1400包括中央处理单元(Central Processing Unit，CPU)1401，其可以根据存储在只读存储器(Read-Only Memory，ROM)1402中的程序或者从存储部分1408加载到随机访问存储器(Random Access Memory，RAM)1403中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 1403中，还存储有系统操作所需的各种程序和数据。CPU 1401、ROM 1402以及RAM1403通过总线1404彼此相连。输入/输出(Input/Output，I/O)接口1405也连接至总线1404。

以下部件连接至I/O接口1405：包括键盘、鼠标等的输入部分1406；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1407；包括硬盘等的存储部分1408；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1409。通信部分1409经由诸如因特网的网络执行通信处理。驱动器1410也根据需要连接至I/O接口1405。可拆卸介质1411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1410上，以便于从其上读出的计算机程序根据需要被安装入存储部分1408。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1409从网络上被下载和安装，和/或从可拆卸介质1411被安装。在该计算机程序被中央处理单元(CPU)1401执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

作为一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、触控终端、或者网络设备等)执行根据本申请实施方式的方法。

可以理解的是，在本申请的具体实施方式中，涉及到与视频处理相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims

1.一种云原生平台中虚拟机的模糊测试方法，其特征在于，所述方法包括：

运行云原生平台中由虚拟机模拟得到的待测试设备；

获取所述待测试设备的目标设备标识信息和目标内存空间信息；

根据所述目标设备标识信息获取所述待测试设备的设备结构体，并根据所述设备结构体中的可操作属性构造目标结构体；其中，所述设备结构体为属性集合，所述属性集合包括至少一个可操作属性；

在所述待测试设备的目标内存空间信息指示的目标内存空间中对所述虚拟机执行模糊测试流程；

其中，所述模糊测试流程包括：获取随机种子数据；基于所述随机种子数据对所述目标结构体进行赋值来得到赋值后目标结构体；根据所述赋值后目标结构体随机执行所述待测试设备的设备处理流程。

2.根据权利要求1所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述获取随机种子数据，包括：

获取与当前模糊测试流程中待执行的设备处理流程匹配的随机种子数据。

3.根据权利要求1所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述模糊测试流程是重复执行的，所述获取随机种子数据，包括：

对目标随机种子数据进行随机变异，得到新随机种子数据，其中，所述目标随机种子数据是在目标模糊测试流程中获取到的随机种子数据，所述目标模糊测试流程是已经执行完成的模糊测试流程；

基于所述新随机种子数据对所述目标结构体进行赋值，得到赋值后目标结构体。

4.根据权利要求3所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述对目标随机种子数据进行随机变异，包括：

若在执行所述目标模糊测试流程时覆盖到的代码为首次覆盖到的代码，则对所述目标随机种子数据中的目标部分进行随机变异，其中，所述目标部分是所述目标随机种子数据中对所述目标结构体进行赋值的部分。

5.根据权利要求3所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述方法还包括：

在所述模糊测试流程的执行时长达到预定最大等待时间时，若所述虚拟机仍未发生崩溃，则重新执行所述模糊测试流程。

6.根据权利要求5所述的云原生平台中虚拟机的模糊测试方法，其特征在于，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，所述方法还包括：

判断系统环境参数的参数值中是否包括所述预定最大等待时间，其中，获取所述待测试设备的目标设备标识信息和目标内存空间信息是在所述系统环境参数的参数值中包括所述预定最大等待时间的情况下进行的。

7.根据权利要求1所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述获取随机种子数据，包括：

获取随机种子数据，并确定所述随机种子数据的数据长度；

若所述随机种子数据的数据长度未达到预定最小数据长度，则重新获取随机种子数据，直至获取到的随机种子数据的数据长度达到所述预定最小数据长度。

8.根据权利要求1所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述获取所述待测试设备的目标设备标识信息和目标内存空间信息，包括：

获取测试设备标识信息和与所述测试设备标识信息对应的内存空间标识信息；

通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息；

根据所述内存空间标识信息获取所述待测试设备的内存空间信息，并从所述内存空间信息中获取目标内存空间信息。

9.根据权利要求8所述的云原生平台中虚拟机的模糊测试方法，其特征在于，在获取所述待测试设备的目标设备标识信息和目标内存空间信息之前，所述方法还包括：

判断系统环境参数的参数值中是否包括测试设备标识信息，其中，通过将所述测试设备标识信息与由所述虚拟机模拟而成的设备的标识信息进行对比，得到目标设备标识信息是在所述系统环境参数的参数值中包括测试设备标识信息的情况下进行的。

10.根据权利要求2所述的云原生平台中虚拟机的模糊测试方法，其特征在于，在执行模糊测试流程之前，所述方法还包括：

获取直接存储器访问读写空间的基地址，所述直接存储器访问读写空间用于存储随机种子数据；

所述获取随机种子数据，包括：

根据所述基地址从所述直接存储器访问读写空间获取随机种子数据。

11.根据权利要求1所述的云原生平台中虚拟机的模糊测试方法，其特征在于，所述根据所述赋值后目标结构体随机执行所述待测试设备的设备处理流程，包括：

获取随机数；

根据所述随机数随机进入所述待测试设备的设备处理流程，并根据所述赋值后目标结构体执行所述设备处理流程。

12.一种云原生平台中虚拟机的模糊测试装置，其特征在于，所述装置包括：

运行单元，用于运行云原生平台中由虚拟机模拟得到的待测试设备；

信息获取单元，用于获取所述待测试设备的目标设备标识信息和目标内存空间信息；

获取和构造单元，用于根据所述目标设备标识信息获取所述待测试设备的设备结构体，并根据所述设备结构体中的可操作属性构造目标结构体；其中，所述设备结构体为属性集合，所述属性集合包括至少一个可操作属性；

执行单元，用于在所述待测试设备的目标内存空间信息指示的目标内存空间中对所述虚拟机执行模糊测试流程；

13.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至11中任一项所述的云原生平台中虚拟机的模糊测试方法。

14.一种电子设备，其特征在于，包括：

一个或多个处理器；

存储装置，用于存储一个或多个程序，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现如权利要求1至11中任一项所述的云原生平台中虚拟机的模糊测试方法。

15.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，所述计算机指令存储在计算机可读存储介质中，计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如权利要求1至11中任一项所述的云原生平台中虚拟机的模糊测试方法。