CN112307481B - 一种系统可信启动方法、电子设备及计算机可读存储介质 - Google Patents

Abstract

本发明实施例提供了一种系统可信启动方法、电子设备及计算机可读存储介质。该方法应用于具有多核对称处理器且存储TEE‑OS程序代码的电子设备；包括：第一CPU在验证成功后，加载运行启动加载器，发送系统加载指令；第二CPU接收该指令，加载运行TEE‑OS；第一CPU发送用于验证操作系统内核的第一验证请求；第二CPU接收该请求，在通过TEE‑OS对操作系统内核验证成功后，反馈第一验证结果；第一CPU接收该结果，发送用于验证待启动应用的第二验证请求；第二CPU接收该请求，在应用TEE‑OS对待启动应用验证成功后，反馈第二验证结果；第一CPU接收该结果，启动待启动应用。与现有技术相比，应用本发明实施例提供的方案，可以提高应用的可信启动的安全性。

Description

一种系统可信启动方法、电子设备及计算机可读存储介质

技术领域

本发明涉及计算机安全技术领域，特别是涉及一种系统可信启动方法、电子设备及计算机可读存储介质。

背景技术

随着计算机技术的不断发展，各类应用在用户的日常工作中发挥着越来越重要的作用。为了保证应用的安全性，防止黑客对应用进行篡改，用户希望应用的启动过程是可信的。其中，所谓的应用为安装于电子设备上的应用软件或应用程序，例如：即时通讯类软件、新闻类软件、视频类软件。

所谓可信是指：如果一个实体的行为总是以预期的方式朝着预期的目标进行，则这该实体就是可信的。针对应用，可以将在电子设备上电后至应用启动过程中，CPU(Central Processing Unit，中央处理器)在各个阶段运行的程序视为一个实体，则从当前运行的程序跳转运行到下一个程序时，必须保证下一个程序是当前程序预期的，且该下一个程序是安全的，从而可以实现该应用的可信启动。

在相关技术中，针对具有多处理器的电子设备，系统可信启动是该电子设备的一个CPU基于操作系统中的REE(Rich Execution Environment，多样执行环境)进行的。具体的，在该电子设备上电后，该CPU调用芯片内部的固件中预设的验证接口对启动加载器进行验证；如果验证成功，该CPU加载运行启动加载器，并调用启动加载器对操作系统内核进行验证；如果验证成功，该CPU启动操作系统内核，并调用操作系统内核对待启动应用进行验证；如果验证成功，该CPU便可以启动该待启动应用。这样，该CPU基于芯片内部固件验证接口、引导运行启动加载器、引导运行操作系统内核以及引导运行应用四个主要阶段构建出一条可信任执行链，实现整个系统的可信启动。其中，每个阶段的验证保护可以通过预先在OTP(One Time Programmable，一次编程区)区域内写入的根密钥以及各个阶段预设的工作密钥实现，且各个阶段预设的工作密钥通过该根密钥进行加密管理。

然而，当上述电子设备的操作系统为Linux操作系统等开源系统时，由于开源的系统更容易受到恶意软件的攻击，而相关技术中系统可信启动是基于操作系统中的REE(RichExecution Environment，多样执行环境)进行的，因此，相关技术中的可信启动过程的安全性仍有不足。

发明内容

本发明实施例的目的在于提供一种系统可信启动方法、电子设备及计算机可读存储介质，以提高应用的可信启动的安全性。

第一方面，本发明实施例提供了一种系统可信启动方法，应用于具有多核对称处理器的电子设备，所述电子设备存储有可信执行环境操作系统TEE-OS的程序代码，包括第一中央处理器CPU和第二CPU；所述方法包括：

所述第一CPU通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行所述启动加载器，并通过调用所述启动加载器向所述第二CPU发送系统加载指令；

所述第二CPU接收所述系统加载指令，加载运行所述TEE-OS；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求；

所述第二CPU接收所述第一验证请求，通过所述TEE-OS对所述操作系统内核进行验证，如果验证成功，向所述第一CPU反馈第一验证结果；

所述第一CPU接收所述第一验证结果，针对待启动应用，向所述第二CPU发送用于验证所述待启动应用的第二验证请求；

所述第二CPU接收所述第二验证请求，应用所述TEE-OS对所述待启动应用进行验证，如果验证成功，向所述第一CPU反馈第二验证结果；

所述第一CPU接收到所述第二验证结果，启动所述待启动应用。

可选的，一种具体实现方式中，所述方法还包括：

当所述第一CPU在第一预设时长内未接收到所述第一验证结果，或，当所述第一CPU在第二预设时长内未接收到所述第二验证结果，所述第一CPU复位所述电子设备。

可选的，一种具体实现方式中，在所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求之前，所述方法还包括：

所述第二CPU在加载所述TEE-OS后，通过调用所述TEE-OS对所述启动加载器进行验证，如果验证成功，向所述第一CPU发送所述第三验证结果；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求，包括：

所述第一CPU判断是否接收到所述第三验证结果；当接收到时，向所述第二CPU发送用于验证操作系统内核的第一验证请求。

可选的，一种具体实现方式中，所述方法还包括：

当所述第一CPU在第三预设时间内未接收到所述第三验证结果，所述第一CPU复位所述电子设备。

可选的，一种具体实现方式中，所述方法还包括：

当所述第一CPU接收到最后一个待启动应用对应的第二验证结果后，所述第一CPU向所述第二CPU发送资源回收指令；

所述第二CPU接收所述资源回收指令，恢复到操作系统多核对称处理器运行的状态。

第二方面，本发明实施例提供了一种电子设备，所述电子设备具有多核对称处理器且存储有可信执行环境操作系统TEE-OS的程序代码，所述电子设备包括第一中央处理器CPU和第二CPU，通信接口、存储器和通信总线，其中，第一CPU，第二CPU，通信接口，存储器通过通信总线完成相互间的通信；

所述存储器，用于存放计算机程序，所述计算机程序包括所述TEE-OS的程序代码；

所述第一CPU，用于通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行所述启动加载器，并通过调用所述启动加载器向所述第二CPU发送系统加载指令；

所述第二CPU，用于接收所述系统加载指令，加载运行所述TEE-OS；

所述第一CPU，还用于向所述第二CPU发送用于验证操作系统内核的第一验证请求；

所述第二CPU，还用于接收所述第一验证请求，通过所述TEE-OS对所述操作系统内核进行验证，如果验证成功，向所述第一CPU反馈第一验证结果；

所述第一CPU，还用于接收所述第一验证结果，针对待启动应用，向所述第二CPU发送用于验证所述待启动应用的第二验证请求；

所述第二CPU，还用于接收所述第二验证请求，应用所述TEE-OS对所述待启动应用进行验证，如果验证成功，向所述第一CPU反馈第二验证结果；

所述第一CPU，还用于接收到所述第二验证结果，启动所述待启动应用。

可选的，一种具体实现方式中，所述第一CPU，还用于当在第一预设时长内未接收到所述第一验证结果，或，当在第二预设时长内未接收到所述第二验证结果，复位所述电子设备。

可选的，一种具体实现方式中，所述第二CPU，还用于在接收所述第一CPU发送的用于验证操作系统内核的第一验证请求之前，在加载所述TEE-OS后，通过调用所述TEE-OS对所述启动加载器进行验证，如果验证成功，向所述第一CPU发送所述第三验证结果；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求，包括：

所述第一CPU判断是否接收到所述第三验证结果；当接收到时，向所述第二CPU发送用于验证操作系统内核的第一验证请求。

可选的，一种具体实现方式中，所述第一CPU，还用于当在第三预设时间内未接收到所述第三验证结果，复位所述电子设备。

可选的，一种具体实现方式中，所述第一CPU，还用于当接收到最后一个待启动应用对应的第二验证结果后，向所述第二CPU发送资源回收指令；

所述第二CPU，还用于接收所述资源回收指令，恢复到操作系统多核对称处理器运行的状态。

第三方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序包括可信执行操作系统TEE-OS的程序代码，所述计算机程序被处理器执行时实现上述第一方面提供的任一系统可信启动方法的步骤。

以上可见，应用上述本发明实施例提供的系统可信启动方法，第一CPU在对启动加载器验证成功后，便可以加载运行启动加载器，进而通过调用启动加载器向第二CPU发送系统加载指令，从而使第二CPU加载运行TEE-OS(Trusted Execution Environment-Operating System，可信执行环境操作系统)。这样，便可以在第二CPU内构建得到TEE(Trusted Execution Environment，可信执行环境)。进而，后续对操作系统内核以及待启动应用程序的验证，均基于第二CPU中构建的TEE，通过第二CPU调用TEE-OS来完成。由于TEE是电子设备系统中可以与REE并存的，且比REE更安全的程序执行空间，因此，在本发明实施例中，可以实现提升恶意软件攻击开源系统的难度，从而提高应用的可信启动的安全性。

此外，由于TEE是在具有多核对称处理器的电子设备的第二CPU中构建的，因此，对于具有多核对称处理器的电子设备而言，在应用本发明实施例提供的方案时，不需要在电设置或添加其他特殊硬件模块，例如可信执行引擎等，从而，可以降低对特殊硬件模块的需求以及成本。

附图说明

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

图1为本发明实施例提供的一种系统可信启动方法的流程示意图；

图2为本发明实施例提供的另一种系统可信启动方法的流程示意图；

图3为一种具有双核ARM架构的，且具有多处理器的电子设备的内部逻辑的结构示意图；

图4为图3所示电子设备的一种内存划分方法的结构示意图；

图5为图3所示电子设备中的Core#0和Core#1的信息交互示意图；

图6为本发明实施例提供的一种电子设备的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

相关技术中，系统可信启动是基于操作系统中的REE进行的，当电子设备的操作系统为Linux操作系统等开源系统时，由于开源的系统更容易收到恶意软件的攻击，因此，相关技术中的可信启动过程的安全性仍有不足。为了解决相关技术中存在的技术问题，本发明实施例提供的一种系统可信启动方法。

其中，本发明实施例提供的一种系统可信启动方法应用于具有多核对称处理器的电子设备，例如，具有SMP(Symmetric Multiprocessing，对称多处理)系统的电子设备。其中，SMP是指：电子设备的操作系统可以同时管理电子设备中的所有CPU，应用系统并不限定在某一个CPU中运行，操作系统需要完成的各项任务可以平均分配到每个CPU中。

下面，首先对本发明实施例提供的一种系统可信启动方法进行介绍。

