CN116661876A - 系统启动方法、文件生成方法、电子设备及服务器 - Google Patents

系统启动方法、文件生成方法、电子设备及服务器 Download PDF

Info

Publication number
CN116661876A
CN116661876A CN202211475664.4A CN202211475664A CN116661876A CN 116661876 A CN116661876 A CN 116661876A CN 202211475664 A CN202211475664 A CN 202211475664A CN 116661876 A CN116661876 A CN 116661876A
Authority
CN
China
Prior art keywords
image file
data
signature data
verification
hash
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202211475664.4A
Other languages
English (en)
Other versions
CN116661876B (zh
Inventor
董广大
朱志英
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202211475664.4A priority Critical patent/CN116661876B/zh
Publication of CN116661876A publication Critical patent/CN116661876A/zh
Application granted granted Critical
Publication of CN116661876B publication Critical patent/CN116661876B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Stored Programmes (AREA)
  • Retry When Errors Occur (AREA)

Abstract

本申请涉及操作系统领域，提供了一种系统启动方法、文件生成方法、电子设备及服务器。所述系统启动方法包括：在所述电子设备进行系统启动的过程中，读取第一镜像文件，所述第一镜像文件中包括多个第二镜像文件各自的第一签名数据；根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件；若多个所述第二镜像文件均验证通过，则启动系统。通过上述方法，在系统启动验证过程中，从第一镜像文件中获取各个组件的第二镜像文件的第一签名数据，无需根据第一镜像文件的链式分区描述符链接到另一个vbmeta镜像、再从链接到的vbmeta镜像中获取组件镜像文件的签名数据，简化了开机流程，从而节约了开机启动时间。

Description

系统启动方法、文件生成方法、电子设备及服务器
技术领域
本申请涉及操作系统领域，尤其涉及一种系统启动方法、文件生成方法、电子设备及服务器。
背景技术
在电子设备的开机启动流程中，电子设备上电后首先运行引导加载程序Bootloader，通过引导加载程序对操作系统各个启动分区的镜像进行校验，该过程称为启动验证过程。在启动的过程中，可以依次将操作系统各个启动分区的镜像加载至内存，并在内存中验证每种镜像的合法性，若所有镜像文件均通过合法性验证，再将内核加载到内存；若任一镜像文件合法性验证失败，则系统无法正常启动。目前，启动验证过程较为繁琐，导致电子设备开机启动时间较长，影响用户体验。
发明内容
本申请提供一种系统启动方法、文件生成方法、电子设备及服务器，解决了现有技术中电子设备开机启动时间较长的问题。
为达到上述目的，本申请采用如下技术方案：
第一方面，提供一种系统启动方法，应用于电子设备，所述方法包括：
在所述电子设备进行系统启动的过程中，读取第一镜像文件，所述第一镜像文件中包括多个第二镜像文件各自的第一签名数据；
根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件；
若多个所述第二镜像文件均验证通过，则启动系统。
本申请实施例中，在系统启动验证过程中，从第一镜像文件中获取各个组件的第二镜像文件的第一签名数据，无需根据第一镜像文件的链式分区描述符链接到另一个vbmeta镜像、再从链接到的vbmeta镜像中获取组件镜像文件的签名数据。通过本申请实施例所述的方法，简化了开机流程，从而节约了开机启动时间。
在第一方面的一种实现方式中，所述第一镜像文件中还包括第二签名数据；
所述根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件，包括：
验证所述第二签名数据；
若所述第二签名数据验证通过，则根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件。
在第一方面的一种实现方式中，所述验证所述第二签名数据，包括：
从用于启动系统的引导程序中获取第二验证数据，所述第二验证数据为所述电子设备的原始设备制造商设置的密钥；
根据所述第二验证数据验证所述第二签名数据。
本申请实施例中，通过设置第二签名数据，在启动验证过程中，bootloader利用OEM key验证vbmeta.img中的第二签名数据，从而信任vbmeta.img，提高了数据安全性。
在第一方面的一种实现方式中，所述第一镜像文件中还包括多个所述第二镜像文件各自的第一验证数据；
所述根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件，包括：
对于每个所述第二镜像文件，根据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据；
若所述第二镜像文件的第一签名数据验证通过，则判定所述第二镜像文件验证通过；
若所述第二镜像文件的第一签名数据验证失败，则判定所述第二镜像文件验证失败。
在第一方面的一种实现方式中，若所述第二镜像文件的大小小于预设值，所述第一镜像文件中包括所述第二镜像文件对应的哈希描述符，所述哈希描述符包括哈希数据和哈希值，所述哈希数据为第一验证数据，所述哈希值为第一签名数据；
相应的，所述据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据，包括：
从所述第一镜像文件获取所述第二镜像文件对应的哈希描述符中的哈希数据和哈希值；
根据所述哈希数据进行数字签名，获得第三签名数据；
若所述第三签名数据与所述哈希值相同，则所述第二镜像文件的第一签名数据验证通过；
若所述第三签名数据与所述哈希值不同，则所述第二镜像文件的第一签名数据验证失败。
在第一方面的一种实现方式中，若所述第二镜像文件的大小大于预设值，所述第一镜像文件中包括所述第二镜像文件对应的哈希树描述符，所述哈希树描述符包括哈希树数据和根哈希，所述哈希树数据为第一验证数据，所述根哈希为第一签名数据；
相应的，所述据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据，包括：
从所述第一镜像文件获取所述第二镜像文件对应的哈希树描述符中的哈希树数据和根哈希；
根据所述哈希树数据进行数字签名，获得第四签名数据；
若所述第四签名数据与所述根哈希相同，则所述第二镜像文件的第一签名数据验证通过；
若所述第四签名数据与所述根哈希不同，则所述第二镜像文件的第一签名数据验证失败。
在第一方面的一种实现方式中，所述方法还包括：
若多个所述第二镜像文件中的任意一个第二镜像文件验证失败，则系统启动失败。
第二方面，提供一种文件生成方法，应用于服务器，所述方法包括：
在将操作系统的每个组件编译为第二镜像文件之后，获取每个所述第二镜像文件对应的第一验证数据和第一签名数据，其中，所述第二镜像文件对应的第一验证数据用于验证所述第二镜像文件的第一签名数据，所述第一签名数据为根据所述第二镜像文件进行数字签名后得到的数据；
根据每个所述第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件，所述第一镜像文件用于烧录到电子设备中、以使所述电子设备在系统启动的过程中验证所述第二镜像文件。
本申请实施例中，由于生成的第一镜像文件中包含了验证第二镜像文件所需的全部信息(第一验证数据和第一签名数据)，因此，服务器在代码编译过程中，无需为第二镜像文件生成一个vbmeta镜像；在烧录过程中，将第一镜像文件烧录到电子设备中即可，无需烧录各个组件的vbmeta镜像，简化了调试或系统更新流程。相应的，在电子设备内存中为第一镜像文件分配一个vbmeta分区即可，无需为各个组件的vbmeta镜像分配vbmeta分区，节约了存储空间。
在第二方面的一种实现方式中，所述根据每个所述第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件，包括：
生成第二签名数据，所述第二签名数据根据所述电子设备的原始设备制造商设置的密钥签名获得；
根据所述第二签名数据、以及每个所述第二镜像文件对应的第一签名数据和第一验证数据生成所述第一镜像文件。
在第二方面的一种实现方式中，所述根据所述第二签名数据、以及每个所述第二镜像文件对应的第一签名数据和第一验证数据生成所述第一镜像文件，包括：
根据每个所述第二镜像文件对应的第一签名数据和第一验证数据，生成每个所述第二镜像文件对应的哈希描述符或哈希树描述符；
根据所述第二签名数据、以及每个所述第二镜像文件对应的哈希描述符或哈希树描述符，生成所述第一镜像文件。
第三方面，提供一种电子设备，包括处理器，处理器用于运行存储器中存储的计算机程序，实现本申请第一方面任一项所述的方法。
第四方面，提供一种服务器，包括处理器，处理器用于运行存储器中存储的计算机程序，实现本申请第二方面任一项所述的方法。
第五方面，提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被一个或多个处理器执行时实现本申请第一方面任一项所述的方法、或实现本申请第二方面任一项所述的方法。
第六方面，本申请实施例提供了一种计算机程序产品，当计算机程序产品在设备上运行时，使得设备执行上述第一方面中任一项所述的方法、或执行上述第二方面中任一项所述的方法。
第七方面，提供一种芯片系统，包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现本申请第一方面任一项所述的方法、或实现本申请第二方面任一项所述的方法。
附图说明
图1是本申请实施例提供的电子设备操作系统的架构示意图；
图2是本申请实施例提供的基于Android系统的开机启动流程的框架图；
图3是本申请实施例提供的vbmeta分区的示意图；
图4是本申请实施例提供的验证流程示意图；
图5是本申请实施例提供的文件生成流程的示意图；
图6是本申请另一实施例提供的vbmeta分区的示意图；
图7是本申请实施例提供的系统启动流程的示意图；
图8是本申请实施例提供的电子设备的结构示意图；
图9是本申请实施例提供的服务器的结构示意图。
具体实施方式
以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本申请。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请实施例中，“一个或多个”是指一个、两个或两个以上；“和/或”，描述关联对象的关联关系，表示可以存在三种关系；例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B的情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
本申请实施例所提供的方法，可以应用于各种类型的电子设备。例如，本申请实施例中的电子设备可以是手机、平板电脑、笔记本电脑、个人计算机、移动互联网设备(mobileInternet device，MID)、智能销售终端(point or sale，POS)、可穿戴设备、虚拟现实设备(virtual reality，VR)、增强现实设备(augmented reality，AR)、工业控制中的无线终端、无人驾驶中的无线终端、智能家居中的无线终端等等。本申请实施例对电子设备的具体形态不作特殊限定。
根据不同的应用场景，电子设备的表现形式也不同。例如，在传统的移动通信应用场景中，电子设备可以是手机、平板电脑等。在物联网通信的应用场景中，电子设备可以是移动互联网设备、可穿戴设备、智能家居中的无线终端等。
在本申请实施例中，电子设备可以包括硬件层、以及运行在硬件层之上的操作系统。其中，硬件层包括中央处理器(central processing unit，CPU)、内存管理单元(memorymanagement unit，MMU)、内存(也称为主存)、和外围设备等硬件。操作系统可以是安卓(Android)操作系统、IOS系统、Windows系统、Linux系统或其他嵌入式系统等。
以Android系统为例，参见图1，是本申请实施例提供的电子设备操作系统的架构示意图。如图1所示，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，系统运行库层以及内核层。
应用程序层可以包括一系列应用程序包。如图1所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。
如图1所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器等。窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通，挂断等)。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。应用程序框架层可以包括硬件抽象层(Hardware Abstraction Layer，HAL)，HAL位于操作系统内核与硬件电路之间的接口层，用于将硬件抽象化，为了保护硬件厂商的知识产权，它隐藏了特定平台的硬件接口细节，为操作系统提供虚拟硬件平台，使其具有硬件无关性，可在多种平台上进行移植。从软硬件测试的角度来看，软硬件的测试工作都可分别基于硬件抽象层来完成，使得软硬件测试工作的并行进行成为可能。Android的无线接口层(RIL)提供了Android电话服务(androidtelephony)与无线电硬件之间的抽象层。RIL是通讯无关的，提供基于GSM的网络支持。
系统运行库层包括安卓运行时(Android Runtime)和系统库。其中，Androidruntime负责Android系统的调度和管理，其包括核心库和虚拟机。核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是Android的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。系统库能够被Android系统中的不同组件使用，并通过应用程序框架为开发者提供服务，其可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。
内核层是硬件和软件之间的层，用于将为电子设备的各种硬件提供底层驱动。内核层可以包含显示驱动、摄像头驱动、音频驱动、和传感器驱动等。如Linux内核。
首先介绍本申请实施例涉及的技术背景。
下面以Android操作系统为例，介绍电子设备的开机流程。
Android操作系统的启动过程可以分为两个阶段，第一阶段是Linux的启动，第二阶段是Android的启动(可以称为上层开机流程)。参见图2，是本申请实施例提供的基于Android系统的开机启动流程的框架图。如图2所示，开机启动流程包括：
01、Boot ROM——当按开机按键(即电子设备芯片上电)，引导芯片开始从固化在只读存储器(Read-Only Memory，ROM)的预设代码开始执行，加载引导程序到内存并执行。
02、Bootloader，又称引导程序或引导加载程序。Bootloader是Android系统上电后、在操作系统内核运行之前执行的第一段程序，用于初始化硬件设备、建立内存空间映射图，引导系统内核的启动，即Android系统内核的加载和启动由BootLoader来完成。具体的，Bootloader用于把操作系统镜像文件拷贝到内存中，然后跳到镜像文件的入口去执行该文件，也可以称之为进入启动加载模式。
03、kernel，即内核。将内核加载进内存后，首先进入内核引导阶段，在内核引导阶段的最后，调用start_kernel进入内核启动阶段，主要是完成内核的大部分初始化工作。Start_kernel会最终启动用户空间的init进程。
04、init进程，又称初始化进程。当初始化内核之后，就会启动init进程，在Linux中所有的进程都是由init进程直接或间接创建出来的。init进程负责创建系统中最关键的几个核心daemon(守护)进程，包括但不限于孵化器(zygote)进程和服务管理者(servicemanager)进程。其中，zygote是android启动的第一个dalvik虚拟机，它负责启动Java进程。service manager是Binder通信的基础。
05、Zygote进程，又称孵化器进程。该进程是所有Java进程的父进程。例如，zygote虚拟机启动子进程system_server，同时定义了一个套接字(Socket)，用于接收ActivityManagerService启动应用程序的请求。
06、System Server进程，又称系统服务进程。在System Server进程开启的时候，会初始化ActivityManagerService。同时，会加载本地系统的服务库，调用createSystemContext()创建系统上下文，创建ActivityThread及开启各种服务等等。
07、Home Activity，在ActivityManagerService开启之后，会调用finishBooting()完成引导过程，同时发送开机广播，进入home界面，显示桌面。
需要说明的是，此处给出的描述仅是Android系统启动过程的一种情形，不同版本的Android系统可能在某些步骤的细节上做了一些调整，但原理相同，此处并不做具体限定。
在上述开机流程中，Bootloader会对操作系统镜像文件进行合法性校验。由于Android系统是一个基于内核的操作系统，因此在启动的过程中，可以依次将启动操作系统的内核镜像(boot.img)和主系统镜像加载至内存，并在内存中验证每种镜像的合法性，若所有镜像文件均通过合法性验证，再将内核加载到内存；若任一镜像文件合法性验证失败，则Android系统无法正常启动。
启动验证过程中，会尽力确保所有已执行代码均来自可信来源(通常是电子设备的原始设备制造商OEM)，以防受到攻击或损坏。通过启动验证，可建立一条从受硬件保护的信任根到引导加载程序，再到boot分区和其他已验证分区(如下述示例中的各个需要验证的分区)的完整信任链。
Android系统中，通常会把zImage(内核镜像uImage文件)和ramdisk.img(磁盘镜像)打包到一起，生成一个boot.img镜像文件，放到boot分区，由bootloader来引导启动。
boot.img验证成功后，再验证其他主系统镜像。示例性的，在一些Android系统架构中，主系统镜像可以包括system.img(系统组件的镜像文件)、vendor.img(芯片组件的镜像文件)、odm.img(产品组件中硬件配置组件的镜像文件)、product.img(产品组件中通用配置组件的镜像文件)、cust.img(定制组件的镜像文件)、version.img(版本组件的镜像文件)、以及preload.img(预装组件的镜像文件)等。
在内存中为每个镜像文件分区，可以镜像文件名称作为分区名称。例如，system.img对应的分区称为system分区，vendor.img对应的分区称为vendor分区，product.img对应的分区称为product分区，cust.img对应的分区称为cust分区，version.img对应的分区称为version分区，preload.img对应的分区称为preload分区。上述只是分区示例，不同的Android系统架构的分区方式和分区名称可能不同，此处并不作具体限定。
AVB验证启动流程
相关技术中，采用AVB(Android verify boot)机制进行启动验证。该机制能够防止启动镜像被篡改，提高操作系统的抗攻击能力。AVB机制中，引入一个新的分区——验证启动元数据(verified boot metadata，vbmeta)分区。在代码编译阶段将所需验证的各个分区的相关信息打包为镜像文件vbmeta.img，存储到vbmeta分区。在启动验证过程中，通过验证vbmeta.img来获取其他分区的签名信息并验证。
在一些应用场景中，如操作系统更新、调试场景，开发人员在服务器侧更新代码。服务器在代码编译阶段，vbmeta.img在芯片组件中拍包。具体的，将操作系统的各个组件生成镜像文件(如boot.img、system.img、vendor.img等)，并且为每个镜像文件生成一个vbmeta镜像。例如，system.img的vbmeta镜像为vbmeta_system_img，vendor.img的vbmeta镜像为vbmeta_vendor_img。每个vbmeta镜像中包括其对应组件的签名数据。将各个组件的vbmeta镜像的描述符(该描述符可以为链式描述符)编译生成vbmeta.img文件。在烧录过程中，将vbmeta.img文件以及各个组件的vbmeta镜像文件均烧录到电子设备中。在电子设备启动过程中，利用已烧录的vbmeta.img和各个组件对应的vbmeta镜像进行启动验证。
相应的，需要在电子设备内存中为每个vbmeta镜像分配一个vbmeta分区。示例性的，如下表所示：
partition Name size
0 vbmeta_system 1MB
1 vbmeta_system_ext 1MB
2 vbmeta_vendor 1MB
3 vbmeta_vendor_dlkm 1MB
4 vbmeta_system_dlkm 1MB
5 Vbmeta_preas 1MB
6 vbmeta_preavs 1MB
7 vbmeta_preload 1MB
8 vbmeta_cust 1MB
9 vbmeta_product 1MB
10 vbmeta_product_h 1MB
11 vbmeta_odm 1MB
如上表所示，vbmeta_system分区存储system.img的vbmeta镜像vbmeta_system_img，vbmeta_vendor分区存储vendor.img的vbmeta镜像vbmeta_vendor_img。可见，除vbmeta.img所占的vbmeta分区外，各个组件对应的vbmeta镜像各自占一个vbmeta分区，换言之，需要在电子设备内存中分配多个vbmeta分区。
AVB中使用的中心数据结构是vbmeta结构体，这个数据结构包含多个链式分区描述符(和其他元数据)，所有这些数据都是加密签名的。参见图3，是本申请实施例提供的vbmeta分区的示意图。如图3所示，vbmeta分区31中的vbmeta.img中包含签名(如图3的31分区中的signature)和加密后的vbmeta结构体，vbmeta结构体中包括多个链式分区描述符(如图3中31分区中的AvbChainPartitionDescriptor)。每个链式分区描述符中包含其所引导的vbmeta镜像的名称和该vbmeta镜像中签名数据所信任的公钥(如图3的32框中所示的名称Partition_name和公钥Public_key)。需要说明的是，图3中仅示出了与本案相关的部分信息，实际应用中，链式分区描述符中还可以包括其他信息，每个vbmeta分区的vbmeta.img中也可以包括其他信息，在此不做具体限定。
在启动验证过程中，bootloader利用OEM key(OEM提供的一个固定的不可篡改的密钥)验证vbmeta.img中的签名signature，从而信任vbmeta.img。vbmeta.img中的签名signature验证成功后，根据vbmeta结构体中的各个链式分区描述符包括的名称从其所引导的vbmeta镜像中读取该vbmeta镜像的签名数据，根据链式分区描述符中的公钥验证该vbmeta镜像中的签名数据。换言之，链式分区描述符相当于一个索引，vbmeta.img中包含的是各个vbmeta镜像的索引，该索引用于链接到各个vbmeta分区中的vbmeta镜像。
参见图4，是本申请实施例提供的验证流程示意图。如图4所示，验证流程包括以下步骤：
S401，读取vbmeta.img。
S402，验证vbmeta.img，即利用OEM key验证vbmeta.img中的签名signature。
遍历vbmeta.img中的链式分区描述符。
S403，对于任意一个链式分区描述符，根据该链式分区描述符中的名称链接到相应的vbmeta分区；
S404，读取该vbmeta分区中的vbmeta镜像。
S405，验证读取到的vbmeta镜像，即利用链式分区描述符中的公钥验证读取到的vbmeta镜像中的签名数据。
以system分区验证为例，读取vbmeta.img，首先利用OEM key验证vbmeta.img中的签名signature；若验证成功，读取组件system对应的链式分区描述符；根据该链式分区描述符中的名称链接到组件system对应的vbmeta分区；读取该vbmeta分区中的vbmeta镜像vbmeta_system_img；利用组件system对应的链式分区描述符中的公钥验证vbmeta_system_img中的签名数据(如图3所示的signature_system)。
2、解决问题
如上所述，需要在内存中为每个组件的vbmeta镜像分配一个vbmeta分区，即需要分配多个vbmeta分区，占用较多存储空间。调试过程中，不仅需要烧录各个组件的镜像文件，还需要烧录各个组件对应的vbmeta镜像。后续如果新增加一个逻辑分区，需要相应增加一个vbmeta分区。这种方式不仅浪费存储空间，还增加了调试的繁琐程度。另外，在开机启动验证过程中，需要根据vbmeta.img中的链式分区描述符索引到相应组件的vbmeta镜像，从vbmeta镜像中获取签名数据，再利用链式分区描述符中的公钥对签名数据进行验证。这种验证方式较为繁琐，影响开机速度。
为了解决上述问题，本申请实施例提供了一种系统启动方法和文件生成方法。本申请实施例中，在所有组件镜像生成后，统一把所有组件镜像的签名数据拍包到vbmeta.img中，只保留一个vbmeta分区，该vbmeta.img保存了所有组件镜像的签名数据，通过本申请实施例中的方法，减少了多余的vbmeta分区，节约了存储空间，便于调试，同时优化了开机速度。
下面分别从服务器侧和电子设备侧描述本申请实施例提供的方法。
参见图5，是本申请实施例提供的文件生成流程的示意图。本申请实施例提供的方法应用于服务器。作为示例而非限定，如图5所示，所述方法可以包括以下步骤：
S501，在将操作系统的每个组件编译为第二镜像文件之后，获取每个第二镜像文件对应的第一验证数据和第一签名数据。
第二镜像文件对应的第一验证数据用于验证该第二镜像文件的第一签名数据，第一签名数据是根据第二镜像文件进行数字签名后得到的数据。
本申请实施例中的第一验证数据相当于上述步骤S406中链式分区描述符包括的公钥。本申请实施例中所述的第二镜像文件为启动系统过程中所需验证组件的镜像文件，如上述的boot.img、system.img、ventor.img和cust.img等，而非vbmeta镜像。
S502，根据每个第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件(vbmeta.img)。
本申请实施例中，vbmeta.img中包括多个第二镜像文件各自对应的描述符，本申请实施例中将这些描述符称为哈希描述符或哈希树描述符(也可称为散列描述符和散列树描述符)。每个第二镜像文件对应的哈希描述符或哈希树描述符中包括该第二镜像文件的第一验证数据和第一签名数据。对比可知，哈希描述符或哈希树描述符与上述的链式分区描述符的不同之处在于，链式分区描述符中包含的是vbmeta镜像的名称和第一验证数据。换言之，链式分区描述符中并未包含第一签名数据，而是将第一签名数据存储到过vbmeta镜像的名称所引导的vbmeta镜像中。
在一些应用场景中，服务器中设置两条进程，一条进程用于将操作系统的各个组件编译为第二镜像文件，该进程将各个组件的第二镜像文件的获取路径传参给另一条进程，由另一条进程实现上述S501-S502中所述的方法。
在另一些应用场景中，可以将拍包(生成镜像文件)程序生成应用软件，下述称为拍包工具。服务器将操作系统的每个组件编译为第二镜像文件之后，服务器将各个组件的第二镜像文件的获取路径传参给拍包工具；拍包工具执行上述S501-S502，即根据获取路径获取各个第二镜像文件的第一验证数据和第一签名数据，再根据每个第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件(vbmeta.img)。
示例性的，如下所示，为拍包工具拍包过程的代码示例：
out/host/linux-x86/bin/avbtoolmake_vbmeta_image/*执行命令*/
--output～/vbmeta.img/*输出路径*/.
--algorithm SHA256_RSA4096/*算法*/
--include_descriptors_from_image～/system.img/*vbmeta拍包的镜像组成*/
--include_descriptors_from_image～/system_ext.img
--include_descriptors_from_image～/system_dlkm.img
--include_descriptors_from_image～/product.img
--include_descriptors_from_image～/product_h.img
--include_descriptors_from_image～/preload.img
--include_descriptors_from_image～/preavs.img
--include_descriptors_from_image～/preas.img
--include_descriptors_from_image～/odm.img
--include_descriptors_from_image～/vbmeta/cust.img
--include_descriptors_from_image～/vendor.img
--include_descriptors_from_image～/vendor_dlkm.img
--include_descriptors_from_image～/version.img
--key
vendor/honor/common/build/vb_pub_key/common/VB_release_vbmeta_v20.pem/*镜像秘钥*/
--rollback_index 0/*回滚指数*/
--signing_helper_with_files
vendor/honor/common/build/tools/sign.py/*签名脚本*/
--padding_size 4096/*填充单位*/
在一个实施例中，S502可以包括以下步骤：
生成第二签名数据，所述第二签名数据根据所述电子设备的原始设备制造商设置的密钥签名获得；根据第二签名数据、以及每个第二镜像文件对应的第一签名数据和第一验证数据生成第一镜像文件。
本申请实施例中的第二签名数据相当于上述S402中vbmeta.img的签名signature。实际应用中，可以对OEM key(电子设备的原始设备制造商设置的密钥)进行签名，得到第一签名。
可选的，根据第二签名数据、以及每个第二镜像文件对应的第一签名数据和第一验证数据生成第一镜像文件的步骤可以包括：
根据每个第二镜像文件对应的第一签名数据和第一验证数据，生成每个第二镜像文件对应的哈希描述符或哈希树描述符；根据第二签名数据、以及每个第二镜像文件对应的哈希描述符或哈希树描述符，生成第一镜像文件。
若第二镜像文件较小(如文件大小小于预设值)，在启动验证过程中通常将其整体加载到内存中，然后通过计算其哈希值进行验证，所以这类第二镜像文件对应的是哈希描述符。哈希描述符中的第一验证数据用于镜像第二镜像文件的哈希，第一签名数据为哈希值(根据第二镜像文件进行数字签名得到的数据)。验证过程中，根据第一验证数据进行数字签名；若签名得到的哈希值与第一签名数据相同，则验证通过；反之，则验证失败。
若第二镜像文件较大(如文件大小大于预设值)，在启动验证过程中通常无法将其整体加载到内存中，而是随着将数据加载到内存的过程持续验证。这种情况下，通常使用哈希树，通过计算其根哈希进行验证，所以这类第二镜像文件对应的是哈希树描述符。哈希树描述符中的第一验证数据用于镜像第二镜像文件的哈希树(包括根哈希、加盐值和偏移量等数据)，第一签名数据为根哈希(根据第二镜像文件的哈希树进行数字签名得到数据)。验证过程中，根据第一验证数据进行数字签名；若签名得到的根哈希与第一签名数据相同，则验证通过；反之，则验证失败。
例如，system.img对应的是哈希树描述符，该哈希树描述符包括system.img的镜像哈希树(第一验证数据)以及用于验证的根哈希(第一签名数据)。再例如，boot.img对应的是哈希描述符，该哈希描述符包括boot.img的镜像哈希(第一验证数据)以及用于验证的哈希值(第一签名数据)。
参见图6，是本申请另一实施例提供的vbmeta分区的示意图。如图6所示，vbmeta分区(第一镜像文件vbmeta.img)中包括头信息(AvbVBMetaImageHeader)、第二签名数据signature、哈希描述符(如boot Hash descriptor)和多个哈希树描述符(如systemHashtree descriptor、vendor Hashtree descriptor和cust Hashtree descriptor等)和公钥Public Key。Boot.img对应的哈希描述符boot Hash descriptor中包括boot.img的镜像Hash和签名数据signature_boot。system.img对应的哈希树描述符system Hashtreedescriptor中包括system.img的镜像Hashtree和签名数据signature_system。
根据图6和图3可以看出，本申请实施例与上述的相关技术相比区别在于，由于根据上述步骤S501-S502生成的vbmeta.img中的哈希描述符或哈希树描述符包含了验证第二镜像文件所需的全部信息，因此，服务器在代码编译过程中，无需为第二镜像文件生成一个vbmeta镜像(图3中存在多个vbmeta分区，图6中仅存在一个vbmeta分区)；在烧录过程中，将vbmeta.img烧录到电子设备中即可，无需烧录各个组件的vbmeta镜像，简化了调试或系统更新流程。相应的，在电子设备内存中为vbmeta.img分配一个vbmeta分区即可，无需为各个组件的vbmeta镜像分配vbmeta分区，节约了存储空间。
另外，上述相关技术中，服务器是在组件编译过程中生成各个组件的vbmeta镜像。每次调试或更新，都需要重新生成多个vbmeta镜像，调试过程繁琐。而本申请上述方法，只需更新vbmeta.img，大大简化了调试过程。
基于上述S501-S502描述的vbmeta.img(第一镜像文件)的生成过程，相应的，电子设备在系统启动的过程中，利用vbmeta.img中的哈希描述符或哈希树描述符验证各个组件的镜像文件(第二镜像文件)。参见图7，是本申请实施例提供的系统启动流程的示意图。作为示例而非限定，如图7所示，在电子设备开机启动验证过程中，可以包括以下步骤：
S701，在电子设备进行系统启动的过程中，读取第一镜像文件(vbmeta.img)。
如上述图5实施例所述，第一镜像文件中包括多个第二镜像文件各自对应的第一验证数据和第一签名数据。
S702，根据多个第二镜像文件各自的第一签名数据分别验证每个第二镜像文件。
在一些实施例中，vbmeta.img中包括第二签名数据signature，与上述图5所示的文件生成方法相对应，该第二签名数据根据所述电子设备的原始设备制造商设置的密钥签名获得。相应的，S702可以包括：
验证第二签名数据；
若第二签名数据验证通过，则根据多个第二镜像文件各自的第一签名数据分别验证每个第二镜像文件；
若第二签名数据验证失败，则系统启动失败。
具体的，验证第二签名数据的过程包括：
从用于启动系统的引导程序bootloader中获取第二验证数据OEM key，第二验证数据为电子设备的原始设备制造商设置的密钥；根据第二验证数据验证第二签名数据。
可以对第二验证数据OEM key进行签名，若得到的签名数据与第二签名数据一致，则验证通过；反之，验证失败。需要说明的是，对第二验证数据进行签名的算法与生成第二签名数据使用的算法一致。
本申请实施例中，通过设置第二签名数据，在启动验证过程中，bootloader利用OEM key验证vbmeta.img中的第二签名数据，从而信任vbmeta.img，提高了数据安全性。
如图5实施例中所述，根据第二镜像文件的大小，生成的第二镜像文件的描述符不同，可能为哈希描述符，也可以为哈希树描述符。哈希描述符中包含的第一验证数据为哈希数据(用于镜像第二镜像文件的哈希)，哈希树描述符中包含的第一验证数据为哈希树数据(用于镜像第二镜像文件的哈希树)。
相应的，若第二签名数据验证通过，根据每个第二镜像文件的第一签名数据验证每个第二镜像文件的步骤可以包括：
若第二镜像文件的大小小于预设值，从第一镜像文件获取第二镜像文件对应的哈希描述符中的哈希数据，根据该哈希数据(第一验证数据)验证第二镜像文件的第一签名数据。具体的，根据第二镜像文件的哈希数据进行数字签名，获得第三签名数据；若所述第三签名数据与第二镜像文件的哈希值相同，则第一签名数据验证通过；若所述第三签名数据与第二镜像文件的哈希值不同，则所述第一签名数据验证失败。
若第二镜像文件的大小大于预设值，从第一镜像文件获取第二镜像文件对应的哈希树描述符中的哈希树数据，根据该哈希树数据(第一验证数据)验证第二镜像文件的第一签名数据。具体的，根据第二镜像文件的哈希树数据进行数字签名，获得第四签名数据；若所述第四签名数据与第二镜像文件的根哈希相同，则第一签名数据验证通过；若所述第四签名数据与第二镜像文件的根哈希不同，则第一签名数据验证失败。
S703，若多个第二镜像文件均验证通过，则启动系统。
S704，若多个第二镜像文件中的任意一个第二镜像文件验证失败，则系统启动失败。
通常，在启动验证过程中，依次验证每个第二镜像文件。若当前第二镜像文件验证失败，则不再进行下一个第二镜像文件的验证。
示例性的，在一些应用场景中，vbmeta.img验证通过后，先验证boot.img；若boot.img验证通过，则依次验证其他分区，如system.img、vendor.img等。
根据图4和图7进行比对，图7实施例与图4实施例中所述的系统启动方法相比区别在于，图4实施例中的vbmeta.img的链式分区描述符相当于一个链接；在系统启动验证过程中，根据vbmeta.img中的链式分区描述符链接到其所引导的另一个vbmeta镜像，再从该vbmeta镜像中获取组件镜像文件的签名数据。而图7实施例中的vbmeta.img的哈希描述符或哈希树描述符中包含了验证所需的全部信息，即签名数据和验证数据；在系统启动验证过程中，从vbmeta.img的哈希描述或哈希树描述符中获取各个组件的镜像文件的签名数据和验证数据，即可进行验证。图7实施例所述的方法，简化了开机流程，从而节约了开机启动时间。
应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
图8是本申请实施例提供的电子设备的结构示意图。如图8所示，该实施例的电子设备8包括：至少一个处理器80(图8中仅示出一个)处理器、存储器81以及存储在所述存储器81中并可在所述至少一个处理器80上运行的计算机程序82，所述处理器80执行所述计算机程序82时实现上述任意各个系统启动方法实施例中的步骤。
所述电子设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该电子设备可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，图8仅仅是电子设备8的举例，并不构成对电子设备8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。
所称处理器80可以是中央处理单元(Central Processing Unit，CPU)，该处理器80还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器81在一些实施例中可以是所述电子设备8的内部存储单元，例如电子设备8的硬盘或内存。所述存储器81在另一些实施例中也可以是所述电子设备8的外部存储设备，例如所述电子设备8上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述电子设备8的内部存储单元也包括外部存储设备。所述存储器81用于存储操作系统、应用程序、引导装载程序(Boot Loader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。
图9是本申请实施例提供的服务器的结构示意图。如图9所示，该实施例的服务器9包括：至少一个处理器90(图9中仅示出一个)处理器、存储器91以及存储在所述存储器91中并可在所述至少一个处理器90上运行的计算机程序92，所述处理器90执行所述计算机程序92时实现上述任意各个文件生成方法实施例中的步骤。
所述服务器可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。该服务器可包括，但不仅限于，处理器、存储器。本领域技术人员可以理解，图9仅仅是服务器9的举例，并不构成对服务器9的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。
服务器可以与电子设备通信连接，以将生成的第一镜像文件发送给电子设备。服务器还可以与烧录设备通信连接，烧录设备与电子设备连接；烧录过程中，服务器将生成的第一镜像文件发送给烧录设备，烧录设备将第一镜像文件烧录到电子设备中。
所称处理器90可以是中央处理单元(Central Processing Unit，CPU)，该处理器90还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器91在一些实施例中可以是所述服务器9的内部存储单元，例如服务器9的硬盘或内存。所述存储器91在另一些实施例中也可以是所述服务器9的外部存储设备，例如所述服务器9上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器91还可以既包括所述服务器9的内部存储单元也包括外部存储设备。所述存储器91用于存储操作系统、应用程序(如拍包工具)、引导装载程序(Boot Loader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器91还可以用于暂时地存储已经输出或者将要输出的数据。
本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时可实现上述各个系统启动方法实施例中的步骤，或实现上述各个文件生成方法实施例中的步骤。
本申请实施例还提供了一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备可实现上述各个系统启动方法实施例中的步骤，或实现上述各个文件生成方法实施例中的步骤。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质至少可以包括：能够将计算机程序代码携带到第一设备的任何实体或装置、记录介质、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
本申请实施例还提供了一种芯片系统，芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现上述各个系统启动方法实施例中的步骤，或实现上述各个文件生成方法实施例中的步骤。芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
最后应说明的是：以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种系统启动方法，其特征在于，应用于电子设备，所述方法包括：
在所述电子设备进行系统启动的过程中，读取第一镜像文件，所述第一镜像文件中包括多个第二镜像文件各自的第一签名数据；
根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件；
若多个所述第二镜像文件均验证通过，则启动系统。
2.根据权利要求1所述的系统启动方法，其特征在于，所述第一镜像文件中还包括第二签名数据；
所述根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件，包括：
验证所述第二签名数据；
若所述第二签名数据验证通过，则根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件。
3.根据权利要求2所述的系统启动方法，其特征在于，所述验证所述第二签名数据，包括：
从用于启动系统的引导程序中获取第二验证数据，所述第二验证数据为所述电子设备的原始设备制造商设置的密钥；
根据所述第二验证数据验证所述第二签名数据。
4.根据权利要求1至3任一项所述的系统启动方法，其特征在于，所述第一镜像文件中还包括多个所述第二镜像文件各自的第一验证数据；
所述根据多个所述第二镜像文件各自对应的第一签名数据分别验证每个所述第二镜像文件，包括：
对于每个所述第二镜像文件，根据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据；
若所述第二镜像文件的第一签名数据验证通过，则判定所述第二镜像文件验证通过；
若所述第二镜像文件的第一签名数据验证失败，则判定所述第二镜像文件验证失败。
5.根据权利要求4所述的系统启动方法，其特征在于，若所述第二镜像文件的大小小于预设值，所述第一镜像文件中包括所述第二镜像文件对应的哈希描述符，所述哈希描述符包括哈希数据和哈希值，所述哈希数据为第一验证数据，所述哈希值为第一签名数据；
相应的，所述据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据，包括：
从所述第一镜像文件获取所述第二镜像文件对应的哈希描述符中的哈希数据和哈希值；
根据所述哈希数据进行数字签名，获得第三签名数据；
若所述第三签名数据与所述哈希值相同，则所述第二镜像文件的第一签名数据验证通过；
若所述第三签名数据与所述哈希值不同，则所述第二镜像文件的第一签名数据验证失败。
6.根据权利要求4所述的系统启动方法，其特征在于，若所述第二镜像文件的大小大于预设值，所述第一镜像文件中包括所述第二镜像文件对应的哈希树描述符，所述哈希树描述符包括哈希树数据和根哈希，所述哈希树数据为第一验证数据，所述根哈希为第一签名数据；
相应的，所述据所述第二镜像文件的第一验证数据验证所述第二镜像文件的第一签名数据，包括：
从所述第一镜像文件获取所述第二镜像文件对应的哈希树描述符中的哈希树数据和根哈希；
根据所述哈希树数据进行数字签名，获得第四签名数据；
若所述第四签名数据与所述根哈希相同，则所述第二镜像文件的第一签名数据验证通过；
若所述第四签名数据与所述根哈希不同，则所述第二镜像文件的第一签名数据验证失败。
7.根据权利要求1至6任一项所述的系统启动方法，其特征在于，所述方法还包括：
若多个所述第二镜像文件中的任意一个第二镜像文件验证失败，则系统启动失败。
8.一种文件生成方法，其特征在于，应用于服务器，所述方法包括：
在将操作系统的每个组件编译为第二镜像文件之后，获取每个所述第二镜像文件对应的第一验证数据和第一签名数据，其中，所述第二镜像文件对应的第一验证数据用于验证所述第二镜像文件的第一签名数据，所述第一签名数据为根据所述第二镜像文件进行数字签名后得到的数据；
根据每个所述第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件，所述第一镜像文件用于烧录到电子设备中、以使所述电子设备在系统启动的过程中验证所述第二镜像文件。
9.根据权利要求8所述的文件生成方法，其特征在于，所述根据每个所述第二镜像文件对应的第一验证数据和第一签名数据生成第一镜像文件，包括：
生成第二签名数据，所述第二签名数据根据所述电子设备的原始设备制造商设置的密钥签名获得；
根据所述第二签名数据、以及每个所述第二镜像文件对应的第一签名数据和第一验证数据生成所述第一镜像文件。
10.根据权利要求9所述的文件生成方法，其特征在于，所述根据所述第二签名数据、以及每个所述第二镜像文件对应的第一签名数据和第一验证数据生成所述第一镜像文件，包括：
根据每个所述第二镜像文件对应的第一签名数据和第一验证数据，生成每个所述第二镜像文件对应的哈希描述符或哈希树描述符；
根据所述第二签名数据、以及每个所述第二镜像文件对应的哈希描述符或哈希树描述符，生成所述第一镜像文件。
11.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于运行存储器中存储的计算机程序，以实现如权利要求1至7任一项所述的方法。
12.一种服务器，其特征在于，所述服务器包括处理器，所述处理器用于运行存储器中存储的计算机程序，以实现如权利要求8至10任一项所述的方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被一个或多个处理器执行时实现如权利要求1至7任一项所述的方法，或实现如权利要求8至10任一项所述的方法。
CN202211475664.4A 2022-11-23 2022-11-23 系统启动方法、文件生成方法、电子设备及服务器 Active CN116661876B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211475664.4A CN116661876B (zh) 2022-11-23 2022-11-23 系统启动方法、文件生成方法、电子设备及服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211475664.4A CN116661876B (zh) 2022-11-23 2022-11-23 系统启动方法、文件生成方法、电子设备及服务器

Publications (2)

Publication Number Publication Date
CN116661876A true CN116661876A (zh) 2023-08-29
CN116661876B CN116661876B (zh) 2024-04-05

Family

ID=87715950

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211475664.4A Active CN116661876B (zh) 2022-11-23 2022-11-23 系统启动方法、文件生成方法、电子设备及服务器

Country Status (1)

Country Link
CN (1) CN116661876B (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107729198A (zh) * 2017-10-18 2018-02-23 深圳合纵富科技有限公司 一种Android系统固件校验方法及装置
CN112784280A (zh) * 2021-01-12 2021-05-11 苏州浪潮智能科技有限公司 一种SoC芯片安全设计方法及硬件平台
CN113127262A (zh) * 2020-01-13 2021-07-16 北京地平线机器人技术研发有限公司 镜像文件的生成方法、装置、电子设备及存储介质
CN114547618A (zh) * 2020-11-25 2022-05-27 广东朝歌智慧互联科技有限公司 基于Linux系统的安全启动方法、装置、电子设备及存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107729198A (zh) * 2017-10-18 2018-02-23 深圳合纵富科技有限公司 一种Android系统固件校验方法及装置
CN113127262A (zh) * 2020-01-13 2021-07-16 北京地平线机器人技术研发有限公司 镜像文件的生成方法、装置、电子设备及存储介质
CN114547618A (zh) * 2020-11-25 2022-05-27 广东朝歌智慧互联科技有限公司 基于Linux系统的安全启动方法、装置、电子设备及存储介质
CN112784280A (zh) * 2021-01-12 2021-05-11 苏州浪潮智能科技有限公司 一种SoC芯片安全设计方法及硬件平台

Also Published As

Publication number Publication date
CN116661876B (zh) 2024-04-05

Similar Documents

Publication Publication Date Title
US9081596B2 (en) Information processing device, virtual machine creation method, and application distribution system
US8904518B2 (en) Information processing device, information processing method, and program distribution system
JP6649510B2 (ja) パッチアップグレードに基づくファイル処理方法及び機器、端末、並びに記憶媒体
CN108847950B (zh) 电子装置、云系统软件自动部署方法及存储介质
US9336018B2 (en) Mechanism for class data sharing using extension and application class-loaders
US10019598B2 (en) Dynamic service discovery
US7873960B2 (en) Generic packaging tool for packaging application and component therefor to be installed on computing device
CN107577937B (zh) 一种应用程序保护方法及系统
US20200320189A1 (en) Processing method for container security policy and related apparatus
CN112769706B (zh) 组件化路由方法及系统
CN114661540A (zh) 测量容器
Votipka et al. Passe-partout: A general collection methodology for Android devices
CN116467015B (zh) 镜像生成方法、系统启动校验方法及相关设备
CN116661876B (zh) 系统启动方法、文件生成方法、电子设备及服务器
US11044096B2 (en) Blockchain based digital identity generation and verification
EP3992783A1 (en) Patch releasing method, server and terminal device
CN111880828A (zh) 一种在Secure Boot环境中批量升级多板卡驱动的方法
US20230385046A1 (en) Method and System for Repairing Device Tree, and Computer-Readable Storage Medium
CN111782230B (zh) 程序安装控制方法、装置和电子设备
US20220308956A1 (en) Verifying object file canisters using built-in reverse relocation integrity checking
US20240168768A1 (en) Method for packaging driver kernel module, electronic device and storage medium
CN112346712A (zh) 系统客制化方法、装置及计算机可读存储介质
CN115185634A (zh) 一种子系统实现方法及计算设备
CN115543374A (zh) 方案生成方法、设备升级方法及相关装置、设备和介质
CN116820554A (zh) 功能组件的升级方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant