一种在目标平台上启动应用程序的方法及装置与流程

本说明书一个或多个实施例涉及数据安全领域，尤其涉及一种在目标平台上启动应用程序的方法及装置。

背景技术：

当前，在多方计算、数据外包、敏感数据处理等场景下，在计算平台上保障程序的代码/数据不被攻击者窃取或破坏，成为技术上的刚需。现有技术中，虽然有一些方案用于保障程序的代码/数据的安全，但是仍旧存在保障有漏洞、依赖远程验证服务等缺点。

因此，对于计算平台上的程序的代码/数据进行保护是亟需解决的问题。

技术实现要素：

本说明书中的实施例旨在提供更有效地保障计算平台上的程序的代码/数据的方法，解决现有技术中的不足。

根据第一方面,一种在目标平台上启动应用程序的方法,所述目标平台至少包含可验证启动芯片和可信执行环境，所述方法包括:

按预设的启动次序依次启动多个系统启动项,其中,对于多个系统启动项中包含的第一启动项的启动包括,对于其下一个启动项进行度量,并将度量结果记录到可验证启动芯片中；

基于可信执行环境启动验证代理程序；

基于可信执行环境启动第一用户应用程序，并由所述验证代理程序基于可信执行环境中的本地验证，确定所述第一用户应用程序对应的第一验证信息。

在一个实施例中,所述方法还包括，将第一验证信息记录到可验证启动芯片中。

在一个实施例中,所述方法还包括，响应于所述目标平台的远程用户对所述可验证启动芯片的访问请求，向所述远程用户提供可验证启动芯片根据所述第一验证信息生成的第一记录；使得所述远程用户根据第一记录，确定第一用户应用程序的安全性，和/或，所述目标平台的安全性。

在一个实施例中，所述第一验证信息由所述验证代理程序维护；所述方法还包括，

响应于远程用户对所述可验证启动芯片的访问请求，向所述远程用户提供第二记录，所述第二记录为可验证启动芯片根据所述多个系统启动项中的尾启动项启动时所记录的第一度量结果生成；

所述验证代理程序响应于所述远程用户基于第一度量结果的连接请求，建立与该远程用户的信任通道，通过所述信任通道向其提供所述第一验证信息。

在一个实施例中,所述第二记录用于远程用户根据第二记录，确定所述目标平台的安全性。

在一个实施例中，所述第一验证信息用于远程用户根据第一验证信息，确定第一用户应用程序的安全性。

在一个实施例中，，根据第二记录，确定所述目标平台的安全性,包括，根据第二记录，验证目标平台启动的操作系统os和/或虚拟机监视器vmm的版本是否为预定版本，根据验证结果确定所述目标平台的安全性。

在一个实施例中，所述可验证启动芯片包括可信平台模块tpm芯片、可信密码模块tcm芯片、可信平台控制模块tpcm芯片、titan芯片中的一种。

在一个实施例中，所述方法，还包括，在启动第一用户应用程序之后：

基于可信执行环境启动第二用户应用程序，

由所述验证代理程序基于可信执行环境中的本地验证，确定所述第二用户应用程序对应的第二验证信息。

在一个实施例中，所述多个系统启动项中的首个启动项为可信度量根核心crtm。

在一个实施例中，所述多个系统启动项还包括，引导加载程序bootloader、操作系统os、虚拟机监视器vmm中的若干项。

在一个实施例中，验证代理程序至少包括可信部分；

所述启动验证代理程序，至少包括，在可信执行环境中执行所述可信部分；

所述多个系统启动项中最后一项的启动，包括，对于所述可信部分进行度量，并将度量结果记录到可验证启动芯片中。

在一个实施例中，第一用户应用程序至少包括可信部分；

基于可信执行环境启动第一用户应用程序，至少包括，在可信执行环境中执行所述可信部分；

所述验证代理程序基于可信执行环境中的本地验证，确定第一用户应用程序的第一验证信息，包括，

所述验证代理程序基于可信执行环境中的本地验证，根据所述可信部分，确定第一用户应用程序对应的第一验证信息。