图1为本发明实施例提供的一种系统可信启动方法的流程示意图。其中，该系统可信启动方法应用于具有多核对称处理器的电子设备的第一CPU和第二CPU，且该电子设备存储有TEE-OS(Trusted Execution Environment-Operating System，可信执行环境操作系统)的程序代码。

需要说明的是，在本发明实施例提供的一种系统可信启动方法中，对各个程序验证的目的是确定该程序是否可信，即确定各个程序是否未被黑客攻击，从而未被篡改，因此，该验证又可以称为可信验证。其中，对各个程序的验证可以通过鉴权进行，所谓鉴权是指利用认证授权来验证各个程序的数字签名的正确与否。

例如，可以对启动加载器的签名文件、TEE-OS的程序代码、以及操作系统内核、待启动应用的签名文件等采用RSA非对称加密算法进行加密，这样，在验证过程中，便可以通过密钥对启动加载器的签名文件、TEE-OS的程序代码、以及操作系统内核、待启动应用的签名文件等进行解密鉴权。

在本发明实施例中，可以通过多种加密算法对启动加载器的签名文件、TEE-OS的程序代码、以及操作系统内核、待启动应用的签名文件等进行加密，因此，也就是说，在本发明实施例中，可以采用多种方式对启动加载器、TEE-OS的程序代码、以及操作系统内核、待启动应用等进行可信验证。

如图1所示，本发明实施例提供的一种系统可信启动方法，可以包括如下步骤：

S101：第一CPU通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行启动加载器；

电子设备上电之后，电子设备中安装的芯片便可以启动，这样，电子设备便开始进入启动阶段。此时，电子设备中的第一CPU可以通过调动该芯片内部的验证接口对启动加载器进行验证。

其中，芯片内部的验证接口是在生厂商生产芯片时便写入到芯片内部的，并且，在写入到芯片内部之后，该验证接口是不能更改的。此外，当电子设备的操作系统不同时，该电子设备所对应的启动加载器的具体类型也是不同的。

例如，在嵌入式系统中，启动加载器可以为Uboot。对此，本发明实施例不做具体限定。

S102：第一CPU通过调用启动加载器向第二CPU发送系统加载指令；

进而，如果验证成功，第一CPU便可以加载运行该启动加载器，此时，启动加载器在第一CPU中开始启动。进而，第一CPU便可以通过调用该启动加载器向第二CPU发送系统加载指令。其中，该系统加载指令中包括TEE-OS的程序代码在电子设备中的存储地址。

S103：第二CPU接收系统加载指令，加载运行TEE-OS；

相应的，第二CPU在获取到上述第一CPU发送的系统加载指令后，便可以从电子设备的存储空间中调用预先存储的TEE-OS的程序代码并加载运行该程序代码。这样，第二CPU便可以实现对TEE-OS的加载运行，从而使TEE-OS在第二CPU中开始启动，以实现在第二CPU内构建TEE。

S104：第一CPU向第二CPU发送用于验证操作系统内核的第一验证请求；

这样，在向第二CPU发送系统加载指令，以使得第二CPU加载运行TEE-OS后，第一CPU便可以向第二CPU发送用于验证操作系统内核的第一验证请求。

S105：第二CPU接收第一验证请求，通过TEE-OS对操作系统内核进行验证；

S106：如果验证成功，第二CPU向第一CPU反馈第一验证结果；

相应的，第二CPU在接收到该第一验证请求后，便可以通过TEE-OS对操作系统内核进行验证，并在验证成功时，向第一CPU反馈第一验证结果。

S107：第一CPU接收第一验证结果；

S108：针对待启动应用，第一CPU向第二CPU发送用于验证待启动应用的第二验证请求；

在向第二CPU发送上述第一验证请求后，第一CPU便可以等待接收第二CPU通过TEE-OS对操作系统内核进行验证的验证结果。这样，当第一CPU接收到第二CPU反馈的第一验证结果后，第一CPU便可以确定：第二CPU通过TEE-OS对操作系统内核验证成功，也就是说，第一CPU可以确定：操作系统内核是可信的，且从电子设备上电开始到当前时刻之间，各个阶段的系统启动是可信的。

进而，针对待启动应用，第一CPU便可以向第二CPU发送用于验证该待启动应用的第二验证请求。

S109：第二CPU接收第二验证请求，应用TEE-OS对待启动应用进行验证；

S110：如果验证成功，第二CPU向第一CPU反馈第二验证结果；

相应的，第二CPU在接收到该第二验证请求后，便可以应用TEE-OS对该待启动应用进行验证，并在验证成功后，向第一CPU反馈第二验证结果。

S111：第一CPU接收到第二验证结果，启动待启动应用。

在向第二CPU发送上述第二验证请求后，第一CPU便可以等待接收第二CPU应用TEE-OS对待启动应用进行验证的验证结果。这样，当第一CPU接收到第二CPU反馈的第二验证结果后，第一CPU便可以确定：第二CPU应用TEE-OS对待启动应用验证成功，也就是说，第一CPU可以确定：待启动应用是可信的，且从电子设备上电开始到当前时刻之间，各个阶段的系统启动是可信的，进而，第一CPU便可以启动该待启动应用。这样，用户便可以开始使用启动后的上述应用，至此，应用的系统可信启动完成。

