Method and apparatus for starting operating system

Abstract

The embodiment of the present application provides a kind of operating system starting method and device.The method comprises: after the embedded device is powered on, based on boot loader, access RPMB after hardware authentication;According to the reference GPT stored in the user data area, the real-time hash value of the reference GPT is calculated;If it is determined that the real-time hash value is consistent with the reference hash value stored in the RPMB, then according to the reference GPT, the sector address of operating system image is located, and the operating system is started;If it is determined that the real-time hash value is inconsistent with the reference hash value, then according to the backup GPT stored in the RPMB, the reference GPT stored in the user data area is updated, and according to the sector address of operating system image located by the updated reference GPT, the operating system is started.The method is used to achieve the effect of improving the reliability and security of operating system startup.

Description

Technical Field

[0001] This application relates to the field of embedded system secure storage and trusted boot technology, and in particular to an operating system boot method and apparatus. Background Technology

[0002] As the intelligence level of in-vehicle systems increases, in-vehicle infotainment (IVI) systems are gradually integrating operating systems, applications, communication modules, and security functions. The reliability and security of their startup links directly affect the overall vehicle operation safety.

[0003] During the operating system startup process, the bootloader relies on a globally unique partition table (GUID Partition Table, GPT) to locate the operating system image partition. However, in traditional solutions, critical startup data such as the GPT partition table are stored in the user data area of ​​the storage device. This area lacks hardware-level security protection and is susceptible to data inconsistencies caused by physical damage, malicious tampering, or abnormal power outages, which can prevent the operating system from booting. Summary of the Invention

[0004] The operating system startup method and apparatus provided in this application are used to improve the reliability and security of operating system startup.

[0005] In a first aspect, embodiments of this application provide an operating system boot method, the method being applied to an embedded device, the embedded device being configured with a storage device, the storage device including a user data area and a replay protection memory block area (RPMB); the RPMB storing a base hash value of a globally unique identifier partition table (GPT) and a backup GPT; including:

[0006] After the embedded device is powered on, it accesses the RPMB after hardware authentication based on the bootloader;

[0007] Calculate the real-time hash value of the benchmark GPT based on the benchmark GPT stored in the user data area;

[0008] If it is determined that the real-time hash value is consistent with the baseline hash value stored in the RPMB, then the operating system image sector address is located according to the baseline GPT, and the operating system is started.

[0009] If it is determined that the real-time hash value is inconsistent with the baseline hash value, the baseline GPT stored in the user data area is updated according to the backup GPT stored in the RPMB, and the sector address of the operating system image is located according to the updated baseline GPT, and the operating system is started.

[0010] In one possible implementation, the RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores activity record information and candidate record information; updating the baseline GPT stored in the user data area according to the backup GPT stored in the RPMB includes:

[0011] Based on the activity record information and the candidate record information, determine the current active region from the first storage region and the second storage region;

[0012] Obtain the backup GPT from the currently active region;

[0013] The backup GPT is verified for integrity, and the baseline GPT stored in the user data area is updated based on the backup GPT after the verification is successful.

[0014] In one possible implementation, the activity record information includes a base hash value, an activity region identifier, and a valid version number; the candidate record information includes a candidate activity region identifier, a candidate GPT hash value, a data submission status identifier for the candidate record information, and a candidate version number.

[0015] The step of determining the current active region from the first storage region and the second storage region based on the activity record information and the candidate record information includes:

[0016] If it is determined that the data submission status identifier of the candidate record information is invalid, then the storage area corresponding to the active area identifier is taken as the current active area;

[0017] If the data submission status identifier of the candidate record information is determined to be valid, then it is verified whether the candidate version number is equal to the valid version number plus one, whether the data submission status identifier of the storage area corresponding to the candidate activity area identifier is valid, and whether the hash value of the GPT stored in the storage area corresponding to the candidate activity area identifier is consistent with the hash value of the candidate GPT; if the verification results are all yes, then the storage area corresponding to the candidate activity area identifier is taken as the current activity area; if the verification results are no, then the storage area corresponding to the activity area identifier is taken as the current activity area.

[0018] In one possible implementation, the RPMB includes a metadata area; the metadata area stores the slot status and active slot identifier of the operating system image's slots; the step of locating the sector address of the operating system image according to the reference GPT and starting the operating system, or the step of locating the sector address of the operating system image according to the updated reference GPT and starting the operating system, includes:

[0019] The target boot slot is determined based on the slot status and active slot identifier of the operating system image.

[0020] Based on the target GPT, determine the sector address of the target boot slot in the user data area, load the operating system image stored in the target boot slot, and start the operating system; wherein, the target GPT is the base GPT or an updated base GPT.

[0021] In one possible implementation, determining the target boot slot based on the slot status and active slot identifier of the operating system image includes:

[0022] If the slot status of the slot corresponding to the active slot identifier is determined to be confirmed, then the slot corresponding to the active slot identifier is determined as the target startup slot.

[0023] If it is determined that the slot status of the slot corresponding to the active slot identifier is in the starting state, and the slot status of all slots is in the starting state, then the slot corresponding to the active slot identifier is determined as the target starting slot.

[0024] If it is determined that the slot corresponding to the active slot identifier is in a rollback state, and the slot of another slot is in a non-rollback state, then the other slot is determined as the target startup slot.

[0025] In one possible implementation, the RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores active record information and candidate record information; the method further includes:

[0026] Obtain system update data; the system update data includes the new GPT, the new hash value of the new GPT, new configuration parameter information, new version number, and new slot information;

[0027] The system update data is written to the current inactive region via the write authentication frame of the RPMB; wherein, the current inactive region refers to the storage region in the first storage region and the second storage region that is not pointed to by the active region identifier in the activity record information;

[0028] After the write operation is completed, the data commit status flag of the currently inactive region is set to valid, and the data version number of the currently inactive region is updated to the new version number;

[0029] Based on the current inactive region, the new version number, and the new hash value, candidate record information is generated and written into the metadata area;

[0030] If it is confirmed that the data stored in the current inactive region is consistent with the candidate record information, then the active record information is updated as a whole using the candidate record information through the write authentication frame of the RPMB, so that the current inactive region becomes the current active region.

[0031] In one possible implementation, the method further includes:

[0032] During the first operating system reboot after the system update data writing is completed, the new GPT is read from the storage area corresponding to the updated activity record information based on the bootloader, and the operating system is started according to the new GPT;

[0033] If the operating system fails to boot, the updated activity log information will be rolled back to the activity log information before the update, based on the bootloader.

[0034] In one possible implementation, the access to the RPMB after hardware authentication based on the bootloader includes:

[0035] The bootloader sends a read authentication frame to the RPMB; wherein the read authentication frame carries a write counter, a frame number, and verification information.

[0036] If the authentication of the read authentication frame is confirmed to be successful, access to the RPMB is permitted.

[0037] Secondly, embodiments of this application provide an operating system booting device, the device being applied to an embedded device, the embedded device being configured with a storage device, the storage device including a user data area and a replay protection memory block area (RPMB); the RPMB stores a base hash value of a globally unique identifier partition table (GPT) and a backup GPT; including:

[0038] The authentication module is used to access the RPMB after the embedded device is powered on, based on the bootloader and after hardware authentication.

[0039] The calculation module is used to calculate the real-time hash value of the benchmark GPT based on the benchmark GPT stored in the user data area;

[0040] The first startup module is used to start the operating system if it is determined that the real-time hash value is consistent with the base hash value stored in the RPMB, and then locates the sector address of the operating system image according to the base GPT.

[0041] The second startup module is used to update the base GPT stored in the user data area according to the backup GPT stored in the RPMB if it is determined that the real-time hash value is inconsistent with the base hash value, and to locate the sector address of the operating system image according to the updated base GPT and start the operating system.

[0042] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor;

[0043] The memory stores computer-executed instructions;

[0044] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0045] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0046] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0047] The operating system booting method and apparatus provided in this application no longer rely solely on the ordinary user data area for determining the reliability of partition positioning data during the boot process. Instead, the RPMB stores the base hash value and backup GPT, and after power-on, it first accesses this secure area through hardware authentication, and then performs real-time hash verification on the base GPT in the user data area. When the verification matches, the bootloader directly completes image positioning based on the current base GPT; when the verification does not match, the bootloader uses the backup GPT in the RPMB to restore the base GPT in the user data area before performing image positioning and booting. By storing the base hash value and backup GPT in the RPMB hardware secure partition, the determination of the operating system image sector address during the boot phase is always based on a partition table consistent with the trusted reference in the RPMB. Furthermore, by utilizing the hash comparison and automatic recovery mechanism during boot, boot failures caused by GPT corruption, tampering, or abnormal power loss can be effectively avoided, improving the reliability and security of operating system booting while reducing maintenance costs. Attached Figure Description

[0048] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0049] Figure 1 A schematic diagram of the partition structure of a storage device provided in this application;

[0050] Figure 2 Flowchart of the operating system boot method provided in this application Figure 1 ;

[0051] Figure 3 A schematic diagram of the structure of an RPMB is provided for this application;

[0052] Figure 4 Flowchart of the operating system boot method provided in this application Figure 2 ;

[0053] Figure 5 Flowchart of the operating system boot method provided in this application Figure 3 ;

[0054] Figure 6 A schematic diagram illustrating one application scenario provided in this application;

[0055] Figure 7 A schematic diagram illustrating one application scenario provided in this application;

[0056] Figure 8 A schematic diagram illustrating one application scenario provided in this application;

[0057] Figure 9 A schematic diagram illustrating one application scenario provided in this application;

[0058] Figure 10 A schematic diagram of data flow provided in this application;

[0059] Figure 11 A schematic diagram of the structure of the boot device for the operating system provided in this application;

[0060] Figure 12 A schematic diagram of the structure of the electronic device provided in this application.

[0061] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0062] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application.

[0063] The Globally Unique Partition Table (GPT) defines the layout information of all partitions on the storage device. The Primary GPT is stored in the first sector (LBA0 to LBA33) of the User Data Area, while the Secondary GPT, as a backup, is fixed in the last 34 sectors of the User Data Area. When the operating system starts, the bootloader must read the GPT to locate the system partition.

[0064] In related technologies, the bootloader reads and directly parses the baseline GPT from the user data area. However, this user data area is mostly protected by software access control and lacks hardware-level security protection. Physical damage, malicious tampering, or abnormal power outages can all lead to data inconsistencies. In other words, the baseline GPT can become abnormal due to storage medium bit flips, block corruption, or unauthorized modifications, which may result in the inability to correctly locate the boot partition. Although storage devices usually retain backup GPTs, both they and the baseline GPT are located in the user data area and are still susceptible to similar storage failures. The system cannot automatically recover and can only rely on physical flashing, resulting in high maintenance costs.

[0065] To address this issue, the inventors conceived of a Replay Protected Memory Block (RPMB) partition, which possesses hardware-level replay protection and write authentication capabilities, enabling it to resist physical attacks and malicious tampering. Therefore, critical boot data, such as GPT backups and trusted baseline hash values, can be migrated to the RPMB, leveraging its hardware security features to ensure data trustworthiness. During boot, the real-time hash value of the user data area's GPT is calculated and compared with the protected baseline hash value in the RPMB. If they match, the GPT is used directly; otherwise, the backup GPT is read from the RPMB for restoration. This automatically repairs the system in case of GPT corruption, ensuring successful system startup and preventing boot failures due to GPT malfunction.

[0066] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0067] The execution entity in this application embodiment is an embedded device, or a controller of an embedded device. An embedded device refers to an electronic device equipped with a storage device, such as a smart terminal, an IoT device, or an in-vehicle device. In some embodiments, the embedded device may be an Android in-vehicle infotainment system or a similar embedded platform.

[0068] The storage device can be an embedded multimedia card (eMMC), universal flash storage (UFS), or other storage media with partition management capabilities. (Reference) Figure 1 As shown, Figure 1 This application provides a schematic diagram of the partition structure of a storage device, in which the embedded device's storage is divided into a user data area and an RPMB. The controller can be a storage device controller, such as an eMMC controller.

[0069] The user data area is a regular read / write area in a storage device used to store the operating system, applications, and user data. This area typically lacks hardware-level security protection, and the data is at risk of being tampered with, damaged, or becoming inconsistent due to abnormal power outages.

[0070] RPMB is a replay-protected memory block area in storage devices, possessing hardware-level write authentication and replay protection capabilities. Read and write access is only permitted through key-based authentication frames, effectively preventing malicious data tampering and replay attacks. For example, RPMB hardware security partitions feature security features such as Hash-based Message Authentication Code with SHA-256 (HMAC-SHA256) access authentication, monotonically increasing write counters, and One-Time Password (OTP) storage. However, it is currently primarily used for storing application-layer data such as keys for Digital Rights Management (DRM) systems and unique device identifiers.

[0071] GPT is a partition table used to describe the partition layout of a storage device. It contains information such as partition type, starting address, and size, and is used to locate the sector where the operating system image is located.

[0072] The baseline hash value is a digest value obtained by hashing the currently trusted GPT, and is used to verify the integrity of the GPT in the user data area at startup.

[0073] Backup GPT is a copy of GPT stored in RPMB, used for recovery in case of GPT verification failure in the user data area.

[0074] By storing the base hash value of GPT and the backup GPT in the RPMB hardware security partition, and leveraging RPMB's hardware-level authentication and replay protection capabilities, critical boot data can be effectively protected from malicious tampering and physical damage, ensuring the trustworthiness of the GPT verification and recovery process, thereby improving the reliability and security of operating system boot.

[0075] In some embodiments, this application can be applied to an in-vehicle infotainment system running Android Automotive OS, where the storage device is an embedded storage chip conforming to the eMMC 5.1 standard or the UFS 2.0 standard. This scenario places stringent requirements on system startup security, reliability, and robustness. Secure system startup is directly related to driving safety; any startup failure or startup hijacking could lead to serious safety incidents.

[0076] Figure 2 Flowchart of the operating system boot method provided in this application Figure 1 ,like Figure 2 As shown, the method includes:

[0077] S101. After the embedded device is powered on, it accesses the RPMB based on the bootloader and after hardware authentication.

[0078] For example, the bootloader is the first startup program executed after the device is powered on, used to establish the early execution environment, complete storage access initialization, and advance the subsequent startup chain. Hardware authentication refers to authenticating access requests based on the hardware security capabilities provided by the storage device, ensuring that only legitimate requests can access protected areas.

[0079] RPMB is a secure partition within the storage device, equipped with write authentication and replay protection capabilities, capable of resisting malicious tampering and replay attacks. RPMB stores a base hash value and a backup GPT, where the base hash value represents the verification result of the trusted GPT, and the backup GPT provides a recovery source in case of anomalies in the partition table in the user data area.

[0080] In one example, after the embedded device powers on, the processor first executes the bootloader entry code embedded in a fixed location on the boot medium. The bootloader initializes the clock, bus, memory controller, and necessary caches, and establishes basic read and write capabilities to the storage device. After completing the initialization required for its own startup, the bootloader accesses the RPMB through hardware authentication. If authentication is successful, the bootloader reads the stored baseline hash value and backup GPT from the RPMB and loads the read results into a controlled buffer in volatile memory for subsequent verification and recovery processes. If authentication fails, the process does not continue accessing the RPMB and stops entering the boot path that relies on this trusted baseline.

[0081] By placing the RPMB access action in the early startup phase after power-on, and completing hardware authentication first through the bootloader, and then reading the baseline hash value and backup GPT, the key reference data involved in the decision-making process during startup can be derived from the protected area, thus providing a reliable reference basis for subsequent integrity comparison of the baseline GPT in the user data area.

[0082] S102. Calculate the real-time hash value of the base GPT based on the base GPT stored in the user data area.

[0083] For example, the user data area is a general read / write area in the storage device used to store the operating system, applications, and user data. This area typically lacks hardware-level security protection. This user data area stores the baseline GPT directly used by the current boot process. The baseline GPT is a primary globally unique identifier partition table stored in the user data area, used to describe the partition layout of the storage device, including information such as partition type, starting address, and size, to locate the partition where the operating system image is located.

[0084] The Current Hash is the hash result calculated based on the baseline GPT in the user data area during this power-on startup.

[0085] In one example, the bootloader reads the baseline GPT content from the user data area and inputs the data corresponding to the baseline GPT into the hash calculation module to perform a digest operation. The hash algorithm is the same as the one used to generate the baseline hash value in the RPMB to ensure consistent comparison criteria. The final output is a real-time hash value. This real-time hash value directly reflects the current content status of the baseline GPT in the user data area. If the baseline GPT is abnormally overwritten or unauthorizedly modified, the real-time hash value will deviate from the baseline hash value recorded in the trusted state. It should be noted that this application does not limit the type of hash algorithm used; for example, it can be the SHA-256 algorithm.

[0086] This step allows for real-time hash calculation of the baseline GPT that actually participates in the startup positioning within the user data area during the same startup process. This generates a verification result based on the current storage state, providing a direct basis for subsequent judgments on whether to continue using the baseline GPT.

[0087] S103. Determine whether the real-time hash value is consistent with the baseline hash value stored in RPMB.

[0088] For example, the base hash (Trusted Hash) refers to the trusted GPT hash digest that is pre-computed and stored in the RPMB. This value is protected by RPMB hardware authentication and cannot be modified without authorization. It can be used as a reference value to determine whether the base GPT in the user data area has been tampered with or damaged.

[0089] In one example, the bootloader compares the real-time hash value with the baseline hash value read from the RPMB byte by byte. If they are the same, the baseline GPT in the user data area is considered to be complete and reliable, and step S104 is executed; if they are different, the baseline GPT is considered to be damaged or tampered with, and step S105 is executed.

[0090] S104. Locate the sector address of the operating system image based on the baseline GPT and start the operating system.

[0091] For example, the operating system is the software system that is ultimately loaded and run, and the operating system image is an image file that contains the operating system kernel, boot parameters, and file system, and is stored in a specific partition of the user data area.

[0092] The sector address refers to the starting sector position and size of the partition on the storage device recorded in GPT, which is used to determine the storage range of the operating system image.

[0093] In one example, when the bootloader determines that the comparison result is completely consistent, it determines that the baseline GPT currently stored in the user data area corresponds to the trusted reference state in the RPMB. The current baseline GPT can be used as the valid partition location basis for this boot. Subsequently, the bootloader parses the target partition entry in the baseline GPT to determine the sector address range of the operating system image. After the location is completed, the bootloader reads the operating system image from the storage device to the predetermined loading area according to the sector address, and after verifying the kernel digital signature, transfers control and completes the operating system boot. In this process, the baseline GPT not only serves as an image location index but also constitutes a key decision object in the boot chain; since its content has passed the consistency verification with the baseline hash value in the RPMB, the image location read subsequently remains consistent with the trusted partition description.

[0094] This step allows the current baseline GPT to be used directly to locate the operating system image sector address when the real-time hash value matches the baseline hash value. The boot process can continue without additional repair operations, and the boot basis is consistent with the trusted reference, which can mitigate the risk of incorrect partition addressing caused by local anomalies in the user data area.

[0095] S105. Update the baseline GPT in the user data area storage according to the backup GPT stored in RPMB, and locate the sector address of the operating system image according to the updated baseline GPT, and start the operating system.

[0096] For example, if the real-time hash value is inconsistent with the baseline hash value, it means that the baseline GPT in the user data area does not match the trusted baseline state stored in RPMB. The reasons may be storage bit flipping, block corruption, the partition table remaining in a half-update state during the upgrade process, or unauthorized modification. This application embodiment does not limit the scope of the problem.