在一个实施例中，所述验证代理程序基于可信执行环境中的本地验证，确定第一用户应用程序对应的第一验证信息，包括，验证代理程序调用软件保护扩展sgx的本地验证指令，得到第一用户应用程序对应的第一验证信息。

根据第二方面,提供了一种在目标平台上启动应用程序的装置，所述目标平台至少包含可验证启动芯片和可信执行环境,所述装置包括：

系统启动单元，配置为，按预设的启动次序依次启动多个系统启动项,其中,对于多个系统启动项中包含的第一启动项的启动包括,对于其下一个启动项进行度量,并将度量结果记录到可验证启动芯片中；

验证代理启动单元，配置为，基于可信执行环境启动验证代理程序；

用户应用启动单元，配置为，基于可信执行环境启动第一用户应用程序，并由所述验证代理程序基于可信执行环境中的本地验证，确定所述第一用户应用程序对应的第一验证信息。

根据第三方面,提供了一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行第一方面所述的方法。

根据第四方面,提供了一种计算设备，包括存储器和处理器，其特征在于，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现第一所述的方法。

利用以上各个方面中的方法、装置、计算设备、存储介质中的一个或多个，可以更为有效地解决保障计算平台上的程序的代码/数据的问题。

附图说明

为了更清楚说明本发明实施例的技术方案，下面将对实施例描述中所需使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的原理示意图；

图2示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的流程图；

图3示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的一种实施方式的流程图；

图4示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的又一种实施方式的流程图；

图5示出根据本说明书实施例的一种在目标平台上启动应用程序的装置的结构图；

具体实施方式

下面将结合附图，对本发明书提供的方案进行描述。

如前所述，目前的保障程序的代码/数据的安全的方法，仍旧存在保障有漏洞、依赖远程验证服务等缺点。发明人对于启动程序的代码/数据的现有的保障方法进行了研究，并得到以下结论。

目前，常用的计算平台上程序的代码/数据的保障方法，主要有基于可验证启动的方案和基于可信执行环境的方案。其中，可验证启动是指，具备逐级完整性校验的系统启动过程。基于可验证启动方案的原理为，系统从可信根出发，一步一步启动到用户程序，每启动一步都对下一步启动项进行度量、校验，并写入可验证启动芯片中的可信记录。以采用tpm(trustedplatformmodule)技术为例，即是将下一步启动项的哈希值写入tpm芯片中的平台配置寄存器pcr中。用户可以远程调取启动可信记录(该记录会被签名来保证完整性和真实性)来判定系统是否维持了预期的启动项及启动顺序。然而，可验证启动的缺点在于，只能保证启动时的安全，如果是启动之后完成的动态攻击，该方案很难检测和抵御。

可信执行环境是指加密或隔离的、因而被认为安全可信的执行环境，因此，代码和数据在加密或隔离的环境里不易受来自环境外的攻击。基于可信执行环境(trustedexecutionenvironment，简称tee)的方案的原理为，将高权限的操作系统os或虚拟机管理器(virtualmachinemonitor，简称vmm)排除在信任基(trustedcomputingbase，简称tcb)之外，让用户放心地在不可信的操作系统或vmm之上运行需要保护的代码和数据，并提供远程校验的能力。然而，基于可信执行环境的方案的首要缺点是只防御来自恶意操作系统或vmm的直接攻击，却无法抵御侧信道攻击(side-channelattack)。此外，基于可信执行环境的方案多少都依赖第三方厂商提供的远程校验服务，产生了外部可用性(availability)依赖，同时也需要假设这些第三方厂商不会作恶(例如,假设不发生共谋攻击collusionattack或内部攻击insiderattack)。

发明人为了解决上述技术方案存在的问题，在本说明书中的实施例中，提出一种在目标平台上启动应用程序的方法及装置。在该方案中，一方面,将用户应用程序的可信逻辑放在可信执行环境里隔离执行，从而防止恶意vmm/操作系统的(非侧信道)直接攻击；另一方面，用户在验证程序时可以同时获取启动链和平台的校验信息，从而能验证所启动的vmm/操作系统是预期状态(例如是一个可信的、tcb很小的、具备侧信道攻击监控的版本)，既而提高对侧信道攻击的防御能力。再一方面,程序验证建立在可验证启动和本地验证相结合的机制上，不需要依赖诸如ias之类的外部可信执行环境校验服务，大大提升了程序验证的可靠性和安全性。