以上可见，应用上述本发明实施例提供的系统可信启动方法，第一CPU在对启动加载器验证成功后，便可以加载运行启动加载器，进而通过调用启动加载器向第二CPU发送系统加载指令，从而使第二CPU加载运行TEE-OS。这样，便可以在第二CPU内构建得到TEE。进而，后续对操作系统内核以及待启动应用程序的验证，均基于第二CPU中构建的TEE，通过第二CPU调用TEE-OS来完成。由于TEE是电子设备系统中可以与REE并存的，且比REE更安全的程序执行空间，因此，在本发明实施例中，可以实现提升恶意软件攻击开源系统的难度，从而提高应用的可信启动的安全性。

此外，由于TEE是在具有多核对称处理器的电子设备的第二CPU中构建的，因此，对于具有多核对称处理器的电子设备而言，在应用本发明实施例提供的方案时，不需要在电设置或添加其他特殊硬件模块，例如可信执行引擎等，从而，可以降低对特殊硬件模块的需求以及成本。

对应于上述第二CPU通过TEE-OS对操作系统内核验证成功的情况，当操作系统内核遇到黑客攻击等意外情况时，操作系统内核的程序代码将会被串改，从而使得操作系统内核变得不安全，进而，系统无法可信启动。在这种情况下，为了保证系统安全，第二CPU通过TEE-OS对操作系统内核进行验证的验证结果为失败。进而，第二CPU将无法向第一CPU反馈用于表征对操作系统内核验证成功的第一验证结果。这种情况下，第二CPU可以不向第一CPU反馈任何结果。也就是说，当第二CPU通过TEE-OS对操作系统内核的验证失败时，第二CPU不向第一CPU反馈第一验证结果，则第二CPU将无法接收到第一验证结果。

基于此，可选的，一种具体实现方式中，本发明实施例提供的一种系统可信启动方法还可以包括如下步骤：

当第一CPU在第一预设时长内未接收到第一验证结果，第一CPU复位电子设备。

当第一CPU在第一预设时长内未接收到第一验证结果时，第一CPU便可以确定第二CPU通过TEE-OS对操作系统内核的验证结果是失败的，因此，为了保证系统安全，第一CPU将会对电子设备进行复位。

其中，所谓复位电子设备是指控制电子设备使其进入新的下电、上电过程中。这样，电子设备可以处于无法工作的状态下，以提醒用户对当前操作系统内核所存在的安全隐含进行消除。例如，构建具有防护能力更强的防火墙。

此外，第一预设时长可以根据实际应用中对系统可信启动的需求进行设定，且第一CPU还可以通过其他方式确定第二CPU通过TEE-OS对操作系统内核的验证结果是失败的，对此本发明实施例均不做具体限定。

例如，第一CPU可以向第二CPU发送获取第一验证结果的请求。这样，由于第二CPU通过TEE-OS对操作系统内核的验证结果是失败的，因此，第二CPU将无法向第一CPU反馈第一验证结果，从而导致第一CPU获取第一验证结果失败。这种情况下，第一CPU可以获知自身获取第一验证请求失败，从而确定第二CPU通过TEE-OS对操作系统内核的验证结果是失败的，并对电子设备进行复位。

对应于上述第二CPU应用TEE-OS对待启动应用验证成功的情况，当待启动应用遇到黑客攻击等意外情况时，待启动应用的程序代码将会被篡改，从而造成待启动应用变得不安全，进而，系统无法可信启动。在这种情况下，为了保证系统安全，第二CPU应用TEE-OS对待启动应用的验证结果为失败。进而，第二CPU将无法向第一CPU反馈用于表征待启动应用验证成功的第二验证结果。这种情况下，第二CPU可以不向第一CPU反馈任何结果。也就是说，当第二CPU应用TEE-OS对待启动应用的验证失败时，第二CPU可以不向第一CPU反馈第二验证结果，则第二CPU无法接收到第二验证结果。

基于此，可选的，一种具体实现方式中，本发明实施例提供的一种系统可信启动方法还可以包括如下步骤：

当第一CPU在第二预设时长内未接收到第二验证结果，第一CPU复位电子设备。

当第一CPU在第二预设时长内未接收到第二验证结果时，第一CPU便可以确定第二CPU应用TEE-OS对待启动应用的验证结果是失败的，因此，为了保证系统安全，第一CPU将会对电子设备进行复位。

其中，第二预设时长可以根据实际应用中对系统可信启动的需求进行设定，且第一CPU还可以通过其他方式确定第二CPU应用TEE-OS对待启动应用的验证结果是失败的，对此本发明实施例均不做具体限定。

例如，第一CPU可以向第二CPU发送获取第二验证结果的请求。这样，由于第二CPU应用TEE-OS对待启动应用的验证结果是失败的，因此，第二CPU将无法向第一CPU反馈第二验证结果，从而导致第一CPU获取第二验证结果失败。这种情况下，第一CPU可以获知自身获取第二验证请求失败，从而确定第二CPU应用TEE-OS对待启动应用的验证结果是失败的，并对电子设备进行复位。

需要说明的是，在本发明实施例提供的一种系统可信启动方法中，待启动应用可以为一个，也可以为多个。

可选的，当待启动应用为一个时，当第一CPU接收到第二验证结果后，第一CPU可以启动该待启动应用，从而完成整个系统可信启动过程。