[0097] The backup GPT is a trusted copy of the partition table that has been stored in the RPMB beforehand, and can be used as the source data for restoring the user data area baseline GPT.

[0098] In one example, after identifying an inconsistency, the bootloader stops using the baseline GPT in the current user data area for image positioning. Instead, it retrieves the backup GPT from the RPMB data buffer, which has already been authenticated, and writes it back to the storage location corresponding to the baseline GPT in the user data area, thus updating the baseline GPT. After the update, the bootloader recalculates the real-time hash value of the updated baseline GPT and verifies its consistency with the baseline hash value in the RPMB. Once verified, the bootloader uses the updated baseline GPT as the new partition positioning basis, parses the target partition entry corresponding to the operating system image, determines the sector address of the operating system image, and starts the operating system according to the predetermined boot process.

[0099] This step allows the system to update the operating system image and boot from the updated GPT when the baseline GPT in the user data area becomes abnormal. This enables the boot decision to be re-anchored to the trusted partition information in the protected area, thus ensuring that the device can still boot from a consistent partition table baseline after abnormal power outages, storage damage, or tampering.

[0100] The operating system boot method provided in this application no longer relies solely on the ordinary user data area for determining the reliability of partition positioning based on key data in the boot chain. Instead, the RPMB stores the base hash value and backup GPT, and after power-on, it first accesses this secure area through hardware authentication, and then performs real-time hash verification on the base GPT in the user data area. When the verification matches, the bootloader directly completes image positioning based on the current base GPT; when the verification does not match, the bootloader uses the backup GPT in the RPMB to restore the base GPT in the user data area before performing image positioning and booting. By storing the base hash value and backup GPT in the RPMB hardware secure partition, the determination of the operating system image sector address during the boot phase is always based on a partition table consistent with the trusted reference in the RPMB. Furthermore, by utilizing hash comparison and automatic recovery mechanisms during boot, boot failures caused by GPT corruption, tampering, or abnormal power loss can be effectively avoided, improving the reliability and security of operating system booting while reducing maintenance costs.

[0101] Figure 3 A schematic diagram of the structure of an RPMB is provided for this application, as follows: Figure 3 As shown, the RPMB includes a metadata area, a first storage area, and a second storage area.

[0102] The metadata area is the region in the RPMB used to store critical management information for startup, recording trusted state information required during the startup process. The metadata area stores activity log information, candidate log information, slot status of the operating system image slots, and active slot identifiers.

[0103] Activity log information refers to currently active trusted records used to determine the currently trusted active storage area and its corresponding trusted baseline value. Activity log information includes the baseline hash value, active area flag, and valid version number. The baseline hash value is a hash digest calculated from the current trusted GPT; the active area flag points to the currently active storage area in either the first or second storage area; and the valid version number indicates the generation number of the currently active data.

[0104] Candidate record information refers to candidate trusted records that have been written during the update process but have not yet taken effect. These records are used to determine whether to continue the switchover or rollback should the update be completed in the event of an interruption or an anomaly. Candidate record information includes a candidate active region identifier, a candidate GPT hash value, a candidate record data commit status identifier, and a candidate version number. The candidate active region identifier points to the inactive storage region selected during the update; the candidate GPT hash value is the new GPT hash value in the updated data; the candidate record data commit status identifier indicates whether the candidate record is valid; and the candidate version number represents the generation number of the candidate data.

[0105] An operating system image slot refers to a boot slot used to store the operating system image. Multiple slots can exist in a system, each corresponding to one operating system image. Slot status indicates whether the corresponding slot is currently bootable, confirmed, or rolled back. The active slot identifier indicates the currently preferred boot slot.

[0106] The first and second storage areas are two independent storage areas in the RPMB used to store backup GPT and its associated data version information. They can store backup data from different generations to support updates and rollbacks.

[0107] The first storage area stores the first backup data, the data commit status identifier of the first storage area, and the data version number of the first storage area. The first backup data is the backup data stored in the first storage area, including the backup GPT, slot information, and configuration information, which are key startup data. The data commit status identifier of the first storage area is used to indicate whether the data in the first storage area has been completely written and passed the verification. The data version number of the first storage area indicates the generation number of the data in the first storage area.

[0108] The second storage area stores the second backup data, the data commit status identifier for the second storage area, and the data version number for the second storage area. These components serve the same purpose as their counterparts in the first storage area, and are used to save data from another generation during the dual-area update process.

[0109] It is understandable that the metadata area, the first storage area, and the second storage area are all set within the protected logical address range of the RPMB. The three are accessed separately through a preset address mapping relationship, and all accesses must go through the RPMB's authentication mechanism.

[0110] By adopting this structure, the active record information, candidate record information, backup GPT and its data commit status and version number are stored in a structured manner through the metadata area, first storage area and second storage area within the RPMB. This allows the system to determine the currently valid storage area based on the active record and candidate record in the metadata area at startup, and obtain a reliable backup GPT for startup or recovery. At the same time, during the update process, new data can be written to the inactive storage area to form candidate records, and then the area switch is completed through atomic switching of the active record. This ensures the consistency and reliability of the startup critical data during the update, power failure and abnormal recovery processes, thereby improving the reliability and maintainability of the system.

[0111] Figure 4 Flowchart of the operating system boot method provided in this application Figure 2 ,like Figure 4 As shown, in this embodiment... Figure 2 Based on the embodiments, the operating system startup method is described in detail, which includes:

[0112] S201. After the embedded device is powered on, a read authentication frame is sent to the RPMB based on the bootloader.

[0113] For example, a read authentication frame is an authentication data frame carried by the bootloader when initiating a read request to the RPMB, used to prove the legitimacy of this read operation to the RPMB. This read authentication frame carries a write counter, a frame number, and verification information. The write counter is a monotonically increasing count value maintained internally by the RPMB to prevent old data from being replayed. The frame number identifies the sequence number of this authentication frame. The verification information can be an HMAC-SHA256 digest calculated based on the key, used to verify the integrity and authenticity of the authentication frame.

[0114] In one example, when the bootloader needs to access the RPMB, it first assembles a read authentication frame according to the RPMB protocol, writing the currently stored write counter, the frame number corresponding to the data to be accessed, and the verification information calculated based on the key into the frame body. Then, it sends the read authentication frame to the RPMB through the storage control interface. Upon receiving the authentication read request, the RPMB matches the internally stored count status, frame number, and verification result. When all three meet the preset authentication conditions, the RPMB controller returns a read-allow response and opens access to the corresponding protected area. If authentication fails, the RPMB rejects the access request and does not return the target data to the bootloader.

[0115] In one possible implementation, the write counter is generated or synchronously obtained from a monotonically increasing count value maintained by the RPMB side. The frame number corresponds to the sequence number of the data block in the current read request. The verification information can be generated in the form of a message authentication code to ensure that the read authentication frame matches the authentication key, count status, and request sequence number stored internally by the RPMB. In practical applications, the read authentication frame can also use other combinations of authentication fields conforming to the RPMB protocol, which is not limited in this application.

[0116] This approach binds read requests to hardware authentication during the boot phase, ensuring that the bootloader can only access the RPMB after the read authentication frame has passed authentication. This controls the reading of protected data to the device-side hardware authentication status. Since the write counter, frame number, and verification information jointly participate in the authentication decision, the authentication request can remain consistent with the internal state of the RPMB, thereby making trusted data access in the boot chain deterministic and controlled.

[0117] With the above approach, access to the RPMB during the boot phase no longer depends on the software verification results of the ordinary storage area, but is directly controlled by hardware authentication. This can improve the reliability of reading protected data and make the bootloader more consistent when accessing critical boot data.

[0118] S202. If it is determined that the authentication of the read authentication frame is successful, then access to the RPMB is allowed.

[0119] For example, successful authentication means that the RPMB verifies the verification information in the read authentication frame using the internally stored key, confirming that the authentication frame has not been tampered with and that the write counter is valid. Granting access to the RPMB means that the bootloader obtains permission to read protected data within the RPMB.

[0120] In one example, after receiving a read authentication frame, the RPMB verifies whether the HMAC-SHA256 digest is correct, whether the write counter matches the internal record of the RPMB, and whether the frame number is valid. If the verification passes, the bootloader is allowed to read the data in the metadata area and various storage areas of the RPMB. If the verification fails, access is denied and the security recovery process is initiated.

[0121] S203. Calculate the real-time hash value of the base GPT based on the base GPT stored in the user data area.

[0122] It should be noted that this step is similar to the aforementioned step S102, and will not be repeated here.

[0123] S204. Determine whether the real-time hash value is consistent with the baseline hash value stored in RPMB.

[0124] It should be noted that this step is similar to the aforementioned step S103, and will not be repeated here. If they are the same, proceed to step S205; if they are not the same, proceed to step S206.

[0125] S205. Locate the sector address of the operating system image based on the baseline GPT and start the operating system.

[0126] It should be noted that this step is similar to the aforementioned step S104, and will not be repeated here.

[0127] S206. Based on the activity record information and candidate record information, determine the current active region from the first storage region and the second storage region.

[0128] For example, activity record information refers to currently active trusted records used to determine the currently trusted active storage region and corresponding trusted baseline value of the system, including the baseline hash value, active region identifier, and valid version number. Candidate record information refers to candidate trusted records that have been written during the update process but have not yet taken effect, used to determine whether to continue the switch or rollback when the update is interrupted or an anomaly occurs, including the candidate active region identifier, the hash value of the candidate GPT, the data commit status identifier of the candidate record, and the candidate version number.

[0129] The first and second storage areas are two independent storage areas in the RPMB used to store version information of the backup GPT and its associated data. The currently active area refers to the storage area in the first and second storage areas that is currently trusted by the system and used to provide backup GPT data.