下面进一步说明该方法的基本思想。

图1示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的原理示意图。如图1所示，目标平台至少包含可验证启动芯片、可信执行环境、以及多个启动项，多个启动项按启动次序包括多个系统启动项(如图中1所示crtm、bootloader/os，第一个系统启动项为可信度量根核心crtm)、验证代理程序、若干用户应用程序(用户应用1、用户应用2)。首先，依次启动多个系统启动项,在任意一个系统启动项的启动中,对于其下一个启动项进行度量,并将度量结果记录到可验证启动芯片中。然后，在tee中启动验证代理程序(或其可信部分)。最后，启动用户应用程序，验证代理程序至少通过调用可信执行环境中的本地验证，得到该用户应用程序对应的验证信息，验证代理程序可以维护用户应用程序对应的验证信息，也可以将其纪录到可验证启动芯片中。

使用该方法在目标平台上启动应用程序，在可信执行环境里执行用户应用程序，可以防止来自恶意vmm/操作系统的攻击，并且，在可信执行环境对应用程序的验证中，通过验证代理程序调用本地验证进行，不再依赖外部可信执行环境校验服务。还可以利用可验证启动芯片根据纪录到其中的度量/验证信息生成的可信纪录，验证所启动的程序和vmm/操作系统是否为预期状态，进而根据验证结果对侧信道攻击进行防御。

下面进一步阐述该方法的具体过程。

图2示出根据本说明书实施例的一种在目标平台上启动应用程序的方法的流程图。目标平台至少包含可验证启动芯片和可信执行环境，该方法至少包括如下步骤。

在步骤21，按预设的启动次序依次启动多个系统启动项,其中,对于多个系统启动项中包含的第一启动项的启动包括,对于其下一个启动项进行度量,并将度量结果记录到可验证启动芯片中。

如前所述，可验证启动是指具备逐级完整性校验的系统启动过程，其原理是对启动项进行可以据以施行逐级完整性校验的可信纪录，该可信纪录通常是依赖于独立的可验证启动芯片实现。在不同的实施例中，可验证启动芯片可以采用不同种类的可验证启动芯片，本说明书对于具体采用何种可验证启动芯片不做限定。在一个实施例中，可验证启动芯片可以包括可信平台模块tpm芯片、可信密码模块tcm芯片、可信平台控制模块tpcm芯片、titan芯片中的一种。

对启动项的度量(measurement)可以包括，对启动项内容的汇总、表征或是标识。根据一种实施方式，可以对下一个启动项进行哈希(hash)计算，从而获得其度量结果。在另一个例子中，也可以对下一个启动项的hash计算的结果，进行hash扩展后获取度量结果进行纪录。所谓的hash扩展是指根据先获得hash计算结果，和添加的计算项，进行一次以上嵌套的hash运算，以获得计算结果的过程。

在一个实施例中，在该步骤中，系统启动顺序如图1所示，可信度量根核心(crtm,corerootoftrustmeasurement)，是目标平台最开始的启动组件，也是整个系统的可信根基。crtm启动后会启动下一个启动项(例如,基本输入输出系统bios)，然后bios会启动进一步的启动项(例如引导加载程序bootloader、vmm、操作系统等等)，如此迭代，直到启动用户态程序。在此过程中，为了建立启动关系的信任链，像常规可验证启动一样，crtm启动后会对下一个启动项(例如bios)予以度量，然后bios会对进一步的启动项(例如bootloader)予以度量，直到度量到用户态程序。每一个度量结果都会写入相应的可信记录(可验证芯片中)里，事后可以出示给远程用户。