可选的，当待启动应用程序为多个时，则第一CPU在接收到第一验证结果后，可以按照预设的多个应用程序的启动顺序，首先向第二CPU发送用于验证第一个待启动应用的第二验证请求。这样，第二CPU接收该用于验证第一个待启动应用的第二验证请求，应用TEE-OS对该第一个待启动应用进行验证，并在验证成功后，向第一CPU反馈针对该第一个待启动的应用的第二验证结果。进而，当第一CPU接收到针对该第一个待启动的第二验证结果时，第一CPU便可以启动该第一个待启动应用，并再次向第二CPU发送用于验证下一个待启动应用的第二验证请求。这样，第二CPU接收该用于验证下一个待启动应用的第二验证请求，应用TEE-OS对该下一个待启动应用进行验证，并在验证成功后，向第一CPU反馈针对该下一个待启动应用的第二验证结果。进而，当第一CPU接收到针对该下一个待启动系统的第二验证结果时，第一CPU便可以启动该下一个待启动应用，并继续向第二CPU发送用于验证再下一个待启动应用的第二验证请求。依次类推，直至第一CPU获取到针对最后一个待启动应用的第二验证结果，启动该最后一个待启动应用。这样，该电子设备便可以完成对所有预设的多个应用的系统可信启动，进而，完成整个系统可信启动过程。

此外，当第一CPU接收到最后一个待启动应用的第二验证结果后，第一CPU便可以确定整个系统可信启动过程中与验证相关的步骤均已全部完成，第一CPU可以不再向第二CPU发送用于对待启动应用进行验证的第二验证请求。在这种情况下，第一CPU可以控制第二CPU结束运行TEE-OS。这样，第二CPU可以回归到REE。进而，在将所有待启动应用启动后，第二CPU也可以参与完成这些应用所需要完成的各项任务，从而提升电子设备的效率。

基于此，可选的，一种具体实现方式中，如图2所示，在步骤S101-S111的基础上，本发明实施例提供的一种系统可信启动方法还可以包括如下步骤：

S112：当第一CPU接收到最后一个待启动应用对应的第二验证结果后，第一CPU向第二CPU发送资源回收指令。

S113：第二CPU接收资源回收指令，恢复到操作系统多核对称处理器运行的状态。

在本具体实现方式中，第一CPU在接收到最后一个待启动应用的第二验证结果后，便可以向第二CPU发送资源回收指令。

相应的，第二CPU在接受到该资源回收指令后，便可以结束运行TEE-OS，使自身恢复到操作系统多核对称处理器运行的状态，此时，第二CPU可以回归REE，从而可以参与完成已启动的应用程序所需要完成的各项任务。

在上述本发明实施例提供的一种系统可信启动方法中，第一CPU在向第二CPU发送系统加载指令，以使得第二CPU加载运行TEE-OS后，第一CPU是直接向第二CPU发送用于验证操作系统内核的第一验证请求的。然而，在一些情况中，可能存在如下现象：即启动加载器已经遇到黑客攻击等意外情况，程序代码已经被串改，但是，第一CPU通过调用芯片内部的验证接口对被攻击的启动加载器的验证依然是成功的。显然，在这种情况中，如果第一CPU继续进行后续的系统可信启动流程，则系统的安全性会遭到极大的破坏。

因此，为了保证进一步提高系统可信启动中对启动加载器进行验证的可靠性，确保启动加载器的程序代码没有被串改，从而提升系统可信启动的安全性。可选的，一种具体实现方式中，在上述步骤S103之前，本发明实施例提供的一种系统可信启动方法，还可以包括如下步骤：

第二CPU在加载TEE-OS后，通过调用TEE-OS对启动加载器进行验证，如果验证成功，向第一CPU发送第三验证结果

第二CPU在接收到系统加载指令，进而，完成加载运行TEE-OS后，便可以通过调用TEE-OS对启动加载器进行验证，并在验证成功时，向第一CPU反馈第三验证结果。

基于此，在本具体实现方式中，上述步骤S103，第一CPU向第二CPU发送用于验证操作系统内核的第一验证请求，便可以包括如下步骤：

第一CPU判断是否接收到第三验证结果；当接收到时，向第二CPU发送用于验证操作系统内核的第一验证请求。

在通过调用启动加载器向电子设备的第二CPU发送系统加载指令后，第一CPU便可以开始判断是否接收到第二CPU通过调用TEE-OS对启动加载器进行验证的验证结果。这样，当第一CPU接收到第二CPU反馈的第三验证结果后，第一CPU便可以确定：第二CPU通过调用TEE-OS对启动加载器验证成功，也就是说，第一CPU可以确定，启动加载器是可信的。进而，第一CPU便可以执行上述步骤S103，向第二CPU发送用于验证操作系统内核的第一验证请求。

对应于上述第二CPU通过调用TEE-OS对启动加载器验证成功的情况，当第二CPU通过调用TEE-OS对启动加载器的验证结果为失败时，第二CPU将无法向第一CPU反馈用于表征启动加载器验证成功的第三验证结果。这种情况下，第二CPU可以不向第一CPU反馈任何结果。也就是说，当第二CPU通过调用TEE-OS对启动加载器的验证失败时，第二CPU可以不向第一CPU反馈第三验证结果，则第一CPU无法接收到第三验证结果。

基于此，可选的，一种具体实现方式中，本发明实施例提供的一种系统可信启动方法，还可以包括如下步骤：