[0130] In one example, when the real-time hash value differs from the base hash value, the bootloader reads the active record information and candidate record information from the metadata area. Based on these information, it determines which of the first and second storage areas is currently active. If the candidate record information indicates that the candidate storage area has been committed and its version number is valid, then the candidate storage area is identified as the currently active area. If the candidate area has not been committed, the storage area pointed to by the active record information remains the currently active area.

[0131] Specifically, if it is determined that the submission status identifier of the candidate record information data is invalid, then the storage area corresponding to the active area identifier will be used as the current active area.

[0132] If the data submission status identifier of the candidate record information is determined to be valid, then check whether the candidate version number is equal to the valid version number plus one, whether the data submission status identifier of the storage area corresponding to the candidate active area identifier is valid, and whether the hash value of the GPT stored in the storage area corresponding to the candidate active area identifier is consistent with the hash value of the candidate GPT. If all the verification results are yes, then the storage area corresponding to the candidate active area identifier is taken as the current active area. If the verification results are no, then the storage area corresponding to the active area identifier is taken as the current active area.

[0133] The data commit status identifier for a storage region indicates whether the data in the corresponding storage region has been completely written and passed verification. When this identifier is valid, it means the data is complete and available. The currently active region refers to the storage region in the first and second storage regions that has been ultimately identified as a trusted source and used to provide backup GPT.

[0134] For example, the bootloader first reads the candidate record information in the metadata area and determines whether the data commit status identifier of the candidate record information is valid. If the data commit status identifier of the candidate record information is invalid, it means that the candidate data has not been completely written or the candidate record has not been formed. In this case, the storage area corresponding to the active area identifier is directly determined as the current active area. If the data commit status identifier of the candidate record information is valid, the following three checks are further performed: the first check is whether the candidate version number is equal to the valid version number plus one; the second check is whether the data commit status identifier of the storage area corresponding to the candidate active area identifier is valid; the third check is whether the hash value of the GPT actually stored in the storage area corresponding to the candidate active area identifier is consistent with the hash value of the candidate GPT. If all three checks are yes, it means that the candidate data is complete and consistent with the candidate record. In this case, the storage area corresponding to the candidate active area identifier is determined as the current active area. If any check is no, it means that the candidate data is unreliable. In this case, the storage area corresponding to the active area identifier is still determined as the current active area. For example, if the data submission status identifier of the currently inactive region is valid, but the data submission status identifier of the candidate record information is invalid, it is determined that the system has completed the data update and writing but the candidate record has not been constructed. The storage region corresponding to the active region identifier will continue to be used as the current active region.

[0135] Optionally, if the data submission status indicator of the candidate record information is valid, but the activity record information still points to the original activity area, it is determined that the candidate version data is complete but has not been submitted. The bootloader verifies that the candidate version number is equal to the valid version number plus one and that the hash value of the candidate GPT matches the GPT hash in the current non-active area. If the verification passes, the activity record information is completed and updated. If the verification fails, the candidate activity area is discarded.

[0136] Optionally, if the activity log information has been switched but the new slot operating system fails to boot, then the slot status change is performed and the activity log information of the stable version before the update is restored.

[0137] By employing the above method, when the data submission status identifier of the candidate record information is valid, multiple verifications are further performed on the incremental relationship of the candidate version number, the data submission status of the candidate storage area, and the GPT hash value actually stored in the candidate area. Only after all verifications pass is the candidate storage area determined as the current active area; otherwise, the storage area corresponding to the active area identifier continues to be used. This avoids directly trusting a candidate area based solely on a larger candidate version number, preventing startup failures due to incomplete candidate data or inconsistencies with candidate records. It improves the accuracy and reliability of determining the current active area during startup, ensuring that the system can still obtain backup GPTs from trusted areas and complete startup even in cases of update interruption, data anomalies, or malicious tampering.

[0138] S207. Obtain a backup GPT from the currently active region.

[0139] For example, the backup GPT is a copy of the GPT stored in the RPMB, used for recovery in the event of a failure to verify the baseline GPT in the user data area. The backup GPT is stored in a first storage area and a second storage area, with each area capable of holding GPT copies from different generations.

[0140] In one example, the bootloader reads the corresponding backup GPT data from the determined current active region.

[0141] S208. Perform integrity verification on the backup GPT, and update the base GPT stored in the user data area based on the backup GPT after the verification passes.

[0142] For example, integrity verification refers to verifying the data structure and content of the backup GPT, including Cyclic Redundancy Check (CRC), GPT header structure validity verification, and partition table entry consistency verification, to confirm that the backup GPT has not been damaged or tampered with. Updating the base GPT stored in the user data area means writing the verified backup GPT data to the location of the base GPT in the user data area, overwriting the damaged or tampered GPT content.

[0143] In one example, the bootloader performs a CRC32 check on the read backup GPT and verifies the validity of the structure, such as the GPT signature, the number of partition entries, and the start and end addresses of the partitions. After the verification is successful, the backup GPT is written to the base GPT sector location in the user data area. After the writing is completed, the real-time hash value of the updated base GPT is recalculated and its consistency is confirmed with the base hash value in the RPMB. Only after the confirmation is successful will the boot process begin.

[0144] By employing the above method, when the baseline GPT in the user data area becomes unavailable, the trusted backup GPT in the RPMB can be invoked to complete the recovery and write-back, ensuring that the partition tables on which boot depends remain valid and consistent. Since the determination of the current active region depends on active record information and candidate record information, the backup GPT read during recovery matches the state records within the RPMB, thus improving the reliability and consistency of the baseline GPT update and enhancing the stability of partition table recovery in the boot process.

[0145] S209. Locate the sector address of the operating system image based on the updated baseline GPT and start the operating system.

[0146] In one example, the bootloader parses the updated baseline GPT, obtains the starting address and length of the sector of the partition where the operating system image is located, loads the operating system image based on the address, and after verifying the kernel digital signature, transfers control and completes the operating system boot.

[0147] The operating system startup method provided in this application embodiment involves the bootloader performing hardware authentication by sending a read authentication frame after the embedded device is powered on. Upon successful authentication, the bootloader accesses the RPMB, calculates the real-time hash value of the base GPT in the user data area, and compares it with the base hash value stored in the RPMB. If they match, the operating system is started directly based on the GPT. If they do not match, the current active region is determined from the first and second storage areas based on activity record information and candidate record information. A backup GPT is obtained from the current active region and its integrity is verified. After successful verification, the base GPT in the user data area is restored. Then, the sector address of the operating system image is located based on the restored GPT, and the operating system is started. By storing the base hash value and backup GPT in the RPMB hardware security partition, and using activity record information and candidate record information to determine the current active region to obtain a trusted backup GPT, and performing hash verification and automatic recovery of the GPT during startup, startup failures caused by GPT corruption, tampering, or abnormal power loss can be effectively avoided. Simultaneously, consistency judgment and abnormal recovery during the update process are supported, improving the reliability and security of the operating system startup and reducing maintenance costs.

[0148] Understandably, the operating system boot process also requires selecting the boot slot for the operating system image. In related technologies, the Android A / B system update mechanism achieves seamless updates by maintaining two sets of system images, Slot A and Slot B. The bootloader typically reads boot slot status flags (such as active, bootable, successful) maintained by the miscellaneous (misc) partition or the Boot Control Hardware Abstraction Layer (bootctrl HAL) to determine which slot to boot from. However, these boot slot states are usually stored in the ordinary user data area and maintained by software, lacking hardware-level trusted protection and posing a risk of unauthorized tampering or rollback.

[0149] To address the aforementioned issues, this application embodiment stores the slot status and active slot identifier in the metadata area of ​​the RPMB. Utilizing the hardware-level write authentication and anti-replay capabilities of the RPMB, and constraining state evolution through authenticated writes and monotonic write counters, the integrity, authenticity, and non-rollbackability of the slot status and active slot identifier are ensured, thereby preventing unauthorized tampering and state rollback.

[0150] In some embodiments, a target boot slot is determined based on the slot status and active slot identifier of the operating system image slot; the sector address of the target boot slot in the user data area is determined based on the target GPT, so as to load the operating system image stored in the target boot slot and start the operating system; wherein, the target GPT is a base GPT or an updated base GPT.

[0151] For example, an operating system image slot refers to a boot slot used to store the operating system image. A storage device can have multiple slots, each corresponding to an independently stored operating system image. Slot status indicates whether the slot is currently bootable, confirmed, or rolled back. Slot status can include a confirmed status (CONFIRMED), a booting status (BOOTING), and a rollback status (ROLLBACK).

[0152] The active slot identifier indicates the currently preferred startup slot, which is the default startup slot after a normal startup or update. The target startup slot refers to the slot that is ultimately determined to be used for this startup after status assessment.

[0153] A target GPT is a trusted, globally unique identifier partition table obtained after hash verification or recovery. It describes the partition layout of the storage device, including information such as the type, starting address, and size of each partition. The target GPT can be a verified and trusted baseline GPT in the user data area, or an updated baseline GPT obtained from an RPMB backup after a baseline GPT verification failure.

[0154] The sector address refers to the starting sector position and sector length of the partition corresponding to the target boot slot in the user data area, as recorded in the target GPT. It is used to determine the specific storage range of the operating system image on the storage device. An operating system image is an image file containing the operating system kernel, boot parameters, and file system, among other things.

[0155] In one example, the bootloader reads the active slot identifier and the slot status of each slot stored in the metadata area. It then combines the slot status to determine whether the current slot has been written, whether startup is allowed, and whether rollback is needed. Simultaneously, it determines the slot that should be prioritized based on the active slot identifier. When the slot status pointed to by the active slot identifier meets the startup conditions, that slot is designated as the target startup slot; otherwise, it switches to another slot whose status meets the requirements as the target startup slot.

