应用程序的处理方法、装置、云环境及存储介质与流程

1.本技术实施例涉及通信技术，尤其涉及一种应用程序的处理方法、装置、云环境及存储介质。


背景技术：

2.云计算(cloud computing)是分布式计算的一种，通过云计算技术，可以将高效的数据处理应用程序(例如spark应用程序等)远程部署到云环境上，从而使用户通过云服务可以远程使用这些数据处理应用程序。云计算技术使得高效的数据处理应用程序的广泛部署成为可能。部署在云环境上的应用程序通常需要较高的稳定性和安全性。例如，这些应用程序需要在处理大量请求时不轻易崩溃，也不会在遭受外部攻击者攻击时泄露用户隐私数据等。由于计算机编程语言java语言具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点，因此，许多部署在云环境上的应用程序使用java语言进行编写。
3.云环境上部署的应用程序可能会遭遇特权攻击(privileged attacks)。由于java语言不能防止云环境的特权攻击，因此，为了避免云环境的特权攻击，与不可信运行环境隔离运行的可信运行环境(trusted execution environment，tee)近年成为保护应用程序的一个重要工具。英特尔的软件防护扩展(software guard extensions，sgx)是目前最流行的可信运行环境产品。sgx提供了一个飞地(enclave)执行的抽象(abstraction)，运行在enclave中的应用程序和数据存储在一个与普通执行环境隔离的内存区域中，使得可以控制操作系统，基本输入输出系统(basic input output system，bios)的特权攻击者都无法提取或篡改其数据。
4.目前飞地提供的执行环境为c/c 语言的执行环境。由于飞地的内存区域有限，因此，应用程序的开发者需要采用手动将应用程序的原程序代码划分为可信部分和不可信部分，并手动将可信部分的代码从java语言改写为c/c 语言的方式，将应用程序的可信部分运行在飞地中，以保障该应用程序具有一个较小的可信计算基础(trusted computing base，tcb)和攻击面(attack surface)。但是该手动改写代码的方式，导致代码改写量较大，代码改写效率较低。
5.故，如何在保持较小的tcb和攻击面、且又能够减少手动改写代码的工作量的情况下，将应用程序的可信部分运行在飞地中，是一个亟待解决的问题。


技术实现要素：