当第一CPU在第三预设时间内未接收到第三验证结果，第一CPU复位电子设备。

当第一CPU在第三预设时长内未接收到第三验证结果时，第一CPU便可以确定第二CPU通过调用TEE-OS对启动加载器的验证结果是失败的，因此，为了保证系统安全，第一CPU将会对电子设备进行复位。

其中，第三预设时长可以根据实际应用中对系统可信启动的需求进行设定，且第一CPU还可以通过其他方式确定第二CPU通过调用TEE-OS对启动加载器的验证结果是失败的，对此本发明实施例均不做具体限定。

例如，第一CPU可以向第二CPU发送获取第三验证结果的请求。这样，由于第二CPU通过调用TEE-OS对启动加载器的验证结果是失败的，因此，第二CPU将无法向第二CPU反馈第三验证结果，从而导致第一CPU无法获取第三验证结果。这种情况下，第一CPU可以确定第二CPU通过调用TEE-OS对启动加载器的验证结果是失败的，并对电子设备进行复位。

进一步的，为了便于理解上述本发明实施例提供的一种系统可信启动方法，下面通过一个具体实施例来进行说明。

在本实施例中，以具有双核ARM(Advanced RISC Machines，RISC处理器)架构的，且具有多处理器的电子设备为例进行描述，且在该电子设备中，启动加载器具体为Uboot。其中，RISC为精简指令集(Reduced Instruction Set Computing)。

在本实施例中，该电子设备包括Core#0和Core#1两个CPU Core。其中，Core#0作为该电子设备的第一CPU，执行上述REE的逻辑，Core#1作为该电子设备的第二CPU，执行上述TEE的逻辑。

其中，该电子设备的内部逻辑结果框图如图3所示，具体的：

每个CPU Core具有私有的指令缓存(Instruction Cache，I Cache)和数据缓存(Date Cache，D Cache)，其中，每个CPU Core具有的私有指令缓存和数据缓存均为L1Cache(Level 1Cache，一级缓存)。Core#0和Core#1之间共享L2 Cache(Level 2Cache，二级缓存)，并利用内部高速总线AHB(Advanced High Performance Bus)通过DDRC(Double DataRate Controller，双倍速率同步动态随机存储器控制器)外接DDR(Double Data Rate，双倍速率同步动态随机存储器)颗粒作为该电子设备中系统运行所需的内存使用。

此外，如图4所示，在本实施例中可以将DDR所在的地址空间划分两部分，其中，地址空间0x80000000-0x90000000段为REE段，为Core#0的内存空间，用于存储Core#0执行上述REE的程序代码；地址空间0x90000000-0xA0000000段为TEE段，为Core#1的内存空间，用于存储Core#1执行上述TEE-OS的程序代码。

这样，在该电子设备上电后，如图5所示，该电子设备中的Core#0与Core#1通过交互，执行上述本发明实施例提供的一种系统可信启动方法：

S501：Core#0调用芯片内部的验证接口对Uboot进行可信验证；如果验证成功，加载Uboot；

S502：Core#0调动Uboot向Core#1发送系统加载指令；

其中，上述系统加载指令中可以包括TEE-OS程序代码在该电子设备中的存储地址。

S503：Core#1接收上述系统加载指令，按照上述系统加载指令中包括的存储地址，从电子设备的存储介质中获取TEE-OS的程序代码，在内存的TEE段加载运行该程序代码；并调用TEE-OS对Uboot进行可信验证；

S504：当Core#1对Uboot的验证结果为验证成功时，Core#1向Core#0发送第三验证结果；

S505：当Core#1对Uboot的验证结果为验证失败时，复位该电子设备；

S506：当Core#0接收到上述第三验证结果后，向Core#1发送用于验证操作系统内核的第一验证请求；

S507：当Core#0在第三预设时间内未接收到第三验证结果，复位电子设备；

S508：Core#1接收上述第一验证请求，通过TEE-OS对操作系统内核进行可信验证；

S509：当Core#1对操作系统内核的验证结果为验证成功时，向Core#0发送第一验证结果；

S510：当Core#1对操作系统内核的验证结果为验证失败时，复位该电子设备；

S511：当Core#0接收到上述第一验证结果后，向Core#1发送用于验证待启动应用的第二验证请求；

S512：当Core#0在第一预设时间内未接收到第一验证结果，复位电子设备；

S513：Core#1接收上述第二验证请求，应用TEE-OS对待启动应用进行可信验证；

S514：当Core#1对待启动应用的验证结果为验证成功时，向Core#0发送第二验证结果；

S515：当Core#1对待启动应用的验证结果为验证失败时，复位该电子设备；

S516：当Core#0接收到上述第二验证结果后，向Core#1发送资源回收指令；

S517：Core#0启动该待启动应用；

S518：当Core#0在第二预设时间内未接收到第二验证结果，复位电子设备；

S519：Core#1接收上述资源回收指令，恢复到操作系统多核对称处理器运行的状态。

这样，在本实施例中，Core#0中所构建的环境为REE，Core#1中所构建的环境为TEE。因此，对操作系统内核以及待启动应用系统的可信验证均是有Core#1在TEE环境中，通过TEE-OS完成的，而处于REE环境中的Core#0仅用于交付可信验证的对象以及获取可信验证的结果，并根据验证结果确定是否执行下一阶段的可信验证。从而，最终完成整个系统可信启动过程。