[0156] After determining the target boot slot, the bootloader calculates the sector address of that slot in the user data area based on the starting sector and offset of the partition given by the target GPT, and reads the corresponding operating system image accordingly. The read image is verified and loaded into memory, after which the bootloader jumps to the image entry point to complete the operating system boot. If the base GPT in the user data area has been updated based on the backup GPT in the RPMB, the target GPT directly adopts the updated base GPT to ensure that the slot location relationship is consistent with the currently valid partition information.

[0157] This method ensures that slot selection and sector positioning are based on slot status, active slot identifier, and target GPT. The data source used for image positioning in the boot chain is consistent, and the target boot slot can be stably resolved to the specific sector address in the user data area, thereby completing image loading and system boot.

[0158] With this implementation method, the operating system startup no longer relies on a single and potentially distorted partition information. Instead, it combines the slot status and active slot identifier to determine the startup target and uses the baseline GPT or an updated baseline GPT to complete address resolution, thereby maintaining the deterministic startup location result and improving startup consistency and image loading reliability.

[0159] Specifically, if the slot status of the slot corresponding to the active slot identifier is confirmed, then the slot corresponding to the active slot identifier will be determined as the target startup slot.

[0160] If the slot corresponding to the active slot identifier is determined to be in the startup state, and all slots are in the startup state, then the slot corresponding to the active slot identifier is determined as the target startup slot.

[0161] If the slot corresponding to the active slot identifier is determined to be in a rollback state, and the slot of another slot is in a non-rollback state, then the other slot is determined as the target startup slot.

[0162] The slot status indicates the current startup state of the corresponding slot, which can include a confirmed state (CONFIRMED), a startup state (BOOTING), and a rollback state (ROLLBACK). A confirmed state indicates that the operating system image in this slot has successfully started and passed verification, and can be used as a stable version. A startup state indicates that the operating system image in this slot is attempting to start or has been updated but has not yet passed startup verification. A rollback state indicates that the operating system image in this slot has failed to start or has been marked as unavailable. The active slot identifier indicates the system's currently preferred startup slot, which is the default slot pointed to during the normal startup process. The target startup slot refers to the slot ultimately determined for this startup after judging based on the slot status and the active slot identifier. The other slot refers to any available slot other than the one indicated by the active slot identifier.

[0163] For example, the bootloader reads the active slot identifier and the slot status of each slot stored in the metadata area, and determines the target startup slot according to the following judgment logic: if the slot status corresponding to the active slot identifier is confirmed, then the slot is determined as the target startup slot; if the slot status corresponding to the active slot identifier is in the startup state, and the slot status of all slots is in the startup state, then the slot corresponding to the active slot identifier is still determined as the target startup slot; if the slot status corresponding to the active slot identifier is in the rollback state, and the slot status of another slot is in the non-rollback state, then the other slot is determined as the target startup slot.

[0164] In this way, the slot status can be synchronously updated by the upgrade writing module during image submission, startup verification, and rollback switching, while the active slot identifier is bound to the currently effective version and written to the metadata area. This implementation makes the startup determination directly dependent on the status records in trusted storage. During the startup process, it can stably select a confirmed slot, maintain the current active slot when all slots are still in the startup state, or switch to a non-rollback standby slot when the active slot is rolled back. As a result, it can output a clear target startup slot in the event of power failure recovery, upgrade interruption, or single slot failure, and maintain the consistency and continuity of the image loading objects, improving the success rate of operating system startup and the system's self-recovery capability.

[0165] In related technologies, the inventors also discovered that the lack of a consistent commit mechanism for critical data updates during startup means that abnormal power outages may result in data being in a partially updated state. Specifically, when updating the operating system using Over-The-Air (OTA) technology, multiple fields are involved, including GPT, slot selection information, and startup configuration. If these fields are written multiple times, a power outage may cause inconsistencies between the data. Through research and analysis, the inventors found that existing solutions lack a unified commit determination mechanism based on version numbers and commit markers, making it difficult to automatically restore a consistent state upon the next startup.

[0166] To address the aforementioned issues, this application introduces a mechanism for separating candidate record information from active record information, and employs an atomic update protocol based on the Generation version number and the Commit flag. The RPMB is divided into two storage areas, Area A and Area B, each storing a complete copy of the startup critical data, the version number, and the Data Commit status identifier. During an update, new data is first written to the inactive area and integrity verification is performed, followed by writing the Data Commit status identifier; subsequently, candidate record information (Candidate Metadata record) is formed, containing the candidate active area, candidate version number, and candidate GPT hash. Only when the candidate data is complete and consistent is the active record information (Active Record) updated once, protected by RPMB authentication. The active area flag, active generation, and GPT Trusted Hash in the active record information are switched as the same effective record, thereby avoiding inconsistencies caused by step-by-step updates of each field.

[0167] In some embodiments, Figure 5 Flowchart of the operating system boot method provided in this application Figure 3 ,like Figure 5 As shown, in this embodiment... Figure 2Based on the embodiments, the operating system startup method is described in detail, which includes:

[0168] S301, Obtain system update data.

[0169] For example, system update data refers to the new version of critical startup data that needs to be written to the inactive storage area during the system update process, used to replace or update the currently effective data. System update data includes a new GPT, a new hash value for the new GPT, new configuration parameter information, a new version number, and new slot information. The new GPT refers to the new globally unique identifier partition table used to describe the partition layout of the storage device after the update, containing the latest location information of partitions such as the operating system image. The new hash value is the digest value obtained by hashing the new GPT, used for subsequent verification of the integrity of the new GPT. The new configuration parameter information refers to the startup configuration parameters associated with the new GPT, such as startup parameters and verification policies. The new version number is the new generation number assigned in this update, usually one more than the current valid version number, used to identify the relationship between the old and new data. The new slot information refers to the slot information corresponding to the updated operating system image, used to indicate the slot that should be prioritized for startup after the update.

[0170] In one example, the Android UpdateEngine generates a new GPT, new configuration parameters, and new slot information in a Trusted Execution Environment (TEE), assigns a new version number, calculates a new hash value for the new GPT, and combines this data into system update data.

[0171] S302. Write system update data to the currently inactive area via the write authentication frame of RPMB.

[0172] For example, a write authentication frame refers to the authentication data frame carried when the RPMB initiates a write request. It includes a write counter, frame number, and verification information, etc., to prove the legitimacy of the write operation and prevent unauthorized writes and replay attacks. The currently inactive area refers to the storage area in the first and second storage areas that is not pointed to by the active area identifier. It is used to receive updated data and does not affect the normal use of the currently active area until the update is completed.

[0173] In one example, the bootloader or update service sends a write authentication frame to the RPMB through the RPMB authentication interface, writing the new GPT, new configuration parameter information, and new slot information from the system update data into the currently inactive area. After the RPMB verifies the write authentication frame, it performs the write operation.

[0174] S303. After the write operation is completed, set the data commit status flag of the currently inactive region to valid and update the data version number of the currently inactive region to the new version number.

[0175] For example, the data commit status identifier of the currently inactive region refers to the data commit status identifier of the inactive storage region, which is used to indicate whether the data in the corresponding storage region has been completely written and passed verification. When this identifier is set to valid, it means that the data in the storage region is complete and available. The data version number of the currently inactive region refers to the data version number of the inactive storage region, which is a field used to identify the generation number of the data in the corresponding storage region, and is used to determine the age of the data during startup or recovery.

[0176] In one example, once the system has written all the updated data to the currently inactive region and passed the integrity check, the data commit status flag of the currently inactive region is set to a valid value. At the same time, the data version number of the region is updated to the new version number written this time, indicating that the region has saved complete new generation data.

[0177] S304. Generate candidate record information based on the current inactive region, the new version number, and the new hash value, and write the candidate record information to the metadata area.

[0178] In one example, the candidate record information includes the candidate active region identifier, the hash value of the candidate GPT, the data commit status identifier of the candidate record information, and the candidate version number. Therefore, after the data is written, the candidate record information is generated based on the identifier of the current inactive region, the new version number, and the new hash value. The candidate active region identifier is the identifier of the current inactive region, the hash value of the candidate GPT is the new hash value, and the candidate version number is the new version number. The candidate record information is then written to the metadata area of ​​the RPMB. The candidate commit status identifier in the candidate record information is set to valid, indicating that the candidate record has been formed, but at this time the active region identifier still points to the original active region.

[0179] S305. If it is confirmed that the data stored in the current inactive region is consistent with the candidate record information, the active record information is updated as a whole using the candidate record information through the write authentication frame of RPMB, so that the current inactive region becomes the current active region.

[0180] For example, a complete update refers to updating the active region identifier, valid version number, and base hash value in the activity record information as a whole within a single write operation protected by RPMB authentication, thus avoiding inconsistencies caused by step-by-step updates. The current active region refers to the storage region pointed to by the active region identifier and currently in effect within the first and second storage regions.

[0181] In one example, after the candidate record is written, the bootloader or update service reads the data actually stored in the currently inactive region and compares it with the candidate active region identifier, candidate version number, and candidate hash value in the candidate record information. After confirming consistency, it updates the active region identifier in the active record information to the current inactive region, updates the valid version number to the new version number, and updates the base hash value to the new hash value through a write authentication frame protected by RPMB authentication. All three are written as a whole as a single active record, thereby completing the switch of the active region, and the currently inactive region becomes the new active region.

[0182] In some embodiments, during the first operating system reboot after the system update data has been written, the new GPT is read from the storage area corresponding to the updated activity log information based on the bootloader, and the operating system is started based on the new GPT; if the operating system fails to start, the updated activity log information is rolled back to the activity log information before the update based on the bootloader.

[0183] For example, the first operating system reboot refers to the first power-on or restart of the system after the update is completed, used to load the updated operating system. The updated activity record information refers to the new activity record after the commit has taken effect, including the updated activity region identifier, the updated effective version number, and the updated base hash value. The storage region corresponding to the updated activity record information refers to the first or second storage region pointed to by the updated activity region identifier, which stores the new GPT written during the update. The new GPT refers to the new globally unique identifier partition table generated and written during the update process, used to describe the updated partition layout and operating system image location.