在一个实施例中，多个系统启动项中的首个启动项为可信度量根核心crtm。在另一个实施例中，多个系统启动项还可以包括，引导加载程序bootloader、操作系统os、虚拟机监视器vmm中的若干项。在又一个实施例中，也可以采用动态crtm(d-crtm，dynamiccrtm)方案，在d-crtm(dynamiccrtm)方案中，bios先于d-crtm启动，在bios启动中激发动态启动事件dlevent(dynamiclaunchevent)，从而启动d-crtm，但是bios启动中，并不会对于下一个启动项的度量，并记录到可启动验证芯片。也就是说，无论是采用常规crtm(或称静态crtm，s-crtm，staticcrtm)、或是d-crtm，对于下一个启动项的度量，并记录到可启动验证芯片，均由crtm(s-crtm或d-crtm)启动开始。

在一个实施例中，在最后一个系统启动项的启动中，对于验证代理程序进行度量，并将度量结果记录到可验证启动芯片中。该实施例的详情将在本说明书后文中阐述。

在步骤22，基于可信执行环境启动验证代理程序。

可信执行环境(tee)，是主处理器(cpu)中的一个安全区域，作为一种隔离执行环境，它可以确保在内部加载的代码和数据在机密性和完整性方面得到保护。例如，tee提供了通过tee隔离执行的应用程序的完整性以及其资源的机密性。或者说，tee提供了一个执行空间，该执行空间为设备上运行的受信任应用程序提供了比操作系统(os)高的安全性。

在不同的实施例中，tee可以在不同的主处理器上实现，而在不同的主处理器上实现tee具有不同的具体实施方式。例如在某种cpu上实现tee的sgx方案，在另一种cpu实现tee的trustzone方案，等等。本说明书对tee的具体实施方式不做限制。

该步骤中，与常规可验证启动不同的是，在用户程序apps之前启动一个验证代理程序。验证代理程序和未来要启动的用户程序apps一样借助可信执行环境技术运行。在一个例子中，可以将验证代理程序的可信部分(trustedlogic)加载到可信执行环境里隔离加密执行。

与常规可验证方式启动不同之处还在于，常规可验证启动方式由在系统启动项的启动过程中直接进入对用户程序apps进行度量。而本说明书实施例中，如上文所述的，在多个系统启动项中最后一项的启动中，对于验证代理程序进行度量并将度量结果记录到可验证启动芯片中。也就是说系统项的最后度量和纪录结果的对象不同。在一个实施例中，验证代理程序可以至少包括可信部分。该实施例中，在步骤21中对于多个系统启动项中最后一项的启动，其具体实施方式可以是，对于所述可信部分进行度量，并将度量结果记录到可验证启动芯片中。

在步骤23，基于可信执行环境启动第一用户应用程序，并由验证代理程序基于可信执行环境中的本地验证，确定第一用户应用程序对应的第一验证信息。

该步骤中，在验证代理程序之后启动的用户应用程序，由验证代理程序至少通过调用可信执行环境中的本地验证，获取其验证信息。例如，在一个例子中，可以在sgx平台上调用sgx的本地验证(localattestation)，获取应用程序的验证信息。在另一个例子中，验证代理程序也可以在调用可信执行环境中的本地验证对该用户程序进行验证获得的信息的基础上，叠加其他数据项后进行扩展计算，如hash扩展计算后，获得该应用程序的验证信息。本质上，由于验证代理程序和用户应用程序运行在同一目标平台上的tee中，因此，验证代理程序可以通过调用tee中的本地验证(localattestation)来实现对用户应用程序的身份验证，而避免借助于第三方的远程验证。

在一个实施例中，第一用户应用程序可以至少包括可信部分；在可信执行环境中执行所述可信部分；验证代理程序基于可信执行环境中的本地验证，根据所述第一用户应用程序的可信部分，确定对应的第一验证信息。在一个具体的实施例中，验证代理程序可以调用软件保护扩展sgx的本地验证指令，得到第一用户应用程序对应的第一验证信息。

在一个实施例中，还可以在启动第一用户应用程序之后，基于可信执行环境启动第二用户应用程序，由所述验证代理程序基于可信执行环境中的本地验证，确定所述第二用户应用程序对应的第二验证信息。也就是说，在验证代理程序启动之后启动的各个用户应用程序，均由验证代理程序基于tee中的本地验证，确定其验证信息。这与可验证启动中，链式地依次验证下一启动程序的方式，再次形成不同。