6.本技术实施例提供一种应用程序的处理方法、装置、云环境及存储介质，用于解决如何在保持较小的tcb和攻击面、且又能够减少手动改写代码的工作量的情况下，将应用程序的可信部分运行在飞地中的问题。
7.第一方面，本技术实施例提供一种应用程序的处理方法，该方法包括：首先，接收第一客户端发送的启动请求，该启动请求用于启动应用程序。其次，根据启动请求，在飞地
的高级语言运行环境中，加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系。其中，该舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。然后，根据舱单文件和飞地入口函数与静态依赖类的依赖关系，加载应用程序的飞地入口函数的静态依赖类。
8.通过该方法，在飞地运行的高级语言的运行环境中，可以基于应用程序的舱单文件、应用程序的飞地入口函数与静态依赖类的依赖关系，加载应用程序的可信部分的代码，从而将使用高级语言编写的应用程序的部分代码(即飞地入口函数与静态依赖类)直接运行在飞地中，可以提高应用程序的可信部分的安全性，使应用程序保持一个较小的tcb和攻击面，提高了应用程序在飞地中的执行效率，同时，也减少了应用程序的代码手动改写量，提高了将应用程序可以运行在飞地中的易用性。
9.作为一种可能的实现方式，在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，可以采用如下几种方式，获取应用程序的飞地入口函数与静态依赖类的依赖关系：第一种方式：根据应用程序的代码，获取应用程序中含有第一注释标注的类的描述文件。其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数。根据应用程序中含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。第二种方式：接收第一客户端发送的应用程序的飞地入口函数与静态依赖类的依赖关系。第三种方式：从存储数据库获取应用程序的飞地入口函数与静态依赖类的依赖关系。通过该可能的实现方式，提高了获取应用程序的飞地入口函数与静态依赖类的依赖关系的灵活性。
10.作为一种可能的实现方式，在加载应用程序的舱单文件之前，可以采用如下方式获取应用程序的舱单文件：接收第一客户端发送的应用程序的舱单文件。或者，从存储数据库获取应用程序的舱单文件。通过该可能的实现方式，提高了获取应用程序的舱单文件的灵活性。
11.作为一种可能的实现方式，上述飞地中可以预先运行有高级语言运行环境，或者，在上述加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系之前，还可以包括：在飞地中加载高级语言运行环境，验证高级语言运行环境的完整性。通过该可能的实现方式，扩展了在飞地中运行高级语言运行环境的方式，以及，将应用程序运行在飞地中的实现方式。
12.作为一种可能的实现方式，在上述加载应用程序的飞地入口函数的静态依赖类之后，该方法还可以包括：验证所加载的飞地入口函数的静态依赖类的完整性。在飞地入口函数的静态依赖类的完整性验证通过后，根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值。向第一客户端发送应用程序的哈希值，该应用程序的哈希值用于第一客户端验证飞地中加载的飞地入口函数的静态依赖类的完整性。通过该可能的实现方式，可以使计算设备和客户端分别验证飞地中加载的飞地入口函数的静态依赖类的完整性。
13.应理解，验证完整性的操作可以在加载应用程序的飞地入口函数和飞地入口函数的静态依赖类之后、且运行该应用程序的飞地入口函数之前的任意时刻执行，对此不进行限定。
14.作为一种可能的实现方式，该方法还可以包括：在飞地入口函数的静态依赖类的
完整性验证通过后，在通过第一线程调用应用程序的第一飞地入口函数时，切换至飞地中为第一线程分配第一内存区域。在第一内存区域中创建并执行第一飞地入口函数的静态依赖类的对象。通过该可能的实现方式，可以通过无操作系统参与的、且线程独立的内存管理方式为运行在飞地中的应用程序分配内存，从而避免应用程序的开发者手动管理内存，提高了内存管理效率。
15.作为一种可能的实现方式，若第一飞地入口函数还包括第一动态依赖类，该方法还包括：获取第一动态依赖类与静态依赖类的依赖关系；根据第一动态依赖类与静态依赖类的依赖关系，动态加载第一动态依赖类；验证第一动态依赖类的完整性；在第一动态依赖类的完整性验证通过后，在第一内存区域中创建并执行第一动态依赖类的对象。通过该可能的实现方式，可以在飞地中运行应用程序的飞地入口函数时，可以动态加载所需要的类函数。
16.作为一种可能的实现方式，第一飞地入口函数与第一飞地出口函数具有调用关系，该方法还包括：从飞地的高级语言运行环境切换至非飞地环境，在非飞地环境执行第一飞地出口函数，返回飞地的高级语言运行环境。通过该可能的实现方式，可以在飞地中运行应用程序的飞地入口函数时，可以执行飞地入口函数所调用的飞地出口函数。
17.作为一种可能的实现方式，该方法还包括：在第一飞地入口函数退出执行后，若第一飞地入口函数的对象均未被其他线程访问，则清除第一线程与第一内存区域的映射关系。通过该可能的实现方式，在执行完第一飞地入口函数后，可以及时清理为第一线程分配的第一内存区域，以将第一内存区域所包括的内存页可以分配给其他线程使用，从而可以及时的释放飞地的内存，提高了飞地内存中的垃圾收集的效率。
18.作为一种可能的实现方式，该方法还包括：在第一飞地入口函数退出执行后，若第一飞地入口函数的第一对象被其他线程访问，则同步停止执行飞地中的所有线程调用的飞地入口函数。确定访问第一对象的至少一个第二线程。根据至少一个第二线程的数量，对第一对象进行拷贝处理。清除第一线程与第一内存区域的映射关系。例如，根据至少一个第二线程的数量，对第一对象进行拷贝处理，可以包括：若第二线程的数量为1，则将第一对象拷贝至第二线程对应的第二内存区域；或者，若第二线程的数量大于1，则将第一对象拷贝至飞地的全局内存区域中。通过该可能的实现方式，在执行完第一飞地入口函数后，可以及时清理为第一线程分配的第一内存区域，以将第一内存区域所包括的内存页可以分配给其他线程使用，从而可以及时的释放飞地的内存，提高了飞地内存中的垃圾收集的效率。
19.第二方面，本技术实施例提供一种应用程序的处理方法，该方法包括：首先，根据应用程序的代码，获取应用程序中含有第一注释标注的类，和/或，含有第二注释标注的类。其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数，第二注释标注用于表征第二注释标注的类为飞地出口函数。然后，根据含有第一注释标注的类，和/或，含有第二注释标注的类，生成应用程序的舱单文件。其中，该舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。
20.通过该方法，任一能够获取到该应用程序的代码的设备(例如，应用程序的开发者的设备，或者，使用该应用程序的客户端等)，可以根据含有第一注释标注的类，和/或，含有第二注释标注的类，生成应用程序的舱单文件。
21.作为一种可能的实现方式，该方法还可以包括：根据含有第一注释标注的类的描
述文件，获取应用程序的飞地入口函数的静态依赖类。根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值，该应用程序的哈希值用于验证静态依赖类的完整性。通过该可能的实现方式，可以得到该应用程序的哈希值。后续，用户在远程使用该应用程序时，可以基于该哈希值和云环境所返回的哈希值，验证运行在云环境的飞地中的代码的完整性。
22.作为一种可能的实现方式，该方法还可以包括：根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。
23.第三方面，本技术实施例提供一种应用程序的处理装置，该装置包括：接收模块、处理模块。其中，接收模块，用于接收第一客户端发送的启动请求，启动请求用于启动应用程序。处理模块，用于根据启动请求，在飞地的高级语言运行环境中，加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系；根据舱单文件和飞地入口函数与静态依赖类的依赖关系，加载应用程序的飞地入口函数的静态依赖类。其中，舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。
24.作为一种可能的实现方式，处理模块，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，根据应用程序的代码，获取应用程序中含有第一注释标注的类的描述文件；根据应用程序中含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系；其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数。
25.作为一种可能的实现方式，处理模块，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，通过接收模块接收第一客户端发送的应用程序的飞地入口函数与静态依赖类的依赖关系；或者，处理模块，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，从存储数据库获取应用程序的飞地入口函数与静态依赖类的依赖关系。
26.作为一种可能的实现方式，处理模块，还用于在加载应用程序的舱单文件之前，通过接收模块接收第一客户端发送的应用程序的舱单文件；或者，处理模块，还用于在加载应用程序的舱单文件之前，从存储数据库获取应用程序的舱单文件。
27.作为一种可能的实现方式，处理模块，还用于在加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系之前，在飞地中加载高级语言运行环境，验证高级语言运行环境的完整性。
28.作为一种可能的实现方式，该装置还可以包括：发送模块。处理模块，还用于在加载应用程序的飞地入口函数的静态依赖类之后，验证加载的飞地入口函数的静态依赖类的完整性；在飞地入口函数的静态依赖类的完整性验证通过后，根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值。发送模块，用于向第一客户端发送应用程序的哈希值；该应用程序的哈希值用于第一客户端验证飞地中加载的所述飞地入口函数的静态依赖类的完整性。
29.作为一种可能的实现方式，处理模块，还用于在飞地入口函数的静态依赖类的完整性验证通过后，在通过第一线程调用应用程序的第一飞地入口函数时，切换至飞地中为第一线程分配第一内存区域，并在第一内存区域中创建并执行第一飞地入口函数的静态依赖类的对象。
30.作为一种可能的实现方式，第一飞地入口函数还包括第一动态依赖类。处理模块，还用于获取所述第一动态依赖类与静态依赖类的依赖关系；根据所述第一动态依赖类与静态依赖类的依赖关系，动态加载所述第一动态依赖类；验证所述第一动态依赖类的完整性，并在所述第一动态依赖类的完整性验证通过后，在所述第一内存区域中创建并执行所述第一动态依赖类的对象。
31.作为一种可能的实现方式，第一飞地入口函数与第一飞地出口函数具有调用关系。处理模块，还用于从飞地的高级语言运行环境切换至非飞地环境；在非飞地环境执行第一飞地出口函数；返回飞地的高级语言运行环境。
32.作为一种可能的实现方式，处理模块，还用于在第一飞地入口函数退出执行后，若第一飞地入口函数的对象均未被其他线程访问，则清除第一线程与第一内存区域的映射关系。
33.作为一种可能的实现方式，处理模块，还用于在第一飞地入口函数退出执行后，若第一飞地入口函数的第一对象被其他线程访问，则同步停止执行飞地中的所有线程调用的飞地入口函数；确定访问第一对象的至少一个第二线程；根据至少一个第二线程的数量，对第一对象进行拷贝处理；清除第一线程与第一内存区域的映射关系。例如，处理模块，具体用于在第二线程的数量为1时，将第一对象拷贝至第二线程对应的第二内存区域；或者，在第二线程的数量大于1时，将第一对象拷贝至飞地的全局内存区域中。
34.上述第三方面和第三方面的各可能的实现方式所提供的应用程序的处理装置，其有益效果可以参见上述第一方面和第一方面的各可能的实现方式所带来的有益效果，在此不加赘述。
35.第四方面，本技术实施例提供一种应用程序的处理装置，该装置包括：处理模块。其中，处理模块，用于根据应用程序的代码，获取应用程序中含有第一注释标注的类，和/或，含有第二注释标注的类；根据含有第一注释标注的类，和/或，含有第二注释标注的类，生成应用程序的舱单文件；其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数，第二注释标注用于表征第二注释标注的类为飞地出口函数，舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。
36.作为一种可能的实现方式，处理模块，还用于根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数的静态依赖类；根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值，该应用程序的哈希值用于验证静态依赖类的完整性。
37.作为一种可能的实现方式，处理模块，还用于根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。
38.上述第四方面和第四方面的各可能的实现方式所提供的应用程序的处理装置，其有益效果可以参见上述第二方面和第二方面的各可能的实现方式所带来的有益效果，在此不加赘述。
39.第五方面，本技术实施例提供一种应用程序的处理装置，该应用程序的处理装置包括：处理器、存储器。其中，存储器用于存储计算机可执行程序代码，程序代码包括计算机执行指令；当处理器执行计算机执行指令时，计算机执行指令使该应用程序的处理装置执行如第一方面或第一方面的各可能的实现方式所提供的方法。
40.第六方面，本技术实施例提供一种应用程序的处理装置，该应用程序的处理装置包括：处理器、存储器。其中，存储器用于存储计算机可执行程序代码，程序代码包括计算机执行指令；当处理器执行计算机执行指令时，计算机执行指令使该应用程序的处理装置执行如第二方面或第二方面各可能的实现方式所提供的方法。
41.第七方面，本技术实施例提供一种应用程序的处理装置，包括用于执行以上如第一方面或第一方面的各可能的实现方式所提供的方法的单元、模块或电路。该应用程序的处理装置可以为云环境中的计算设备，也可以为应用于云环境中的计算设备的一个模块，例如，可以为应用于云环境中的计算设备的芯片。
42.第八方面，本技术实施例提供一种应用程序的处理装置，包括用于执行以上如第二方面或第二方面的各可能的实现方式所提供的方法的单元、模块或电路。该应用程序的处理装置可以为云环境中的客户端，也可以为应用于云环境中的客户端的一个模块，例如，可以为应用于云环境中的客户端的芯片。
43.第九方面，本技术实施例提供一种网络装置，该网络装置上存储有计算机程序，在计算机程序被网络装置执行时，实现上述如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。该网络装置例如可以为芯片。
44.第十方面，本技术实施例提供一种网络装置，该网络装置包括处理器和接口电路。其中，接口电路，用于接收计算机执行指令并传输至处理器；处理器运行计算机执行指令以执行如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。该网络装置例如可以为芯片。
45.第十一方面，本技术实施例提供一种网络装置，该网络装置包括处理器和存储器。其中，存储器用于存储计算机执行指令；处理器用于执行存储器所存储的计算机执行指令，以使网络装置执行如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。该网络装置例如可以为芯片。
46.第十二方面，本技术实施例提供一种网络装置，该网络装置包括处理器、存储器和收发器。其中，收发器，用于接收信号或者发送信号；存储器，用于存储计算机程序；处理器，用于从存储器调用计算机程序执行如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。该网络装置例如可以为芯片。
47.第十三方面，本技术实施例提供一种计算机程序产品，该计算机程序产品包括计算机程序代码，当该计算机程序代码在计算机上运行时，使得计算机执行如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。
48.第十四方面，本技术实施例提供一种计算机可读存储介质，计算机可读存储介质用于存储计算机程序或计算机执行指令，当计算机程序或计算机执行指令在计算机上运行时，使得计算机执行如第一方面或第一方面的各可能的实现方式或第二方面或第二方面的各可能的实现方式所提供的方法。
49.第十五方面，本技术实施例提供一种云环境，该云环境包括：第三方面任一项所述的应用程序的处理装置和第四方面任一项所述的应用程序的处理装置。或者，该云环境包括：第五方面任一项所述的应用程序的处理装置和第六方面任一项所述的应用程序的处理装置。
50.本技术实施例提供的应用程序的处理方法、装置、云环境及存储介质，在飞地运行
的高级语言的运行环境中，可以基于应用程序的舱单文件、应用程序的飞地入口函数与静态依赖类的依赖关系，加载应用程序的可信部分的代码，从而将使用高级语言编写的应用程序的部分代码(即飞地入口函数与静态依赖类)直接运行在飞地中，可以提高应用程序的可信部分的安全性，使应用程序保持一个较小的tcb和攻击面，提高了应用程序在飞地中的执行效率，同时，也减少了应用程序的代码手动改写量，提高了将应用程序可以运行在飞地中的易用性。
附图说明
51.图1为本技术实施例提供的一种应用场景示意图；
52.图2为本技术实施例提供的一种编程模型的示意图；
53.图3为本技术实施例提供的一种应用程序的处理方法的流程示意图；
54.图4为本技术实施例提供的一种内存管理的示意图；
55.图5为本技术实施例提供的另一种应用程序的处理方法的流程示意图；
56.图6为本技术实施例提供的又一种应用程序的处理方法的流程示意图；
57.图7为本技术实施例提供的又一种应用程序的处理方法的流程示意图；
58.图8为本技术实施例提供的又一种应用程序的处理方法的流程示意图；
59.图9为本技术实施例提供的又一种应用程序的处理方法的流程示意图；
60.图10为本技术实施例提供的又一种应用程序的处理方法的流程示意图；
61.图11为本技术实施例提供的一种应用程序的处理装置的结构示意图；
62.图12为本技术实施例提供的另一种应用程序的处理装置的结构示意图。
具体实施方式
63.图1为本技术实施例提供的一种应用场景示意图。如图1所示，应用程序可部署在云环境中。云环境是云计算模式下利用基础资源向用户提供云服务的实体。云环境包括云数据中心和云服务平台，所述云数据中心包括云服务提供商拥有的大量基础资源(包括计算资源、存储资源和网络资源)，云数据中心包括的计算资源可以是大量的计算设备(例如服务器)。例如，以云数据中心包括的计算资源是运行有虚拟机的服务器为例，应用程序可以独立地部署在云数据中心中的服务器或虚拟机(virtual machine，vm)上，应用程序也可以分布式地部署在云数据中心中的多台服务器上、或者分布式地部署在云数据中心中的多台虚拟机上、再或者分布式地部署在云数据中心中的服务器和虚拟机上。
64.应用程序例如可以由云服务提供商在云服务平台抽象成一种云服务提供给用户，用户在云服务平台购买该云服务后(例如，可预充值再根据最终资源的使用情况进行结算)，云环境利用部署在云数据中心的应用程序向用户提供云服务。用户在远程使用该应用程序时，可以通过应用程序接口(application program interface，api)或者gui指定需要该应用程序执行的操作，云环境中的该应用程序执行相应操作，并通过api或者gui向用户返回执行结果。
65.在一些实施例中，上述部署在云环境中的应用程序也可以称为使用用户-服务器模型的应用程序。也就是说，运行应用程序的服务器为云环境中的服务器。
66.云环境上部署的应用程序可能会遭遇如下特权攻击(privileged attacks)：外部
的特权攻击者例如通过操作系统漏洞控制云环境的操作系统，从而可以攻击运行在操作系统上的应用程序。例如，提取和篡改运行在操作系统上的应用程序的数据等。或者，内部的特权攻击者(例如云环境的提供商(简称云提供商)的工作人员等)可以从物理上(physically)攻击运行在云环境中的应用程序。
67.目前，由于java语言不能防止云环境的特权攻击。因此，为了避免云环境的特权攻击，与不可信运行环境隔离运行的可信运行环境近年成为保护云应用程序的一个重要工具。英特尔的sgx是目前最流行的可信运行环境产品。sgx提供了一个飞地(enclave)执行的抽象(abstraction)。飞地具有如下特点：
68.1、飞地可以提供两个安全特性，分别为：保密性(confidentiality)和完整性(integrity)。
69.具体地，由于飞地中存储数据和代码的内存区域与普通不可信内存隔离。所以，运行在飞地中的数据和代码无法被特权攻击者窥探、提取和篡改。因此，飞地可以保障运行在飞地上的应用程序的保密性和完整性。
70.2、飞地可以提供远程验证(remote attestation)的机制。
71.具体地，该远程验证的机制可以度量(measure)运行在飞地中的运行环境的完整性，并生成一个验证报告(例如该运行环境的哈希值)提供给远程使用该应用程序的客户端，以使客户端验证运行在飞地中的运行环境。这里所说的度量也可以称为验证。
72.3、飞地可以为应用程序提供两个接口，分别为飞地入口函数(ecall)和飞地出口函数(ocall)。
73.具体地，飞地入口函数是由应用程序定义的、且在飞地中执行的可信函数。飞地出口函数是飞地入口函数在飞地中执行时调用的、且在不可信执行环境执行的函数。飞地出口函数通常用于执行特权指令，例如操作系统函数(system call)等。应理解，飞地入口函数可以存在至少一个具有调用关系的飞地出口函数，也可以无飞地出口函数，具体可以根据飞地入口函数是否需要执行特权指令相关。
74.例如，当应用程序的一个飞地入口函数被不可信环境调用时，在飞地的执行环境中执行该飞地入口函数，以对用户提供的加密数据进行解密，并进行计算。在计算过程中，若该飞地入口函数需要调用飞地出口函数，则退出飞地的执行环境，在不可信执行环境中执行相应地飞地出口函数。在执行完毕后，返回飞地的执行环境继续执行该飞地入口函数。最后，该飞地入口函数计算得到的结果进行加密后，退出飞地的执行环境并将加密的执行结果返回给用户。
75.4、飞地可以减少tcb和攻击面。
76.具体地，传统系统信任系统软件、操作系统和bios，因此，传统系统的tcb包括所有的这些软件硬件，所以这些系统软件与不可信的用户的交互都会成为攻击面。而tee提供的飞地只信任所有运行在飞地的代码(即tcb)，而攻击面仅为飞地与不可信环境的交互部分(如飞地出口函数和飞地入口函数)，因此，可以减少tcb和攻击面。
77.5、飞地执行可以减少计算开销和存储开销。
78.具体地，传统可信计算使用同态加密可信用户数据，使得云环境可以直接对加密数据进行运算。这些运算的操作通常有限，如加法，乘法及幂运算。另外，同态加密/解密的计算消耗较长时间，导致应用程序造的计算成本开销(10x～1000x)较大。同时，因为支持不
同计算需要使用不同的同态加密，造成额外的存储开销(2x-4x)。而飞地可以支持所有计算操作，因而，可以减少计算开销和存储开销。
79.目前，飞地提供的执行环境为c/c 语言的执行环境，即，飞地提供的飞地入口函数和飞地出口函数为c/c 接口函数。因此，现有技术中提供采用如下方式使应用程序可以运行在飞地中：
80.应用程序的开发者手动将应用程序的原程序代码划分为可信部分和不可信部分。其中，可信部分处理解密的敏感数据，不可信部分管理加密数据，操作系统调用和管理飞地。然后，应用程序的开发者手动将可信部分的代码从java语言改写为c/c 语言，并加入加解密逻辑，从而使应用程序的可信部分可以运行在飞地中。操作系统调用则由应用程序的开发者编写的飞地出口函数传送到非可信环境执行并验证其返回的结果。
81.通过上述手动划分和手动改写的方式，可以使应用程序的一部分代码运行在飞地中，用于处理和存储敏感的数据。因此，采用该方式可以使应用程序保持一个较小的tcb和攻击面。但是上述将可信部分的代码从java语言改写为c/c 语言的方式，需要将所有可信java代码，及其所有依赖的java库函数改写为c/c 代码，并把所有操作系统函数改写成飞地出口函数。而一个java依赖库可能包含数万行代码，因此，上述方式导致改写量较大，改写效率较低，致使将应用程序可以运行在飞地中的易用性存在问题。
82.此外，由于c/c 不具有自动管理内存的能力，因此，上述将应用程序的可信部分的代码从java语言改写为c/c 语言的方式，需要在飞地中运行该应用程序的可信部分时，手动管理运行该应用程序的可信部分的内存。
83.考虑到上述改写量较大的问题，还有一些方案提出将整个应用程序运行在飞地中。例如，多个系统(如graphene-sgx和scone)结合库系统(library os)或容器(container)把整个完整的应用程序运行在飞地中。具体地，将一个修改的库系统程序或容器守护程序(container daemon)运行在飞地中，然后，该程序将一个完整的、无需更改的应用程序或容器镜像(image)度量并加载并运行在飞地中。加载过程产生的哈希值将用于用户验证运行在飞地中的应用程序的完整性。
84.通过上述将一个完整的应用程序运行在飞地中的方式，虽然无需再手动划分应用程序的可信部分和不可信部分，也无需对应用程序的可信部分进行改写，但是，将一个应用程序完全运行在飞地中，又衍生了新的问题，具体如下：
85.(1)、造成一个较大的tcb和攻击面。
86.具体地，该应用程序的tcb包含应用程序及其依赖库、库系统(或容器守护程序)、及可信硬件本身等。其中，库系统(或容器守护程序)可能包含数十万行代码。tcb中任何代码中存在的漏洞，都可能造成该应用程序的崩溃或者遭受攻击，导致该应用程序的保密性和完整性遭受破坏。
87.(2)、应用程序在飞地中的执行效率低。
88.具体地，由于飞地执行通常提供有限的内存容量，例如内存容量最大约100m。目前，当飞地的内存不足时，将会采用比内存执行高1000x的页交换(pagging)对数据进行处理。即，将数据采用页交换的方式存储至不可信内存中，在使用该数据时，再从该不可信内存中读取至飞地中。
89.当采用上述方式在飞地中运行一个完整无更改的应用程序时，应用程序的所有数
据和代码，无论是否处理敏感数据，都需要存储在飞地的内存中。因此，采用该方式在飞地中运行应用程序，可能会因频繁页交换导致应用程序的执行效率低。例如，java虚拟机在初始化完成后占有超过100mb内存，因此使用上述方式运行一个完整java虚拟机，可能会因频繁页交换导致java虚拟机的执行效率较低。
90.故，如何在保持较小的tcb和攻击面、且又能够减少手动改写代码的工作量的情况下，将应用程序的可信部分运行在飞地中，是一个亟待解决的问题。
91.如前所述，目前飞地提供的执行环境为c/c 语言的执行环境，即，飞地提供的飞地入口函数和飞地出口函数为c/c 接口函数。该低层级的c/c 接口函数导致应用程序的可信部分的安全性存在问题。具体地，c/c 语言具有非内存安全的特性，因此，特权攻击者可以利用c/c 的漏洞对其进行攻击。c/c 语言还具有非类型安全的特性、也易影响应用程序的保密性和完整性。例如，一个采用c/c 语言编写的可信部分可能存在一个缓冲区溢出错误，这个错误可能会污染应用程序的执行栈，从而影响应用程序的执行控制流。
92.因此，考虑到前述方式存在的安全性、效率性和易用性的问题，结合面向对象的高级语言(例如java语言)具有内存安全、类型安全等特性，以及，当前大部分应用程序采用面向对象的高级语言编写的特点，本技术实施例提出在飞地中运行高级语言的运行环境，并将使用高级语言编写的应用程序的部分代码直接在飞地中运行的方法。即，飞地中运行高级语言的运行环境，以及，应用程序的可信代码是信任的，而其他部分(例如操作系统、bios、以及，其他运行在飞地外的运行环境等)是不可信的。此处所说的高级语言可以为任一面向对象的高级语言，例如java语言、scala语言等。
93.该方法具有如下效果：
94.1)、高级语言具有类型安全和内存安全的良好特性，易于保护应用程序的可信部分免于遭受传统内存攻击，也可以防止内存错误，提高了应用程序的可信部分的安全性。
95.2)、应用程序的开发者在对应用程序进行可信代码和非可信代码的划分后，若应用程序的可信部分无加解密逻辑，则应用程序的开发者仅需手动在可信部分加入加解密逻辑即可，若应用程序的可信部分本身存在加解密逻辑，则无需再手动改写应用程序，减少了应用程序的代码手动改写量，提高了将应用程序可以运行在飞地中的易用性。
96.3)、将应用程序的一部分代码运行在飞地中，可以使应用程序保持一个较小的tcb和攻击面，同时在运行时也不会占用飞地过多的内存，提高了应用程序在飞地中的执行效率。
97.为了实现上述方法，本技术实施例提出如下改进：
98.第一方面：提供两个基于注释(annotation)的编程接口，分别为第一接口jecall和第二接口jocall。其中，第一接口jecall对应第一注释@jecall，第二接口jocall对应第二注释@jocall。第一注释@jecall标注用于表征该第一注释@jecall标注的类为飞地入口函数，第二注释@jocall标注用于表征第二注释@jocall标注的类为飞地出口函数。即，使用第一注释标注的类为运行在飞地中的类，使用第二注释标注的类为运行在飞地中的类调用的在非飞地环境中运行在飞地中的类(例如操作系统调用等)。这里所说的非飞地环境也可以称为不可信环境。
99.应用程序的开发者可以使用第一注释@jecall和第二注释@jocall对应用程序中的类进行标注。这样，标注为jecall的类及其依赖类将自动运行在飞地中，而标注为jocall
的类在飞地中运行时，将退出飞地执行。
100.应理解，上述jecall、jocall、@jecall和@jocall仅是用于说明第一接口、第二接口、第一注释和第二注释，本技术实施例对第一接口、第二接口、第一注释和第二注释所采用的具体名称不进行限定。
101.示例性的，图2为本技术实施例提供的一种编程模型的示意图。如图2所示，以编程模型应用于一个key-value数据库的应用程序为例，应用程序的开发者可以在该编程模型中，采用上述所说的第一注释和第二注释对该应用程序的代码进行可信部分和不可信部分的划分。
102.例如，图2中的应用程序包括：handle_request函数、decrypt函数、store函数。其中，handle_request函数在执行时会调用decrypt函数，以及，store函数。假定handle_request函数被应用程序的开发者标注为jecall，store函数被标注为jocall，则说明handle_request函数与其所调用的decrypt函数都将运行飞地中。而handle_request函数调用的store函数将在不可信环境中运行。即，当handle_request函数在不可信环境被调用时，将会切换至飞地中执行该handle_request函数。在飞地中执行该handle_request函数的过程中，可以使用解密函数对客户端提供的加密数据进行解密。当store函数被调用时，将从飞地切换到不可信环境中执行该函数并返回结果。当jecall执行完成时，其退出飞地并返回加密的计算结果。
103.图2虽然以编程模型为例，对如何采用上述所说的第一注释和第二注释对该应用程序的代码进行可信部分和不可信部分的划分。应理解，应用程序的开发者也可以采用其他方式，使用第一注释和第二注释对该应用程序的代码进行可信部分和不可信部分的划分，对此不进行限定。
104.第二方面：以高级语言java语言为例，java语言编写的应用程序采用动态类加载的方式进行代码加载，而在飞地(即可信运行环境)中使用动态类加载会泄露飞地(即可信运行环境)的代码控制流信息。例如，假如一个敏感信息在0时执行函数a，否则执行b，而函数a和b的加载则会暴露敏感信息。同时，在飞地(即可信运行环境)进行动态加载使得可信用户无法知道或验证所有可能会被执行的代码。
105.因此，考虑到该问题，本技术实施例提供一种可以保证代码完整性的代码加载方式，该代码加载方式可以基于应用程序的舱单文件(manifest)、应用程序的飞地入口函数与静态依赖类的依赖关系，加载应用程序的可信部分的代码。这样，只有少部分的代码(即飞地入口函数与静态依赖类)需要在应用程序启动时被加载。
106.作为一种可能的实现方式，在应用程序的开发者采用上述第一注释和第二注释对应用程序完成标注后，可以采用下述方式获取应用程序的舱单文件(manifest)。图3为本技术实施例提供的一种应用程序的处理方法的流程示意图。该方法的执行主体可以为任一能够获取到该应用程序的代码的设备，例如，应用程序的开发者的设备，或者，使用该应用程序的客户端等。如图3所示，该方法包括：
107.s101、根据应用程序的代码，获取该应用程序中含有第一注释标注的类，和/或，含有第二注释标注的类。
108.例如，可以遍历应用程序的代码中是否存在第一注释、第二注释，以获取获取该应用程序中含有第一注释标注的类，和/或，含有第二注释标注的类。
109.s102、根据含有第一注释标注的类，和/或，含有第二注释标注的类，生成应用程序的舱单文件。
110.其中，应用程序的舱单文件(manifest)可以包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。示例性的，这里所说的描述信息例如可以包括：函数名、调用的参数列表(例如参数类型和执行顺序等)、返回类型等。
111.进一步地，可以根据含有第一注释标注的类的描述文件，获取该应用程序的飞地入口函数的静态依赖类。然后，根据该应用程序的每个飞地入口函数的静态依赖类的哈希值和舱单文件，生成该应用程序的哈希值h0，该哈希值h0用于验证静态依赖类的完整性。这里所说的哈希值h0例如可以是采用任意哈希算法得到的，例如，sha256哈希值，本技术实施例对此不进行限定。
112.具体地，类的描述文件通常描述有类的静态依赖类的信息。因此，可以根据含有第一注释标注的类的描述文件，获取该类的静态依赖类，进而根据这些静态依赖类的描述文件，再获取这些静态依赖类的静态依赖类，以此类推，直至获取到所有的静态静态依赖类。
113.示例性的，以含有第一注释标注的类为类a1为例，假定根据类a1的描述文件获知类a的静态依赖类有类b和类c，根据类b的描述文件获知类b的静态依赖类有类b1和类b2，根据类b2的描述文件获知类b2的静态依赖类有类b21和类b22，根据类b1描述文件获知类b1无静态依赖类，根据类c描述文件获知类c无静态依赖类，具体的依赖关系可以如下述表1所示：
114.表1
[0115][0116]
则在该示例下，类a1即为该应用程序的一个飞地入口函数，类a1的静态依赖类有类b、类b1、类b2、类b21、类b22、类c。
[0117]
假定该应用程序一共有5个飞地入口函数，分别为类a1、类a2、类a3、类a4、类a5，则可以根据类a1的每个静态依赖类的哈希值、类a2的每个静态依赖类的哈希值、类a3的每个静态依赖类的哈希值、类a4的每个静态依赖类的哈希值、类a5的每个静态依赖类的哈希值、采用步骤s102的方式所得到的舱单文件进行哈希运算，得到该应用程序的哈希值h0。后续，用户在远程使用该应用程序时，可以通过哈希值h0验证运行在飞地中的代码的完整性。具体如何验证，可以参见后续描述。
[0118]
可选地，作为一种可能的实现方式，还可以根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。该依赖关系例如可以采用临接表或者依赖图来表示，对此不进行限定。
[0119]
第三方面：提供无操作系统参与的、且线程独立的内存管理方式，从而避免应用程序的开发者手动管理内存。图4为本技术实施例提供的一种内存管理的示意图。如图4所示，
本技术实施例采用如下方式分配内存区域：当一个线程调用该应用程序的飞地入口函数时，可以在飞地中为该线程分配一个独立且可扩展的内存区域。也就是说，各线程之间的内存区域相互独立。
[0120]
例如，图4示出了线程1和线程2在分别调用应用程序的飞地入口函数时，在飞地内存中为线程1分配的内存区域，与，为线程2分配的内存区域相互独立。在该示例中，线程1与线程2调用的飞地入口函数可以相同，也可以不同。
[0121]
下面结合具体地实施例对如何加载应用程序的代码进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或者相似的概念或者过程可能在某些实施例不再赘述。
[0122]
图5为本技术实施例提供的另一种应用程序的处理方法的流程示意图。该方法的执行主体可以为云环境中的计算设备如图5所示，该方法包括：
[0123]
s201、接收第一客户端发送的启动请求，其中，该启动请求用于启动应用程序。
[0124]
例如，当用户需要使用该应用程序时，用户可以远程通过第一客户端发送启动该应用程序的启动请求。
[0125]
s202、根据启动请求，在飞地的高级语言运行环境中，加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系。
[0126]
应理解，此处所说的飞地的高级语言运行环境，与开发应用程序所使用的语言相同。例如，应用程序为采用高级语言java语言编写的应用程序，则飞地的高级语言运行环境为java语言的运行环境。
[0127]
该高级语言运行环境可以具有如下功能：
[0128]
1)加载应用程序的可信部分并传输到飞地中，产生一个对应的哈希值h
′
o
，用于客户端验证其所加载的可信部分完整性。
[0129]
2)从应用程序的不可信部分的执行切换到应用程序的可信部分的执行。即，从不可信环境切换到飞地的可信环境中执行该应用程序的可信代码。在切换过程中，可信部分的函数的描述信息和所需调用的参数从不可信内存复制到可信的飞地内存中。
[0130]
3)将运行在飞地的函数编译为二进制运行码，并运行在飞地中。
[0131]
可选地，飞地中可以预先运行有该高级语言运行环境，或者，计算设备可以在接收到该启动请求之后，在飞地中加载高级语言运行环境，并验证该高级语言运行环境的完整性。例如，可以调用预设的可信运行环境的远程验证协议，以验证该高级语言运行环境的完整性。
[0132]
示例性的，计算设备可以基于高级语言运行环境生成该运行环境的哈希值hx，并将该运行环境的哈希值发给第一客户端。相应地，第一客户端存储有一个哈希值hx'。若哈希值hx'与哈希值hx相同，则飞地中加载的该高级语言运行环境的完整性验证通过。然后，计算设备与第一客户端可以进行密钥交换。这样，计算设备与第一客户端此后的通信都可以使用交换的密钥进行加密。
[0133]
上述第一客户端所存储的哈希值hx'，可以是第一客户端自己运行高级语言运行环境生成的哈希值，也可以是采用其他方式获取的可信的、且用于验证飞地中加载的该高级语言运行环境的哈希值，本技术实施例对此不进行限定。
[0134]
在飞地的高级语言运行环境中所加载的应用程序的舱单文件，可以为利用前述图
3所示的方式线下生成的舱单文件。本实施例不限定计算设备获取该舱单文件的方式。作为一种可选的方式，计算设备在加载该舱单文件之前，可以接收第一客户端发送的该舱单文件。示例性的，第一客户端可以将该舱单文件携带在启动请求中发送给计算设备，也可以将该舱单文件与启动请求一同发送给计算设备，或者，第一客户端可以分别向计算设备发送该舱单文件与启动请求。
[0135]
作为另一种可选的方式，计算设备在加载该舱单文件之前，可以从云环境的存储数据库获取存储的该应用程序的舱单文件。此时，存储数据库所存储的该应用程序的舱单文件可以为云环境的维护人员、应用程序的开发者等预先存储在该存储数据库中的，或者，云环境中的一个计算设备在历史某一次启动该应用程序时，将所获取到的舱单文件存储在该存储数据库的。
[0136]
在飞地的高级语言运行环境中所加载的应用程序的飞地入口函数与静态依赖类的依赖关系，可以为利用前述所描述的方式线下生成的。本实施例不限定计算设备获取应用程序的飞地入口函数与静态依赖类的依赖关系的方式。作为一种可选的方式，计算设备在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，可以接收第一客户端发送的应用程序的飞地入口函数与静态依赖类的依赖关系。关于如何发送应用程序的飞地入口函数与静态依赖类的依赖关系，可以参见上述发送舱单文件的描述，对此不再赘述。
[0137]
作为另一种可选的方式，计算设备在加载该应用程序的飞地入口函数与静态依赖类的依赖关系之前，可以从云环境的存储数据库获取存储的该应用程序的飞地入口函数与静态依赖类的依赖关系。此时，存储数据库所存储的该应用程序的飞地入口函数与静态依赖类的依赖关系可以为云环境的维护人员、应用程序的开发者等预先存储在该存储数据库中的，或者，云环境中的一个计算设备在历史某一次启动该应用程序时，将所获取到的应用程序的飞地入口函数与静态依赖类的依赖关系存储在该存储数据库的。
[0138]
在飞地的高级语言运行环境中所加载的应用程序的飞地入口函数与静态依赖类的依赖关系，可以为在线生成的。即，计算设备在接收到启动请求之后在线生成的。作为一种可选的方式，计算设备在加载该应用程序的飞地入口函数与静态依赖类的依赖关系之前，可以根据该应用程序的代码，获取应用程序中含有第一注释标注的类的描述文件。然后，计算设备可以根据应用程序中含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。
[0139]
s203、根据舱单文件和飞地入口函数与静态依赖类的依赖关系，加载应用程序的飞地入口函数的静态依赖类。
[0140]
作为一种可能的实现方式，应用程序的代码可以存储在云环境中，例如，云环境的存储数据库等。计算设备在获取到舱单文件和飞地入口函数与静态依赖类的依赖关系后，可以基于该舱单文件和飞地入口函数与静态依赖类的依赖关系，将应用程序的飞地入口函数的静态依赖类加载在飞地中。
[0141]
继续参照图5，作为一种可能的实现方式，在完成应用程序的飞地入口函数的静态依赖类的加载之后，可以执行如下操作：
[0142]
s204、验证加载的飞地入口函数的静态依赖类的完整性。
[0143]
例如，计算设备可以在飞地中验证加载的飞地入口函数的静态依赖类的内容，与该静态依赖类的哈希值的合法性，以判断该静态依赖类的完整性。当该静态依赖类的内容，
以及，哈希值均合法时，确定该静态依赖类的完整性验证通过。在飞地入口函数的静态依赖类的完整性验证通过后，可以执行步骤s205。当该静态依赖类的内容非法，或，哈希值非法时，确定该静态依赖类的完整性验证失败。在所述飞地入口函数的静态依赖类的完整性验证失败后，例如可以向第一客户端返回应用程序的可信部分加载失败的消息。
[0144]
s205、根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值h0'。
[0145]
应理解，上述哈希值h0'的计算方式可以与前述获取哈希值h0的计算方式相同。该哈希值h0'可以标示应用程序所有加载进入飞地的代码。
[0146]
s206、向第一客户端发送该应用程序的哈希值h0'，该应用程序的哈希值h0'用于第一客户端验证飞地中加载的飞地入口函数的静态依赖类的完整性。
[0147]
例如，第一客户端侧存储有采用前述方式线下生成的哈希值h0。当第一客户端接收到计算设备发送的应用程序的哈希值h0'时，可以将哈希值h0'与哈希值h0进行比较。若两者相同，则飞地中加载的飞地入口函数的静态依赖类的完整性验证通过，若两者不同，则飞地中加载的飞地入口函数的静态依赖类的完整性验证失败。
[0148]
应理解，步骤s204-步骤s206可以在加载应用程序的飞地入口函数的静态依赖类之后、且运行该应用程序的飞地入口函数之前的任意时刻执行，对此不进行限定。
[0149]
下面通过一个具体的示例来对本实施例的方法进行示例说明，其中，计算设备上运行有jvm，采用java语言编写的应用程序部署在jvm的飞地上。图6为本技术实施例提供的又一种应用程序的处理方法的流程示意图。如图6所示，计算设备的jvm在接收到客户端发送的应用程序的启动请求之后，可以执行如下步骤：
[0150]
①
在飞地中加载高级语言运行环境。
[0151]
②
根据加载的应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系，将应用程序的飞地入口函数的静态依赖类加载到飞地中。
[0152]
③
验证所加载的飞地入口函数的静态依赖类的完整性，并在完整性验证通过后，根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值h0'。
[0153]
④
与客户端之间进行高级语言运行环境的验证，以及，密钥的交换。
[0154]
应理解，
④
所示的动作也可以在
①
之后、
⑤
之前的任一时刻执行。
[0155]
⑤
将应用程序的哈希值h0'发送给客户端，以使客户端基于存储的哈希值h0与哈希值h0'，对飞地中加载的飞地入口函数的静态依赖类的完整性进行验证。
[0156]
⑥
在客户端完成应用程序的可信部分的完整性验证后，将加载的飞地入口函数的静态依赖类编译为二进制运行码，并运行在飞地中。
[0157]
本技术实施例的方法，在飞地运行的高级语言的运行环境中，可以基于应用程序的舱单文件(manifest)、应用程序的飞地入口函数与静态依赖类的依赖关系，加载应用程序的可信部分的代码，从而将使用高级语言编写的应用程序的部分代码(即飞地入口函数与静态依赖类)直接运行在飞地中，可以提高应用程序的可信部分的安全性，使应用程序保持一个较小的tcb和攻击面，提高了应用程序在飞地中的执行效率，同时，也减少了应用程序的代码手动改写量，提高了将应用程序可以运行在飞地中的易用性。
[0158]
上述内容描述的是如何将使用高级语言编写的应用程序的部分代码(即飞地入口函数与静态依赖类)运行在飞地中的内容。下面具体描述在上述飞地入口函数与静态依赖
类的完整性验证通过后，计算设备如何调用飞地入口函数的过程。
[0159]
图7为本技术实施例提供的又一种应用程序的处理方法的流程示意图。如图7所示，该方法包括：
[0160]
s301、在通过第一线程调用应用程序的第一飞地入口函数时，切换至飞地中为第一线程分配第一内存区域。即，从非飞地环境切换至飞地的高级语言的运行环境中。
[0161]
上述第一飞地入口函数可以为该应用程序的任一飞地入口函数。
[0162]
可选地，第一内存区域可以包括至少一个内存页，每个内存页例如可以为32千字节(kilobyte，kb)的内存。
[0163]
例如，计算设备可以初始为第一内存区域分配一个内存页。在执行该第一线程所调用的第一飞地入口函数的过程中，若存在内存分配需求，可以为该线程添加内存页。即，动态扩展第一内存区域的大小。例如，可以在距离该内存区域最近的内存页中寻找空闲内存页分配给第一线程，以确保第一内存区域的连续性。若距离该内存区域最近的内存页无法满足第一线程的内存需求，则可以在飞地的内存中重新为第一线程寻找多个连续的内存页作为第一内存区域。
[0164]
s302、在第一内存区域中创建并执行第一飞地入口函数的静态依赖类的对象。
[0165]
计算设备在通过上述方式为第一线程分配第一内存区域后，可以在第一内存区域中创建并执行第一飞地入口函数的静态依赖类的对象。关于如何创建类的对象可以参见现有技术的描述，在此不再赘述。
[0166]
应理解，在一些实施例中，第一飞地入口函数可能还存在无需创建对象即可执行的静态依赖类，针对此类型的静态依赖类，在执行第一飞地入口函数时，直接执行即可，对此不再赘述。另外，除了静态依赖类之外，可能还包括动态依赖类和/或具有调用关系的第一飞地出口函数。下面对在执行第一飞地入口函数的过程中，如何执行动态依赖类以及飞地出口函数进行说明：
[0167]
针对动态依赖类：
[0168]
图8为本技术实施例提供的又一种应用程序的处理方法的流程示意图。以第一动态依赖类为例，即，第一飞地入口函数还包括第一动态依赖类。如图8所示，计算设备可以执行如下操作：
[0169]
s401、获取第一动态依赖类与静态依赖类的依赖关系。
[0170]
例如，计算设备可以基于第一线程调用第一飞地入口函数时所请求执行的操作，确定第一飞地入口函数待执行的动态类，从而获取此动态依赖类与静态依赖类的依赖关系。应理解，此处所说的依赖关系包括该动态依赖类与其所有静态依赖类的依赖关系。
[0171]
以java语言为例，则此处所说的动态依赖类例如可以为第一飞地入口函数反射动态调用的类文件。
[0172]
关于如何获取此动态依赖类与静态依赖类的依赖关系，可以参见前述关于在线获取静态依赖类的描述，对此不再赘述。
[0173]
s402、根据第一动态依赖类与静态依赖类的依赖关系，动态加载第一动态依赖类。
[0174]
作为一种可能的实现方式，应用程序的代码可以存储在云环境中，例如，云环境的存储数据库等。计算设备在获取到第第一动态依赖类与静态依赖类的依赖关系后，可以基于该第一动态依赖类与静态依赖类的依赖关系，将第一动态依赖类加载在飞地中。
[0175]
示例性的，可以提供一个加载动态依赖类的接口，该接口例如可以为loadclass(classname)。其中，classname为待加载的动态依赖类的名字。这样，计算设备可以通过这个接口将该classname加载进入飞地中。
[0176]
s403、验证第一动态依赖类的完整性。
[0177]
例如，计算设备可以在飞地中验证所加载的第一动态依赖类的静态依赖类的内容，与该静态依赖类的哈希值的合法性，以判断该第一动态依赖类的完整性。当该第一动态依赖类的静态依赖类的内容，以及，第一动态依赖类的静态依赖类的哈希值均合法时，确定该第一动态依赖类的完整性验证通过。在第一动态依赖类的完整性验证通过后，可以执行步骤s404。当该第一动态依赖类的静态依赖类的内容非法，或，第一动态依赖类的静态依赖类的哈希值非法时，确定该第一动态依赖类的完整性验证失败。在第一动态依赖类的完整性验证失败后，例如可以向第一客户端返回第一动态依赖类加载失败的消息。
[0178]
可选地，在该第一动态依赖类的完整性验证通过后，可以根据该第一动态依赖类所依赖的静态依赖类的哈希值，生成该第一动态依赖类的哈希值hc，并将该哈希值hc发送给通过第一线程调用第一飞地入口函数的客户端，以使该客户端验证飞地中加载的该第一动态依赖类的完整性。关于如何验证可以参见前述客户端验证飞地入口函数的静态依赖类的方式，其实现方式类似，对此不再赘述。
[0179]
s404、在第一内存区域中创建并执行第一动态依赖类的对象。
[0180]
关于如何创建动态依赖类的对象可以参见现有技术的描述，在此不再赘述。
[0181]
针对第一飞地入口函数调用的飞地出口函数：
[0182]
以第一飞地入口函数调用的第一飞地出口函数为例，则在飞地中执行第一飞地入口函数的过程中，计算设备还可以执行如下操作：
[0183]
计算设备可以先从飞地的高级语言运行环境切换至非飞地环境，即不可信环境。然后，计算设备可以在非飞地环境执行第一飞地出口函数。最后，返回飞地的高级语言运行环境中继续执行第一飞地入口函数。关于如何切换至非飞地环境执行飞地出口函数，其实现方式与现有技术中切换至非飞地环境执行飞地出口函数的方式类似，对此不再赘述。
[0184]
上述内容描述了计算设备如何在应用程序的运行过程中，通过第一线程调用应用程序的第一飞地入口函数。下面对在完成第一飞地入口函数的调用后，即执行完第一飞地入口函数后，如何进行垃圾回收(即清理为第一线程分配的第一内存区域)进行解释和说明：
[0185]
图9为本技术实施例提供的又一种应用程序的处理方法的流程示意图。如图9所示，在第一飞地入口函数退出执行后，计算设备可以执行如下操作：
[0186]
s501、判断第一飞地入口函数的对象是否被其他线程访问。若否，则执行s505，若是，则执行s503。
[0187]
此处所说的对象可以是创建的第一飞地入口函数的静态依赖类的对象，或者是，第一飞地入口函数的动态依赖类的对象。此处所说的其他线程是指飞地中正在调用该应用程序的飞地入口函数的线程。该其他线程与第一线程调用的可以是应用程序相同的飞地入口函数，也可以是不同的飞地入口函数。
[0188]
在本实施例中，若第一飞地入口函数的对象未被任何线程访问，说明第一飞地入口函数的对象未共享给其他线程，此时，第一内存区域为第一线程独立的内存区域，直接清
理第一内存区域对其他线程不会造成影响。若第一飞地入口函数的对象被至少一个其他线程访问，说明第一飞地入口函数的对象共享给其他线程。此时，第一内存区域非第一线程独立的内存区域，即，直接清理第一内存区域对其他线程会造成影响。在一些实施例中，此处所说的被其他线程访问也可以描述为被其他线程调用的该应用程序的飞地入口函数访问，本技术实施例对此不进行限定。
[0189]
继续参照图4，例如，线程1的对象被被线程2访问，说明该对象共享给了线程2。此时，线程1的内存区域非线程1独立的内存区域，即，直接清理线程1的内存区域对线程2会造成影响。
[0190]
s502、同步停止执行飞地中的所有线程调用的飞地入口函数。
[0191]
应理解，此处所说的停止执行的所有线程是指飞地中所有调用该应用程序的飞地入口函数的线程(即前述所说的其他线程)。这些线程可以是调用的相同的飞地入口函数，也可以是调用的不同的飞地入口函数，也可以是部分线程调用的是相同的飞地入口函数，部分是调用的不同的飞地入口函数。
[0192]
s503、确定访问第一对象的至少一个第二线程。
[0193]
s504、根据至少一个第二线程的数量，对第一对象进行拷贝处理。
[0194]
继续参照图4，在本技术实施例中，该飞地中的内存区域还可以包括全局内存区域，该全局内存区域可以用于存储静态变量和生存期长于一个线程的对象。
[0195]
例如，若第二线程的数量为1，则将第一对象拷贝至第二线程对应的第二内存区域中。若第二线程的数量大于1，则将第一对象拷贝至飞地的全局内存区域中，以使多个第二线程通过访问全局内存区域即可访问第一对象，节省了飞地的内存空间。
[0196]
在执行该步骤s504之后，可以执行步骤s505，以清理为第一线程分配的第一内存区域。
[0197]
s505、清除第一线程与第一内存区域的映射关系。
[0198]
在完成第一线程与第一内存区域的映射关系的清除之后，第一内存区域所包括的内存页可以分配给飞地中的其他线程使用，从而可以及时的释放飞地的内存，提高了垃圾收集的效率。
[0199]
通过上述方式，在执行完第一飞地入口函数后，可以及时清理为第一线程分配的第一内存区域，以将第一内存区域所包括的内存页可以分配给其他线程使用，从而可以及时的释放飞地的内存，提高了飞地内存中的垃圾收集的效率。
[0200]
由于大数据处理的应用程序在大数据计算的过程中，多个线程共享的对象少而大部分飞地对象的生存期通常在一个飞地入口函数中，因此，采用该方式可以提高大数据处理的应用程序的垃圾收集的效率。
[0201]
作为一种可能的实现方式，本技术实施例提出一种无操作系统参与的多线程垃圾收集同步方式，该方式通过记录不同线程是否存在跨区域的写入操作来捕捉一个飞地入口函数的对象是否逃脱(escape)原来的内存区域，即，是否被其他线程访问。
[0202]
当该飞地入口函数存在逃脱对象时(即当存在被其他线程访问的对象)，需要同步停止所有线程的执行，并把逃脱对象回收并清理其他无用的对象(即未被其他线程访问的对象)。这样，在该飞地入口函数退出执行后，为调用该飞地入口函数的线程分配的内存区域被自动清理。
[0203]
具体地，本技术实施例为捕捉飞地入口函数是否存在逃脱对象，计算设备在应用程序的可信部分的代码中插入一个对全局变量的检查，通过该全局变量捕捉飞地入口函数是否存在逃脱对象。
[0204]
以计算设备通过一个采用多线程同步机制将逃脱对象回收的垃圾收集(garbage collect，gc)的线程实现该方法为例，示例性的，这里所涉及的全局变量例如可以如下述表2所示：
[0205]
表2
[0206]
变量名称变量的含意needgcgc正在被调用nthd在飞地中执行的线程总数ngcthd在可飞地中停止执行的线程总数
[0207]
这样，当一个对象(假定为目标对象)写入到另外一个对象的成员变量时，计算设备可以检查目标对象所属的内存区域。假如，目标对象所属的内存区域的标识(例如内存区域的id或索引等)与被写入的内存区域的标识不同时，则将包含目标对象的内存区域和被写入该目标对象的内存区域的记录写入到目标对象所属的线程的逃脱对象列表中，以及，被写入该目标对象的内存区域对应的线程的逃脱对象列表中。
[0208]
当目标对象所属的线程退出时，计算设备可以基于该逃脱对象列表判断是否存在逃脱对象。当不存在逃脱对象时，即列表为空时，清除该线程与分配的内存区域的映射关系即可。当存在逃脱对象时，即列表不为空时，调用多线程同步机制，将逃脱对象回收(即gc线程)。
[0209]
具体地，首先，同步停止所有线程的执行，以避免其他线程同时访问这些逃脱的对象。当所有线程停止后，扫描所有线程的执行栈和逃脱对象列表，发现所有属于当前线程的内存区域的对象。对每一个逃脱对象，假如其逃脱到一个其他线程的内存区域，则将其被拷贝到该线程的内存区域。若该逃脱对象逃脱到多个线程的内存区域，则将其拷贝到飞地的的全局内存区域中。
[0210]
示例性的，以表2所示的全局变量为例，假定计算设备调用gc针对第一线程进行多线程同步时，可以先尝试把全局变量needgc从0设置为1。
[0211]
1)假如needgc设置成功，则说明成功调用多线程同步。然后，计算设备对全局变量ngcthd进行原子加一操作。相应地，nthd在第一线程开始执行第一飞地函数时，执行原子加一操作。当变量ngcthd与nthd相等时，则说明飞地中的所有线程均已停止执行，则可以开始回收逃脱对象。在完成逃脱对象的回收后，减少ngcthd和nthd并设置needgc为0，表示除第一线程之外的其他线程可以恢复执行。
[0212]
2)假如needgc设置失败时，说明有其他线程调用多线程同步机制，则增加ngcthd的值，在needgc变为0后，再减少ngcthd的值，并返回执行尝试把全局变量needgc从0设置为1的步骤。
[0213]
针对飞地中运行的线程，计算设备在生成的应用程序的可信代码中的循环检查和函数入口中插入了对needgc的检查(非原子)。当needgc为1时，该线程停止执行直到needgc变为0。同时，该线程增加ngcthd的值，以通知gc该线程已停止执行。当needgc为0时，该线程恢复执行。
[0214]
通过上述方式，在执行完第一飞地入口函数后，可以及时清理为第一线程分配的第一内存区域，以将第一内存区域所包括的内存页可以分配给其他线程使用，从而可以及时的释放飞地的内存，提高了飞地内存中的垃圾收集的效率。
[0215]
另外，由于上述垃圾收集的方式无需操作系统参与，即，解除了垃圾收集操作与操作系统的调用依赖，这样，在进行垃圾收集时无需与操作系统进行交互，从而可以在进行垃圾收集免于特权攻击中的侧信道(side-channel)攻击和埃古(iago)攻击。
[0216]
应理解，此处所说的侧信道攻击是指：攻击者通过观察侧信道(例如执行时间，飞地出口函数等)，猜测飞地中运行的应用程序的隐私数据的攻击方式。例如，当一个敏感数据为1时，两个飞地出口函数被执行，当该敏感数据为0时，一个飞地出口函数被执行。攻击者可以观察飞地出口函数的执行次数来猜测该敏感数据的值。
[0217]
此处所说的埃古攻击是指：攻击者操纵不可信操作系统给飞地中运行的应用程序提供输入，使得飞地中运行的应用程序的控制流发生改变的攻击方式。例如，假如飞地中运行的应用程序依赖一个文件输入，而这个文件包含一个整型数。当该整型数为1时，飞地中运行的应用程序执行do_one函数，当该整型数为0时，飞地中运行的应用程序执行do_zero。因此，当攻击者操纵不可信操作系统更改提供给飞地中运行的应用程序的输入，则飞地程序的完整性将被破坏。
[0218]
下面通过一个具体的示例来对第一线程调用第一飞地入口函数的过程中的内存管理以及垃圾收集的流程进行简要说明：
[0219]
图10为本技术实施例提供的又一种应用程序的处理方法的流程示意图。如图10所示，该方法包括：
[0220]
s601、从非飞地环境中切换至飞地中。
[0221]
s602、为第一线程分配第一内存区域。
[0222]
例如，计算设备可以初始为第一内存区域分配一个内存页。该内存页例如可以为32kb的内存。
[0223]
s603、执行第一飞地入口函数。
[0224]
在执行第一飞地入口函数的过程中，执行如下操作：
[0225]
s6031、在创建对象时，判断第一内存区域的空闲内存是否充足。若否，则执行s6032，若是，则执行s6033。
[0226]
此处所说的对象可以是静态依赖类的对象或者是动态依赖类的对象。
[0227]
s6032、扩展第一内存区域的大小。
[0228]
s6033、在第一内存区域中创建并执行该对象。
[0229]
返回继续执行第一飞地入口函数。
[0230]
s604、在第一线程退出飞地环境后，确定第一飞地入口函数是否存在逃脱对象。若是，执行s605，若否，则执行s606。
[0231]
即在第一飞地入口函数执行完毕后，执行该步骤。
[0232]
s605、调用多线程同步机制，将逃脱对象回收。
[0233]
s606、清除第一线程与第一内存区域的映射关系。
[0234]
至此，完成了在第一线程调用第一飞地入口函数的过程中的内存管理以及垃圾收集。
[0235]
应理解，上述图10仅是为了说明内存管理以及垃圾收集的流程逻辑，省略了实际执行过程中与内存管理无关的内容，比如，第一飞地入口函数执行过程中调用飞地出口函数的内容等，具体可以参见前述实施例中关于每个部分的详细介绍，在此不再赘述。
[0236]
需要说明的是，虽然本技术实施例以可信运行环境飞地为例，对如何在可信运行环境中运行采用高级语言编写的应用程序进行了说明和介绍。但是本领域技术人员可以理解的是，本技术实施例的方法也可以应用于其他可信运行环境，对此不加以限定。
[0237]
图11为本技术实施例提供的一种应用程序的处理装置的结构示意图。如图11所示，该应用程序的处理装置可以为前述所说的计算设备，也可以为该计算设备的芯片。该应用程序的处理装置包括：接收模块11和处理模块12。可选地，在一些实施例中，该应用程序的处理装置还可以包括：发送模块13。
[0238]
接收模块11，用于接收第一客户端发送的启动请求，启动请求用于启动应用程序。
[0239]
处理模块12，用于根据启动请求，在飞地的高级语言运行环境中，加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系；根据舱单文件和飞地入口函数与静态依赖类的依赖关系，加载应用程序的飞地入口函数的静态依赖类。其中，舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。
[0240]
作为一种可能的实现方式，处理模块12，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，根据应用程序的代码，获取应用程序中含有第一注释标注的类的描述文件；根据应用程序中含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系；其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数。
[0241]
作为一种可能的实现方式，处理模块12，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，通过接收模块11接收第一客户端发送的应用程序的飞地入口函数与静态依赖类的依赖关系；或者，处理模块12，还用于在加载应用程序的飞地入口函数与静态依赖类的依赖关系之前，从存储数据库获取应用程序的飞地入口函数与静态依赖类的依赖关系。
[0242]
作为一种可能的实现方式，处理模块12，还用于在加载应用程序的舱单文件之前，通过接收模块11接收第一客户端发送的应用程序的舱单文件；或者，处理模块12，还用于在加载应用程序的舱单文件之前，从存储数据库获取应用程序的舱单文件。
[0243]
作为一种可能的实现方式，处理模块12，还用于在加载应用程序的舱单文件和应用程序的飞地入口函数与静态依赖类的依赖关系之前，在飞地中加载高级语言运行环境，验证高级语言运行环境的完整性。
[0244]
作为一种可能的实现方式，处理模块12，还用于在加载应用程序的飞地入口函数的静态依赖类之后，验证加载的飞地入口函数的静态依赖类的完整性；在飞地入口函数的静态依赖类的完整性验证通过后，根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值。发送模块13，用于向第一客户端发送应用程序的哈希值；该应用程序的哈希值用于第一客户端验证飞地中加载的所述飞地入口函数的静态依赖类的完整性。
[0245]
作为一种可能的实现方式，处理模块12，还用于在飞地入口函数的静态依赖类的完整性验证通过后，在通过第一线程调用应用程序的第一飞地入口函数时，切换至飞地中
为第一线程分配第一内存区域，并在第一内存区域中创建并执行第一飞地入口函数的静态依赖类的对象。
[0246]
作为一种可能的实现方式，第一飞地入口函数还包括第一动态依赖类。处理模块12，还用于获取所述第一动态依赖类与静态依赖类的依赖关系；根据所述第一动态依赖类与静态依赖类的依赖关系，动态加载所述第一动态依赖类；验证所述第一动态依赖类的完整性，并在所述第一动态依赖类的完整性验证通过后，在所述第一内存区域中创建并执行所述第一动态依赖类的对象。
[0247]
作为一种可能的实现方式，第一飞地入口函数与第一飞地出口函数具有调用关系。处理模块12，还用于从飞地的高级语言运行环境切换至非飞地环境；在非飞地环境执行第一飞地出口函数；返回飞地的高级语言运行环境。
[0248]
作为一种可能的实现方式，处理模块12，还用于在第一飞地入口函数退出执行后，若第一飞地入口函数的对象均未被其他线程访问，则清除第一线程与第一内存区域的映射关系。
[0249]
作为一种可能的实现方式，处理模块12，还用于在第一飞地入口函数退出执行后，若第一飞地入口函数的第一对象被其他线程访问，则同步停止执行飞地中的所有线程调用的飞地入口函数；确定访问第一对象的至少一个第二线程；根据至少一个第二线程的数量，对第一对象进行拷贝处理；清除第一线程与第一内存区域的映射关系。例如，处理模块12，具体用于在第二线程的数量为1时，将第一对象拷贝至第二线程对应的第二内存区域；或者，在第二线程的数量大于1时，将第一对象拷贝至飞地的全局内存区域中。
[0250]
应理解，上述接收模块11和发送模块13可以集成在收发模块，也可以分离。
[0251]
本技术实施例提供的应用程序的处理装置，可以执行上述方法实施例中图5至图10所示的计算设备的动作，其实现原理和技术效果类似，在此不再赘述。
[0252]
可选地，上述应用程序的处理装置中还可以包括至少一个存储模块，该存储模块可以包括数据和/或指令，处理模块和/或收发模块(或者接收模块和发送模块)可以读取存储模块中的数据和/或指令，实现对应的方法。
[0253]
本技术实施例还提供了一种应用程序的处理装置的结构示意图。该应用程序的处理装置可以为前述所说的能够获取到应用程序的代码的设备，也可以为该设备的芯片。该应用程序的处理装置包括：处理模块21。
[0254]
处理模块21，用于根据应用程序的代码，获取应用程序中含有第一注释标注的类，和/或，含有第二注释标注的类；根据含有第一注释标注的类，和/或，含有第二注释标注的类，生成应用程序的舱单文件；其中，第一注释标注用于表征该第一注释标注的类为飞地入口函数，第二注释标注用于表征第二注释标注的类为飞地出口函数，舱单文件包括：应用程序的飞地入口函数的描述信息，和/或，应用程序的飞地出口函数的描述信息。
[0255]
作为一种可能的实现方式，处理模块21，还用于根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数的静态依赖类；根据飞地入口函数的静态依赖类的哈希值和舱单文件，生成应用程序的哈希值，该应用程序的哈希值用于验证静态依赖类的完整性。
[0256]
作为一种可能的实现方式，处理模块21，还用于根据含有第一注释标注的类的描述文件，获取应用程序的飞地入口函数与静态依赖类的依赖关系。
[0257]
作为一种可能的实现方式，上述应用程序的处理装置中还可以包括收发模块(或者接收模块和发送模块)，处理模块可以通过收发模块(或者接收模块和发送模块)与其他外设之间进行通信，本技术实施例对此不进行限定。
[0258]
本技术实施例提供的应用程序的处理装置，可以执行上述方法实施例中图3所示的能够获取到应用程序的代码的设备的动作，其实现原理和技术效果类似，在此不再赘述。
[0259]
可选的，上述应用程序的处理装置中还可以包括至少一个存储模块，该存储模块可以包括数据和/或指令，处理模块21可以读取存储模块中的数据和/或指令，实现对应的方法。
[0260]
需要说明的是，应理解以上接收模块实际实现时可以为接收器或通信接口、发送模块实际实现时可以为发送器或通信接口。而处理模块可以以软件通过处理元件调用的形式实现；也可以以硬件的形式实现。例如，处理模块可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块的功能。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里所述的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
[0261]
例如，以上这些模块可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个专用集成电路(application specific integrated circuit，asic)，或，一个或多个微处理器(digital signal processor，dsp)，或，一个或者多个现场可编程门阵列(field programmable gate array，fpga)等。再如，当以上某个模块通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(central processing unit，cpu)或其它可以调用程序代码的处理器。再如，这些模块可以集成在一起，以片上系统(system-on-a-chip，soc)的形式实现。
[0262]
图12为本技术实施例提供的另一种应用程序的处理装置的结构示意图。如图12所示，该应用程序的处理装置可以包括：处理器31(例如cpu)、存储器32；存储器32可能包含高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储器(non-volatile memory，nvm)，例如至少一个磁盘存储器，存储器32中可以存储各种指令，以用于完成各种处理功能以及实现本技术的方法步骤。可选的，本技术涉及的应用程序的处理装置还可以包括：电源33、通信总线34以及通信端口35。通信总线34用于实现元件之间的通信连接。上述通信端口35用于实现应用程序的处理装置与其他外设之间进行连接通信。
[0263]
在本技术实施例中，上述存储器32用于存储计算机可执行程序代码，程序代码包括指令。当处理器31执行指令时，指令使应用程序的处理装置执行上述方法实施例中计算设备的动作；或者，当处理器31执行指令时，指令使应用程序的处理装置执行上述方法实施例中能够获取到应用程序的代码的设备的动作，其实现原理和技术效果类似，在此不再赘述。
[0264]
本技术实施例还提供一种计算机可读存储介质，其上存储有用于实现上述方法实施例中由计算设备执行的方法，或由能够获取到应用程序的代码的设备执行的方法的计算机指令。
[0265]
例如，该计算机指令被执行时，使得应用程序的处理装置可以实现上述方法实施
例中计算设备执行的方法、或者、能够获取到应用程序的代码的设备执行的方法。
[0266]
本技术实施例还提供一种包含指令的计算机程序产品，该指令被执行时使得该计算机实现上述方法实施例中由计算设备执行的方法，或由能够获取到应用程序的代码的设备执行的方法。
[0267]
本技术实施例还提供一种云环境，该云环境包括上文实施例中的包括前述所描述的计算设备和客户端。
[0268]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本技术实施例的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如固态硬盘solid state drive(ssd))等。
[0269]
本文中的术语“多个”是指两个或两个以上。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系；在公式中，字符“/”，表示前后关联对象是一种“相除”的关系。
[0270]
可以理解的是，在本技术的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本技术的实施例的范围。
[0271]
可以理解的是，在本技术的实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术的实施例的实施过程构成任何限定。