[0184] Operating system startup failure refers to situations such as timeouts, kernel crashes, or continuous anomalies in critical services during the startup process, preventing the new version of the operating system from functioning correctly. Rollback refers to restoring the currently effective activity log information to its pre-update values, allowing the system to regain trust in the previous stable version. The pre-update activity log information refers to the old activity log before the update took effect, including the pre-update activity region identifier, the pre-update valid version number, and the pre-update base hash value. The pre-update activity region identifier points to the original activity storage region before the update.

[0185] In one example, because the update process only updates the activity log information in the RPMB and the new GPT in the corresponding storage area, without directly modifying the baseline GPT stored in the user data area, the bootloader's calculation of the real-time hash value of the baseline GPT in the user data area during the first reboot will be inconsistent with the updated baseline hash value. Based on this inconsistency, the bootloader enters the recovery process, reads the activity log information in the metadata area, determines the storage area corresponding to the updated activity area identifier, and reads the new GPT from that storage area. Then, it verifies whether the data commit status identifier of that storage area is valid, whether the data version number is consistent with the updated valid version number, and whether the hash value of the new GPT is consistent with the updated baseline hash value. After successful verification, the new GPT is written to the sector location of the baseline GPT in the user data area. After writing, the real-time hash value of the updated baseline GPT is recalculated and its consistency with the updated baseline hash value in the RPMB is confirmed. After confirmation, the sector address of the partition where the operating system image is located is located based on the updated baseline GPT, and the operating system is loaded and started. If the operating system successfully boots and runs stably, the corresponding slot status can be updated to a confirmed status through the trusted execution environment.

[0186] After the operating system fails to boot, the bootloader restores the active region identifier in the metadata area to the original active region identifier, the valid version number to the original valid version number, and the base hash value to the original base hash value, thus rolling back the entire active record information to the state before the update. Then, it reads the old GPT from the storage area corresponding to the original active region identifier, performs integrity verification on the old GPT, restores the base GPT in the user data area, and then locates the sector address of the operating system image based on the restored old GPT, loads and boots the old version of the operating system, so as to restore to the previous stable version.

[0187] Understandably, in related technologies, the update process typically includes: writing the new system image to an inactive slot, updating the bootctrl state, rebooting the device, attempting to boot into the new slot, and marking it as successful upon successful boot. This mechanism achieves dual-system switching at the logical level, but the bootctrl state itself is stored in a software-controlled area, lacking hardware-level protection, and is at risk of being tampered with or rolled back without authorization.

[0188] In this embodiment, during the first reboot after system update data writing, the bootloader detects a discrepancy between the real-time hash value of the user data area's baseline GPT and the updated baseline hash value. Based on this, it reads the new GPT from the storage area corresponding to the updated activity log information, performs integrity verification on the new GPT, updates the baseline GPT in the user data area, and starts the operating system. If startup fails, the updated activity log information is rolled back to the activity log information before the update, and the old GPT is read from the original activity storage area to resume startup. By delaying the update of the user data area GPT to the trusted recovery process after reboot and utilizing the activity log information in the RPMB to support failure rollback, it avoids GPT corruption caused by abnormal power outages or interruptions during the update process. Furthermore, it automatically restores to the stable version before the update in case of startup failure, improving the reliability, security, and recoverability of system updates.

[0189] Figure 6 A schematic diagram illustrating an application scenario provided in this application, such as... Figure 6 As shown, in some embodiments, taking an in-vehicle IVI system equipped with Android Automotive OS as an example, the storage device is a 64GB chip compliant with the eMMC 5.1 standard, and the RPMB partition capacity is 4MB. The RPMB partition is logically divided into: Area A (sectors 0-2559, 1.25MB), Area B (sectors 2560-5119, 1.25MB), and Metadata area (sectors 5120-6143, 512KB).

[0190] The operating system boot process includes the following steps:

[0191] S1: After the system powers on, the bootloader initializes the eMMC controller and reads metadata from the metadata area via the TEE / RPMB authentication mechanism. The RPMB read result needs to be verified by HMAC-SHA256 digest and write counter; if the first read fails, a limited number of rereads are performed; if authentication fails continuously, the data in storage area B is not directly trusted, and the system enters the safe / emergency recovery mode.

[0192] S2: After successful RPMB authentication, the bootloader performs a cyclic redundancy check (CRC32) on the metadata area to verify whether the read metadata is complete and whether there are any transmission or storage errors. After the CRC32 check passes, the bootloader then verifies the magic number, record version, and field integrity to confirm that the metadata structure is legal, the version matches, and the field format is correct.

[0193] S3: Parse the Active Area Flag and Active Generation to determine the currently active storage areas and their data version generations, and use this as the basis for subsequent GPT verification, candidate area judgment and anomaly recovery.

[0194] S4: Read the primary GPT from logical block addresses 0 to 33 (LBA 0-33) of the User Data Area, calculate the current hash (using the SHA-256 algorithm), and read the GPT Trusted Hash from the metadata area. Compare the current hash with the primary hash. If they match, proceed to S6; otherwise, execute S5.

[0195] S5: Read the backup GPT from the current active area, perform cyclic redundancy check (CRC32) and GPT structure validity check; if the check passes, restore the backup GPT to the primary GPT position in the user data area, and recalculate the real-time hash value of the restored primary GPT and confirm its consistency with the primary hash value; if the backup GPT check fails, enter the safe / emergency recovery mode.

[0196] S6: Read the active slot identifier and the slot A / BState of slots A and B, and perform a state machine validity check. The active slot identifier is the current boot selection pointer. The slot State uses three key states: BOOTING, CONFIRMED, and ROLLBACK. If the target slot corresponding to the active slot identifier is in the CONFIRMED state, it can be used as the stable version for booting, i.e., it is determined as the target boot slot; if the target slot is in the BOOTING state, the boot attempt will continue to be attempted for that slot or rollback to another slot will be determined based on the number of boot attempts, timeouts, or failure records; if the target slot is in the ROLLBACK state, the system will switch to another slot; if neither slot can be booted, the system will enter the safe / emergency recovery mode.

[0197] S7: After confirming that the operating system image of the target boot slot meets the boot conditions, atomically update the slot status of the target boot slot to the booting state and record the boot attempt event.

[0198] S8: Based on the verified GPT, locate the boot partition corresponding to the target boot slot, the Android Verified Boot Meta Data (vbmeta) partition, and the system image; verify the digital signature and the integrity of the Android Verified Boot (AVB); transfer control after successful verification.

[0199] S9: After the kernel starts up and runs stably (e.g., critical services are normal within 60 seconds of startup), it submits a status update request to RPMB through the trusted execution environment, atomically updating the slot status of the target startup slot from the startup state (BOOTING) to the confirmed state (CONFIRMED); if startup fails, it updates the slot status of the target startup slot from the startup state (BOOTING) to the rollback state (ROLLBACK), and switches the active slot identifier (Active Slot) to another available slot.

[0200] Through the above method, a GPT-RPMB trusted digest and backup and recovery mechanism that is independent of the ordinary user data area is established. The SHA-256 trusted digest of the GPT partition table is stored in the RPMB metadata area. At startup, the real-time hash value of the base GPT in the user data area is calculated and compared with the base hash value by reading it through RPMB authentication. If there is a discrepancy, the backup GPT is read from the trusted active storage area and CRC32 verification is performed. After the verification is successful, the base GPT is restored.

[0201] Figure 7 A schematic diagram illustrating an application scenario provided in this application, such as... Figure 7 As shown, in some embodiments, the OTA update scenario for the operating system includes the following steps:

[0202] Phase 1 (Preparation and Writing): The Android UpdateEngine generates a new GPT, a new boot slot, and new configuration parameters within the trusted execution environment; it assigns a new version number, setting the new version number to equal the effective version number plus one, i.e., NewGeneration = Active Generation + 1; it calculates the new hash value corresponding to the new GPT; it determines the current active region (example: the first storage region Area A) based on the activity record information, and selects the second storage region (Area B) as the current inactive region (backup region); it writes the entire set of update data to the current inactive region Area B via RPMB write authentication frames.

[0203] Phase Two (Data Commit): After all data in the currently inactive area has been written and passed the CRC and structural integrity checks, the data commit status flag corresponding to the currently inactive area is set to valid, indicating that the data in the currently inactive area has been written completely and is available. For example, writing VALID (e.g., 0xFFFFFFFF) as the Data Commit for Area B indicates that the data in Area B is complete and available.

[0204] Phase 3 (Candidate Record Writing): Candidate record information is written to the metadata area, including the candidate activity area identifier, candidate version number, candidate GPT hash value, and data commit status identifier. For example, CandidateArea=B, Candidate Generation=New Gen, Candidate GPT Hash=New Hash, and CandidateCommit=VALID. During this phase, the activity record information remains unchanged, and the activity area does not switch; that is, the activity area remains AreaA. In the event of an abnormal power outage, the data from the original activity area AreaA can be reused.

[0205] Phase Four (Active Commit): After verifying that the data stored in the currently inactive Area B matches the Candidate Metadata in the metadata area, a write operation protected by RPMB authentication is used to update the Active Record information in the metadata area. The update includes the Active Area Flag, the valid version number, and the GPT Trusted Hash value, thus switching the currently inactive area to the new active area. In other words, the Active Area Flag, the valid version number, and the GPT Trusted Hash value are written as a single active record, officially making Area B an active area.

[0206] Phase 5 (Reboot Verification and Rollback): After the device reboots, the bootloader reads and authenticates the activity log information; it verifies the data submission status identifier, data version number, GPT hash value, and slot information corresponding to the new activity area. Upon successful verification, the slot status of the target boot slot is updated to "booting" and an attempt is made to load the operating system image. If the operating system runs stably, the status of the target boot slot changes from "booting" to "confirmed." If the operating system fails to boot, the status of the target boot slot changes from "booting" to "rollback," and the activity log information is restored to the stable version before the update, i.e., maintaining the content of Area A as a trusted activity log.