其中，为了保证UBOOT、TEE-OS可信，可在编译UBOOT和TEE-OS的阶段构建一组RSA密钥对用于UBOOT的签名文件和TEE-OS的程序代码进行加密。这样，在Core#0加载TEE-OS时，首先对TEE-OS的程序代码本身进行解密验证，Core#1在TEE-OS启动后，利用RSA解密密钥对UBOOT的签名文件进行反向解密验证。如果解密失败，则Core#1直接复位该电子设备；如果解密成功，则Core#1将表征UBOOT验证成功的第三验证结果反馈给处于REE中的Core#0。以使得处于REE环境中的Core#0根据Core#1对UBOOT的验证是否成功选择继续运行执行上述本发明实施例提供的一种系统可信方法或者选择复位该电子设备。这样，便可以通过一个双向验证机制保证UBOOT和TEE-OS均可信，从而提高系统可信启动的安全性。

其中，在本实施例提供的一种系统可信启动方法中，通过在系统启动阶段将Core#0之外的第二个CPU Core作为一个TEE环境，则可以将启动信任链的可信验证工作交由TEE-OS来完成。这样，在面对黑客利用反向工程对各程序代码进行攻击时，首先，由于可以对UBOOT的签名文件、TEE-OS的程序代码、以及操作系统内核和待启动应用的签名文件均采用RSA非对称加密算法，因此，黑客获取不到加密密钥，无法实现程序文件的修改。此外，即使在电子设备运行过程中，黑客企图通过调试器等手段获取内存中的信息，也会由于超时复位电子设备的措施，导致黑客所能利用的可操作时间非常有限。进一步的，即使黑客截取了UBOOT的签名文件，然而，如果没有TEE-OS对后续的操作系统内核、待启动应用进行可信验证，黑客也无法获取到设备的操作系统内核、待启动应用系统的信息，而只能停留在UBOOT，为整个系统更进一步的安全屏障。

相应于上述本发明实施例提供的一种系统可信启动方法，本发明实施例还提供了一种电子设备，该电子设备具有多核对称处理器且存储有可信执行环境操作系统TEE-OS的程序代码。如图6所示，该电子设备包括第一CPU610、第二CPU620，通信接口630、存储器640和通信总线650，其中，第一CPU610，第二CPU620，通信接口630，存储器640通过通信总线650完成相互间的通信。

存储器640用于存放计算机程序，该计算机程序包括TEE-OS的程序代码；

第一CPU610，用于通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行启动加载器，并通过调用启动加载器向第二CPU620发送系统加载指令；

第二CPU620，用于接收系统加载指令，加载运行TEE-OS；

第一CPU610，还用于向第二CPU620发送用于验证操作系统内核的第一验证请求；

第二CPU620，还用于接收第一验证请求，通过TEE-OS对操作系统内核进行验证，如果验证成功，向第一CPU610反馈第一验证结果；

第一CPU610，还用于接收第一验证结果，针对待启动应用，向第二CPU620发送用于验证待启动应用的第二验证请求；

第二CPU，还用于接收第二验证请求，应用TEE-OS对待启动应用进行验证，如果验证成功，向第一CPU610反馈第二验证结果；

第一CPU610，还用于接收到第二验证结果，启动待启动应用。

以上可见，应用上述本发明实施例提供的系统可信启动方法，第一CPU在对启动加载器验证成功后，便可以加载运行启动加载器，进而通过调用启动加载器向第二CPU发送系统加载指令，从而使第二CPU加载运行TEE-OS。这样，便可以在第二CPU内构建得到TEE。进而，后续对操作系统内核以及待启动应用程序的验证，均基于第二CPU中构建的TEE，通过第二CPU调用TEE-OS来完成。由于TEE是电子设备系统中可以与REE并存的，且比REE更安全的程序执行空间，因此，在本发明实施例中，可以实现提升恶意软件攻击开源系统的难度，从而提高应用的可信启动的安全性。

此外，由于TEE是在具有多核对称处理器的电子设备的第二CPU中构建的，因此，对于具有多核对称处理器的电子设备而言，在应用本发明实施例提供的方案时，不需要在电设置或添加其他特殊硬件模块，例如可信执行引擎等，从而，可以降低对特殊硬件模块的需求以及成本。