在不同的实施方式中，用户应用程序对应的验证信息，可以被写入可验证启动芯片，也可以不被写入该芯片、而仅由验证代理程序维护，从而可以对上述启动程序进行远程验证的用户提供不同的远程校验方式。

因此，根据一种实施方式，如图3所示，可以将第一验证信息记录到可验证启动芯片中。在一个实施例中，当目标平台的远程用户希望对目标平台的安全性进行远程校验时，该用户可以对目标平台中的可验证启动芯片发出访问请求。响应于该访问请求，目标平台可以向所述远程用户提供可验证启动芯片根据所述第一验证信息生成的第一记录。如此，该远程用户可以根据该第一记录，确定第一用户应用程序的安全性，和/或，所述目标平台的安全性。

在该实施方式中的一个例子中，远程用户可以在其自己的平台上根据目标平台上的启动项的程序版本号，搭建与目标平台相同的运行环境，并据以获得第一记录的对应值，根据第一记录的对应值和第一记录，确定目标平台启动链上各启动项(包括系统启动项和用户应用程序启动项)的安全性。在一个例子中，如果第一记录的对应值和第一记录相匹配，则说明目标平台的启动链上各启动项均是完整和正确的，也就是说目标平台和其上启动的应用程序均是安全的；如果第一记录的对应值和第一记录不匹配，则说明目标平台启动链上各启动项中至少有一项是不完整或不正确的，也就是说目标平台和其上启动的应用程序中有一项或多项是不安全的。

在该实施方式中的另一个例子中，远程用户也可以从例如信任的第三方获得第一记录的对应值，其余的执行过程同于上一个例子中执行过程中相应的部分，这里不再赘述。

根据另一种实施方式，如图4所示，第一验证信息可以由验证代理程序维护。在一个实施例中，在目标平台的远程用户希望对目标平台的安全性进行远程校验时，该用户仍然可以对目标平台中的可验证启动芯片发出访问请求。响应于该访问请求，目标平台向该远程用户提供第二记录，所述第二记录为可验证启动芯片根据所述多个系统启动项中的尾启动项启动时所记录的第一度量结果生成。需要理解，尾启动项是最后一个系统启动项，在其之后启动的程序为验证代理程序，因此，尾启动项启动时所记录的第一度量结果，即对应于验证代理程序的度量结果。于是，远程用户可以基于该第一度量结果，向该验证代理程序发出连接请求。响应于该连接请求，验证代理程序可以建立与该远程用户的信任通道，通过所述信任通道向其提供所述第一验证信息。

在一个例子中，第一验证信息可以用于远程用户根据第一验证信息，确定第一用户应用程序的安全性。另一个例子中，第二记录可以用于第一远程用户根据第二记录，确定所述目标平台的安全性。在一个具体的例子中，第二记录可以用于第一远程用户根据第二记录，验证目标平台启动的操作系统os和/或虚拟机监视器vmm的版本是否为预定版本，根据验证结果确定所述目标平台的安全性。

具体的，远程用户可以在其自己的平台上根据目标平台上的各启动项的程序版本号，搭建与目标平台相同的运行环境，从而获得其自己平台上第二记录和第一验证信息的对应值，根据第二记录的对应值和第二记录，确定目标平台上启动链上系统启动项和验证代理程序的安全的。在一个例子中，如果第二记录的对应值和第二记录相匹配，则可确定目标平台上启动链上各系统启动项和验证代理程序均是完整的、正确的,也就是说可以确定目标平台运行的系统是安全的。然后，在另一个例子中，还可以根据第一验证信息的对应值和第一验证信息，确定第一用户应用程序的完整性和正确性，如果第一验证信息的对应值和第一验证信息相匹配，则可确定第一用户应用程序安全的。

在另一个例子中，远程用户也可以从例如信任的第三方获得第二记录和第一验证信息的对应值，其余的执行过程同于上一个例子中执行过程中相应的部分，这里不再赘述。

图5示出根据本说明书实施例的一种在目标平台上启动应用程序的装置的结构图。目标平台至少包含可验证启动芯片和可信执行环境，如图5所示，该装置500包括：