[0207] Figure 8A schematic diagram illustrating an application scenario provided in this application, such as... Figure 8 As shown, the state machine for the slot state is explained.

[0208] A separate management mechanism is adopted for the active slot identifier and the slot state, which are independent management dimensions. The active slot identifier is used to identify the currently preferred boot slot of the device and determine the default boot target upon power-up; the slot state is used to record the boot verification results and operational health status of the corresponding operating system image slot.

[0209] Before the device is powered on and started, the bootloader determines the target boot slot for this startup based on the active slot identifier stored in the metadata area, and updates the slot status of the target boot slot to the BOOTING state through the RPMB atomic write mechanism.

[0210] If the operating system starts up normally and runs stably, the Trusted Execution Environment will update the slot status of the target boot slot from the booting state to the confirmed state, indicating that the operating system image of the current slot has passed the full boot verification and has reliable availability.

[0211] If a startup failure occurs during the startup process, such as watchdog timeout, kernel panic, or continuous crashes of critical services, the current slot status will be updated from the startup state to the rollback state, and the active slot identifier will be switched to another operating system image slot to achieve self-healing rollback of the startup chain.

[0212] It should be noted that the confirmed status only indicates that the corresponding slot has passed the startup trust verification and the system is running stably; the active slot identifier only limits the slot objects that the device should preferentially start when it is powered on. The two are independent and uncoupled. ROLLBACK is the final state under normal process and cannot be directly restored to the startable state through ordinary update process.

[0213] By employing the above method, slot status is incorporated into RPMB protection, and the active slot identifier serves as an independent "current boot selection pointer," no longer using the active state as the slot status. Slot status employs three critical states: BOOTING, CONFIRMED, and ROLLBACK. Before startup, the target boot slot's status is atomically updated to BOOTING; after the system is running stably, it is updated to CONFIRMED by the TEE; and in the event of a startup timeout, crash, or consecutive failures of critical services, it is updated to ROLLBACK and switched to another slot.

[0214] The inventors also discovered a weakness in the trust chain of secure boot during the boot process, particularly in the critical data stages. Traditional secure boot focuses on verifying the bootloader and system image signatures, but critical data such as the GPT, Active Slot, and Slot status—which "determine what to boot"—may not be under the same level of trusted protection. If the boot selection information or GPT is tampered with, even if the image itself is correctly signed, it may result in the selection of an incorrect version or an unexpected partition. Figure 9 A schematic diagram illustrating an application scenario provided in this application, such as... Figure 9 The diagram illustrates the trusted execution environment key hosting content involved in the Secure Boot process of this application embodiment.

[0215] The Trusted Execution Environment (TEE) securely manages the authentication key of the RPMB and completes the calculation and processing of Hardware Authentication Verification Information (HMAC). The bootloader invokes the TEE capabilities through the Secure Monitor Call (SMC) instruction to complete the legitimate authentication and access of the RPMB.

[0216] The secure boot process performs multi-level chain-based trusted verification, specifically including: (1) verifying the integrity of the bootloader itself based on the public key hash of the chip ROM; (2) reading the metadata area data of the RPMB after hardware authentication (data metadata is trusted), and verifying the integrity and legality of the activity record information, GPT base hash value, active slot identifier and slot status; (3) calculating the real-time hash value of the base GPT in the user data area, comparing the real-time hash value with the GPT base hash value, and reading the backup GPT from the current active area to complete the base GPT repair when the comparison is abnormal; (4) locating the operating system image of the target boot slot based on the verified trusted base GPT, and verifying the digital signature of the Boot / vbmeta / system image and the integrity of AVB; (5) verifying the valid version number and rollback status constraints to prevent the device from booting expired versions or illegal system versions marked for rollback; (6) after all verification items pass the verification, loading the kernel and handing over the system operation control. If any level of trusted verification fails, loading and booting the unverified operating system image is prohibited, and the device will enter the abnormal recovery path to execute the repair and rollback logic.

[0217] In this way, the bootloader first verifies itself based on the root of trust embedded in the chip ROM, then authenticates and reads the metadata of the RPMB, and sequentially verifies the base hash value (trusted digest) of the GPT, the Active Slot and Slot status, and Generation consistency. Finally, it locates the target operating system image based on the trusted GPT and performs digital signature / AVB verification, thereby establishing a continuous trust chain of "ROM root of trust → Bootloader → RPMB boot key data → GPT → Slot → system image".

[0218] Figure 10 A data flow diagram provided for this application, such as Figure 10 As shown, the bootloader is the core of the startup process. The public key hash embedded in the chip ROM constructs the root of trust for startup. The ARM TrustZone trusted execution environment is responsible for managing the authentication key and authentication verification calculation of the replay protection memory block. The bootloader completes the authentication call through security monitoring call instructions to achieve hardware authentication access to the RPMB partition. The RPMB is internally divided into three logical partitions: metadata area, first storage area, and second storage area. The metadata area stores slot status, active slot identifier, activity record information for managing the currently effective configuration, and candidate record information for carrying the upgrade configuration to be effective. The activity record information includes the base hash value, active area identifier, and effective version number. The candidate record information includes the hash value of the candidate GPT, candidate active area identifier, candidate version number, and data submission status identifier of the candidate record information. The first and second storage areas respectively store their respective backup data, data version number of the corresponding area, and data submission status identifier.

[0219] During the normal boot process, the bootloader reads the activity record information in the RPMB metadata area after authentication, extracts the base hash value and compares it with the base GPT real-time hash stored in the user data area. If the comparison is inconsistent, the backup GPT is retrieved from the current active storage area pointed to by the activity record information to repair the base GPT in the user data area. Then, the target boot slot is selected by combining the active slot identifier and slot status in the metadata area. The operating system image in the user data area is located based on the trusted base GPT and subsequent boot verification is performed.

[0220] When performing a system upgrade, the upgrade program first writes complete update data, including the new GPT version, configuration parameters, and version information, to the currently inactive storage area. After setting the data commit status flag for that area, it writes complete candidate record information to the metadata area. Once the data in the inactive storage area is verified to be consistent with the candidate record information, the active record information is replaced with the candidate record information by a single authenticated write operation, and the switch of the active area is completed synchronously. This ensures the atomicity of the configuration update and avoids configuration corruption caused by power failure during the upgrade.

[0221] The RPMB hardware isolation protects the startup metadata, and the dual-region rotation and candidate / effective two-level recording mechanism simultaneously achieve GPT integrity self-verification, upgrade atomic update and slot status trusted management.

[0222] In summary, this application forms a closed loop by integrating RPMB hardware protection, GPT trusted digests, dual-region atomic updates, Boot Slot state machines, and Secure Boot verification: RPMB provides authenticated access and a monotonic write counter; the base hash value of GPT establishes a trusted verification relationship from the base GPT in the user data area to the hardware-protected data; the version number and data commit status identification mechanism ensures that at least the previous stable version is retained during the update process; the active slot identifier and slot status are separated, respectively expressing "current selection" and "boot verification result"; and secure boot ultimately performs digital signature / AVB verification on the target image. This forms a complete technical chain of "trusted data storage—atomic update—anomaly recovery—anti-rollback—image verification." Therefore, the embodiments of this application have the following advantages:

[0223] (1) Improve the security of critical startup data: Utilize RPMB hardware-level HMAC authentication and write counter to protect GPT trusted digests, active slot identifiers and slot status, thereby reducing the impact of ordinary software permissions or physical modifications on critical startup data.

[0224] (2) Improve anomaly recovery capability: By using Area A / Area B dual copies and trusted backup GPT, an independent recovery path is provided when the baseline GPT is abnormal, and the previous stable activity record information is retained when the update is abnormal.

[0225] (3) Improve upgrade reliability: The phased submission mechanism is formed by the version number, data submission status indicator, candidate record information data submission status indicator and activity record information, so that the recovery action of "continuing the old version, completing the candidate submission or rolling back" can be determined when the power failure occurs at different stages.

[0226] (4) Improve rollback prevention capability: Utilize the monotonically increasing characteristic of the RPMB write counter and the version constraint of the version number to prevent the old state from being replayed and prohibit the ROLLBACK state from being restored to the startable state through the normal process.

[0227] (5) Improve the integrity of the boot trust chain: link the ROM-fixed root of trust, bootloader, RPMB trusted boot key data, GPT, slot status and system image signature / AVB verification to avoid only verifying the system image without verifying the key selection information of "what to boot".

[0228] Figure 11 A schematic diagram of the structure of the boot device for the operating system provided in this application is shown below. Figure 11 As shown, the operating system boot device 400 provided in this embodiment includes:

[0229] The authentication module 401 is used to access the RPMB after the embedded device is powered on, based on the bootloader and through hardware authentication.

[0230] The calculation module 402 is used to calculate the real-time hash value of the baseline GPT based on the baseline GPT stored in the user data area;

[0231] The first startup module 403 is used to locate the sector address of the operating system image based on the reference GPT and start the operating system if it is determined that the real-time hash value is consistent with the reference hash value stored in RPMB.

[0232] The second boot module 404 is used to update the base GPT stored in the user data area according to the backup GPT stored in the RPMB if it is determined that the real-time hash value is inconsistent with the base hash value, and to locate the sector address of the operating system image according to the updated base GPT and start the operating system.

[0233] In one possible implementation, the RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores active record information and candidate record information; the second startup module 404 is used for:

[0234] Based on the activity record information and candidate record information, determine the current active region from the first storage region and the second storage region;

[0235] Retrieve backup GPT from the currently active region;

[0236] Perform integrity verification on the backup GPT, and update the baseline GPT stored in the user data area based on the backup GPT after the verification passes.

[0237] In one possible implementation, the activity record information includes a base hash value, an activity region identifier, and a valid version number; the candidate record information includes a candidate activity region identifier, a candidate GPT hash value, a data submission status identifier for the candidate record information, and a candidate version number.