上述电子设备提到的通信总线可以是外设部件互连标准(Peripheral ComponentInterconnect，PCI)总线或扩展工业标准结构(Extended Industry StandardArchitecture，EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

通信接口用于上述电子设备与其他设备之间的通信。

存储器可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。可选的，存储器还可以是至少一个位于远离前述处理器的存储装置。

可选的，一种具体实现方式中，第一CPU610，还用于当在第一预设时长内未接收到第一验证结果，或，当在第二预设时长内未接收到第二验证结果，复位电子设备。

可选的，一种具体实现方式中，第二CPU620，还用于在接收第一CPU610发送的用于验证操作系统内核的第一验证请求之前，在加载TEE-OS后，通过调用TEE-OS对启动加载器进行验证，如果验证成功，向第一CPU610发送第三验证结果；

则在本具体实现方式中，第一CPU610向第二CPU620发送用于验证操作系统内核的第一验证请求，包括：

第一CPU610判断是否接收到第三验证结果；当接收到时，向第二CPU620发送用于验证操作系统内核的第一验证请求。

可选的，一种具体实现方式中，第一CPU610，还用于当在第三预设时间内未接收到第三验证结果，复位电子设备。

可选的，一种具体实现方式中，第一CPU610，还用于当接收到最后一个待启动应用对应的第二验证结果后，向第二CPU620发送资源回收指令；

第二CPU610，还用于接收资源回收指令，恢复到操作系统多核对称处理器运行的状态。

相应于上述本发明实施例提供的一种系统可信启动方法，本发明实施例还提供了一种计算机存储介质，该计算机程序包括可信执行操作系统TEE-OS的程序代码，该计算机程序被处理器执行时实现上述本发明实施例提供的一种系统可信启动方法。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于电子设备实施例、计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本发明的保护范围内。

Claims (9)

1.一种系统可信启动方法，其特征在于，应用于具有多核对称处理器的电子设备，所述电子设备存储有可信执行环境操作系统TEE-OS的程序代码，包括第一CPU和第二CPU；所述方法包括：

所述第一CPU通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行所述启动加载器，并通过调用所述启动加载器向所述第二CPU发送系统加载指令；

所述第二CPU接收所述系统加载指令，加载运行所述TEE-OS；

所述第二CPU在加载所述TEE-OS后，通过调用所述TEE-OS对所述启动加载器进行验证，如果验证成功，向所述第一CPU发送第三验证结果；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求；

所述第二CPU接收所述第一验证请求，通过所述TEE-OS对所述操作系统内核进行验证，如果验证成功，向所述第一CPU反馈第一验证结果；

所述第一CPU接收所述第一验证结果，针对待启动应用，向所述第二CPU发送用于验证所述待启动应用的第二验证请求；

所述第二CPU接收所述第二验证请求，应用所述TEE-OS对所述待启动应用进行验证，如果验证成功，向所述第一CPU反馈第二验证结果；

所述第一CPU接收到所述第二验证结果，启动所述待启动应用；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求，包括：

所述第一CPU判断是否接收到所述第三验证结果；当接收到时，向所述第二CPU发送用于验证操作系统内核的第一验证请求。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述第一CPU在第一预设时长内未接收到所述第一验证结果，或，当所述第一CPU在第二预设时长内未接收到所述第二验证结果，所述第一CPU复位所述电子设备。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述第一CPU在第三预设时间内未接收到所述第三验证结果，所述第一CPU复位所述电子设备。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述第一CPU接收到最后一个待启动应用对应的第二验证结果后，所述第一CPU向所述第二CPU发送资源回收指令；

所述第二CPU接收所述资源回收指令，恢复到操作系统多核对称处理器运行的状态。

5.一种电子设备，其特征在于，所述电子设备具有多核对称处理器且存储有可信执行环境操作系统TEE-OS的程序代码，所述电子设备包括第一CPU和第二CPU，通信接口、存储器和通信总线，其中，第一CPU，第二CPU，通信接口，存储器通过通信总线完成相互间的通信；

所述存储器，用于存放计算机程序，所述计算机程序包括所述TEE-OS的程序代码；

所述第一CPU，用于通过调用芯片内部的验证接口对启动加载器进行验证；如果验证成功，加载运行所述启动加载器，并通过调用所述启动加载器向所述第二CPU发送系统加载指令；

所述第二CPU，用于接收所述系统加载指令，加载运行所述TEE-OS；

所述第一CPU，还用于向所述第二CPU发送用于验证操作系统内核的第一验证请求；

所述第二CPU，还用于接收所述第一验证请求，通过所述TEE-OS对所述操作系统内核进行验证，如果验证成功，向所述第一CPU反馈第一验证结果；

所述第一CPU，还用于接收所述第一验证结果，针对待启动应用，向所述第二CPU发送用于验证所述待启动应用的第二验证请求；

所述第二CPU，还用于接收所述第二验证请求，应用所述TEE-OS对所述待启动应用进行验证，如果验证成功，向所述第一CPU反馈第二验证结果；

所述第一CPU，还用于接收到所述第二验证结果，启动所述待启动应用；

所述第二CPU，还用于在接收所述第一CPU发送的用于验证操作系统内核的第一验证请求之前，在加载所述TEE-OS后，通过调用所述TEE-OS对所述启动加载器进行验证，如果验证成功，向所述第一CPU发送第三验证结果；

所述第一CPU向所述第二CPU发送用于验证操作系统内核的第一验证请求，包括：

所述第一CPU判断是否接收到所述第三验证结果；当接收到时，向所述第二CPU发送用于验证操作系统内核的第一验证请求。

6.根据权利要求5所述的电子设备，其特征在于，

所述第一CPU，还用于当在第一预设时长内未接收到所述第一验证结果，或，当在第二预设时长内未接收到所述第二验证结果，复位所述电子设备。

7.根据权利要求6所述的电子设备，其特征在于，

所述第一CPU，还用于当在第三预设时间内未接收到所述第三验证结果，复位所述电子设备。

8.根据权利要求5所述的电子设备，其特征在于，

所述第一CPU，还用于当接收到最后一个待启动应用对应的第二验证结果后，向所述第二CPU发送资源回收指令；

所述第二CPU，还用于接收所述资源回收指令，恢复到操作系统多核对称处理器运行的状态。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序包括可信执行操作系统TEE-OS的程序代码，所述计算机程序被处理器执行时实现权利要求1-4任一项所述的方法步骤。