系统启动单元51，配置为，按预设的启动次序依次启动多个系统启动项,其中,对于多个系统启动项中包含的第一启动项的启动包括,对于其下一个启动项进行度量,并将度量结果记录到可验证启动芯片中；

验证代理启动单元52，配置为，基于可信执行环境启动验证代理程序；

用户应用启动单元53，配置为，基于可信执行环境启动第一用户应用程序，并由所述验证代理程序基于可信执行环境中的本地验证，确定所述第一用户应用程序对应的第一验证信息。

在一个实施例中，该装置500还可以包括，记录单元，配置为，将第一验证信息记录到可验证启动芯片中。

在一个例子中，该装置500还可以包括，第一响应单元，配置为，响应于所述目标平台的远程用户对所述可验证启动芯片的访问请求，向所述远程用户提供可验证启动芯片根据所述第一验证信息生成的第一记录；使得所述远程用户根据第一记录，确定第一用户应用程序的安全性，和/或，所述目标平台的安全性。

在一个实施例中，用户应用启动单元53，可以进一步配置为，所述第一验证信息由所述验证代理程序维护；

该装置500还可以包括，第二响应单元，配置为，响应于远程用户对所述可验证启动芯片的访问请求，向所述远程用户提供第二记录，所述第二记录为可验证启动芯片根据所述多个系统启动项中的尾启动项启动时所记录的第一度量结果生成；

第三响应单元，配置为，所述验证代理程序响应于所述远程用户基于第一度量结果的连接请求，建立与该远程用户的信任通道，通过所述信任通道向其提供所述第一验证信息。

在一个例子中，所述第二记录用于远程用户根据第二记录，确定所述目标平台的安全性。

在一个例子中，所述第一验证信息可以用于远程用户根据第一验证信息，确定第一用户应用程序的安全性。

第二响应单元，可以进一步配置为，根据第二记录，确定所述目标平台的安全性,包括，根据第二记录，验证目标平台启动的操作系统os和/或虚拟机监视器vmm的版本是否为预定版本，根据验证结果确定所述目标平台的安全性。

在一个实施例中，所述可验证启动芯片可以包括可信平台模块tpm芯片、可信密码模块tcm芯片、可信平台控制模块tpcm芯片、titan芯片中的一种。

在一个实施例中，用户应用启动单元，可以进一步配置为，在启动第一用户应用程序之后：基于可信执行环境启动第二用户应用程序，

用户应用启动单元，可以进一步配置为，由所述验证代理程序基于可信执行环境中的本地验证，确定所述第二用户应用程序对应的第二验证信息。

在一个实施例中，多个系统启动项中的首个启动项可以为可信度量根核心crtm。在一个例子中，多个系统启动项还可以包括，引导加载程序bootloader、操作系统os、虚拟机监视器vmm中的若干项。

在一个实施例中，验证代理程序可以至少包括可信部分；

验证代理启动单元，可以进一步配置为，在可信执行环境中执行所述可信部分；

系统启动单元，可以进一步配置为，对于所述可信部分进行度量，并将度量结果记录到可验证启动芯片中。

在一个实施例中，第一用户应用程序至少包括可信部分；

用户应用启动单元，可以进一步配置为，在可信执行环境中执行所述可信部分；所述验证代理程序基于可信执行环境中的本地验证，根据所述可信部分，确定第一用户应用程序对应的第一验证信息。

在一个实施例中，用户应用启动单元，可以进一步配置为，验证代理程序调用软件保护扩展sgx的本地验证指令，得到第一用户应用程序对应的第一验证信息。

本说明书另一方面提供一种计算机可读存储介质，其上存储有计算机程序，当所述计算机程序在计算机中执行时，令计算机执行上述任一项方法。

本说明书另一方面提供一种计算设备，包括存储器和处理器，所述存储器中存储有可执行代码，所述处理器执行所述可执行代码时，实现上述任一项方法。

需要理解，本文中的“第一”，“第二”等描述，仅仅为了描述的简单而对相似概念进行区分，并不具有其他限定作用。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本发明所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的技术方案的基础之上，所做的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。