[0238] The second startup module 404 is used for:

[0239] If the data submission status identifier of the candidate record information is determined to be invalid, then the storage area corresponding to the active area identifier will be taken as the current active area.

[0240] If the data submission status identifier of the candidate record information is determined to be valid, then check whether the candidate version number is equal to the valid version number plus one, whether the data submission status identifier of the storage area corresponding to the candidate active area identifier is valid, and whether the hash value of the GPT stored in the storage area corresponding to the candidate active area identifier is consistent with the hash value of the candidate GPT. If all the verification results are yes, then the storage area corresponding to the candidate active area identifier is taken as the current active area. If the verification results are no, then the storage area corresponding to the active area identifier is taken as the current active area.

[0241] In one possible implementation, the RPMB includes a metadata area; the metadata area stores the slot status and active slot identifier of the operating system image slot; the first boot module 403 or the second boot module 404 is used for:

[0242] Determine the target boot slot based on the slot status and active slot identifier of the operating system image slot;

[0243] Based on the target GPT, determine the sector address of the target boot slot in the user data area, load the operating system image stored in the target boot slot, and start the operating system; wherein, the target GPT is the base GPT or an updated base GPT.

[0244] In one possible implementation, the first startup module 403 or the second startup module 404 is configured to:

[0245] If the slot status of the slot corresponding to the active slot identifier is confirmed, then the slot corresponding to the active slot identifier will be identified as the target startup slot.

[0246] If the slot corresponding to the active slot identifier is determined to be in the startup state, and all slots are in the startup state, then the slot corresponding to the active slot identifier is determined as the target startup slot.

[0247] If the slot corresponding to the active slot identifier is determined to be in a rollback state, and the slot of another slot is in a non-rollback state, then the other slot is determined as the target startup slot.

[0248] In one possible implementation, the RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores active record information and candidate record information; the device further includes an update module for:

[0249] Retrieve system update data; system update data includes the new GPT, the new hash value of the new GPT, new configuration parameter information, new version number, and new slot information;

[0250] The system update data is written to the currently inactive region via the write authentication frame of RPMB; the currently inactive region refers to the storage region in the first storage region and the second storage region that is not pointed to by the active region identifier in the activity record information.

[0251] After the write is complete, set the data commit status flag of the currently inactive region to valid and update the data version number of the currently inactive region to the new version number;

[0252] Based on the current inactive region, the new version number, and the new hash value, candidate record information is generated and written to the metadata area;

[0253] If it is confirmed that the data stored in the current inactive region is consistent with the candidate record information, the active record information is updated as a whole using the candidate record information through the RPMB write authentication frame, so that the current inactive region becomes the current active region.

[0254] In one possible implementation, the update module is used for:

[0255] During the first operating system reboot after the system update data has been written, the new GPT is read from the storage area corresponding to the updated activity log information based on the bootloader, and the operating system is started according to the new GPT.

[0256] If the operating system fails to boot, the updated activity log information will be rolled back to the activity log information before the update, based on the bootloader.

[0257] In one possible implementation, the authentication module 401 is used for:

[0258] The bootloader sends a read authentication frame to the RPMB; the read authentication frame carries a write counter, frame number and verification information.

[0259] If the authentication of the read authentication frame is confirmed to be successful, access to the RPMB is permitted.

[0260] The operating system boot device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0261] Figure 12 A schematic diagram of the structure of the electronic device provided in this application. Figure 12 As shown, the electronic device 500 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the electronic device 500 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus. This electronic device can be the aforementioned embedded device, and the memory can be the aforementioned storage device.

[0262] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0263] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0264] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0265] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0266] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0267] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0268] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0269] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0270] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0271] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0272] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0273] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0274] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0275] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0276] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope.

Claims

1. A method for starting an operating system, characterized in that, The method is applied to an embedded device, which is configured with a storage device, the storage device including a user data area and a replay protection memory block area (RPMB). The RPMB stores the base hash value and backup GPT of the globally unique identifier partition table; the method includes: After the embedded device is powered on, it accesses the RPMB after hardware authentication based on the bootloader; Calculate the real-time hash value of the benchmark GPT based on the benchmark GPT stored in the user data area; If it is determined that the real-time hash value is consistent with the baseline hash value stored in the RPMB, then the operating system image sector address is located according to the baseline GPT, and the operating system is started. If it is determined that the real-time hash value is inconsistent with the baseline hash value, the baseline GPT stored in the user data area is updated according to the backup GPT stored in the RPMB, and the sector address of the operating system image is located according to the updated baseline GPT, and the operating system is started.

2. The method according to claim 1, characterized in that, The RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores activity record information and candidate record information; updating the baseline GPT stored in the user data area according to the backup GPT stored in the RPMB includes: Based on the activity record information and the candidate record information, determine the current active region from the first storage region and the second storage region; Obtain the backup GPT from the currently active region; The backup GPT is verified for integrity, and the baseline GPT stored in the user data area is updated based on the backup GPT after the verification is successful.

3. The method according to claim 2, characterized in that, The activity record information includes a base hash value, an activity region identifier, and a valid version number; the candidate record information includes a candidate activity region identifier, a candidate GPT hash value, a data submission status identifier for the candidate record information, and a candidate version number. The step of determining the current active region from the first storage region and the second storage region based on the activity record information and the candidate record information includes: If it is determined that the data submission status identifier of the candidate record information is invalid, then the storage area corresponding to the active area identifier is taken as the current active area; If the data submission status identifier of the candidate record information is determined to be valid, then the following checks are performed: whether the candidate version number is equal to the valid version number plus one; whether the data submission status identifier of the storage area corresponding to the candidate activity area identifier is valid; and whether the hash value of the GPT stored in the storage area corresponding to the candidate activity area identifier is consistent with the hash value of the candidate GPT. If all the verification results are yes, then the storage area corresponding to the candidate activity area identifier is taken as the current activity area. If the verification results are no, then the storage area corresponding to the activity area identifier is taken as the current activity area.

4. The method according to claim 1, characterized in that, The RPMB includes a metadata area; the metadata area stores the slot status and active slot identifier of the operating system image slots; the step of locating the sector address of the operating system image according to the reference GPT and starting the operating system, or the step of locating the sector address of the operating system image according to the updated reference GPT and starting the operating system, includes: The target boot slot is determined based on the slot status and active slot identifier of the operating system image. Based on the target GPT, determine the sector address of the target boot slot in the user data area, load the operating system image stored in the target boot slot, and start the operating system; wherein, the target GPT is the base GPT or an updated base GPT.

5. The method according to claim 4, characterized in that, The step of determining the target boot slot based on the slot status and active slot identifier of the operating system image includes: If the slot status of the slot corresponding to the active slot identifier is determined to be confirmed, then the slot corresponding to the active slot identifier is determined as the target startup slot. If it is determined that the slot status of the slot corresponding to the active slot identifier is in the starting state, and the slot status of all slots is in the starting state, then the slot corresponding to the active slot identifier is determined as the target starting slot. If it is determined that the slot corresponding to the active slot identifier is in a rollback state, and the slot of another slot is in a non-rollback state, then the other slot is determined as the target startup slot.

6. The method according to claim 1, characterized in that, The RPMB includes a metadata area, a first storage area, and a second storage area; the metadata area stores active record information and candidate record information; the method further includes: Obtain system update data; the system update data includes the new GPT, the new hash value of the new GPT, new configuration parameter information, new version number, and new slot information; The system update data is written to the current inactive region via the write authentication frame of the RPMB; wherein, the current inactive region refers to the storage region in the first storage region and the second storage region that is not pointed to by the active region identifier in the activity record information; After the write operation is completed, the data commit status flag of the currently inactive region is set to valid, and the data version number of the currently inactive region is updated to the new version number; Based on the current inactive region, the new version number, and the new hash value, candidate record information is generated and written into the metadata area; If it is confirmed that the data stored in the current inactive region is consistent with the candidate record information, then the active record information is updated as a whole using the candidate record information through the write authentication frame of the RPMB, so that the current inactive region becomes the current active region.

7. The method according to claim 6, characterized in that, The method further includes: During the first operating system reboot after the system update data writing is completed, the new GPT is read from the storage area corresponding to the updated activity record information based on the bootloader, and the operating system is started according to the new GPT; If the operating system fails to boot, the updated activity log information will be rolled back to the activity log information before the update, based on the bootloader.

8. The method according to any one of claims 1-7, characterized in that, The access to RPMB based on the bootloader and after hardware authentication includes: The bootloader sends a read authentication frame to the RPMB; wherein the read authentication frame carries a write counter, a frame number, and verification information. If the authentication of the read authentication frame is confirmed to be successful, access to the RPMB is permitted.

9. A boot device for an operating system, characterized in that, The device is applied to an embedded device, which is equipped with a storage device, the storage device including a user data area and a replay protection memory block area (RPMB). The RPMB stores the base hash value and backup GPT of the globally unique identifier partition table (GPT); the device includes: The authentication module is used to access the RPMB after the embedded device is powered on, based on the bootloader and after hardware authentication. The calculation module is used to calculate the real-time hash value of the benchmark GPT based on the benchmark GPT stored in the user data area; The first startup module is used to start the operating system if it is determined that the real-time hash value is consistent with the base hash value stored in the RPMB, and then locates the sector address of the operating system image according to the base GPT. The second startup module is used to update the base GPT stored in the user data area according to the backup GPT stored in the RPMB if it is determined that the real-time hash value is inconsistent with the base hash value, and to locate the sector address of the operating system image according to the updated base GPT and start the operating system.

10. An electronic device / computer-readable storage medium / computer program product, characterized in that, The electronic device includes: a memory and a processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8; The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8; The computer program product includes a computer program that, when executed by a processor, is used to implement the method as described in any one of claims 1-8.

Images