Kernel starting method and device, electronic equipment, storage medium and program product

Abstract

This application provides a kernel booting method, apparatus, electronic device, storage medium, and program product. The method is applied to an electronic device running a trusted operating system, the kernel of which is a position-independent executable program. The method includes: receiving a boot command; in response to the boot command, generating a random number and storing the random number in a first memory space; the first memory space is a hardware-isolated and protected memory space; when the kernel is booted, reading the random number from the first memory space and obtaining a random offset address based on the random number; obtaining the actual virtual address of the kernel based on the random offset address and the kernel's link address; and running the kernel in a second memory space corresponding to the actual virtual address of the kernel. The method of this application improves the security of the trusted operating system.

Description

Technical Field

[0001] This application relates to operating system technology, and more particularly to a kernel boot method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] The kernel is a fundamental component of the Linux operating system. It's the first layer of software extension based on the hardware, providing the most basic functions of the operating system, such as managing system processes, memory, and device drivers, and determining the system's performance and stability. To ensure the simultaneous execution of multiple executable files, prevent interference between different executables during execution, and speed up execution, executable files need to be loaded into virtual memory at virtual addresses, rather than directly into physical memory at physical addresses. Similarly, when running the kernel, compiled into an executable file, it needs to be loaded into virtual memory at the corresponding virtual address.

[0003] In existing technologies, when compiling the kernel of the Linux operating system, the kernel is compiled and linked with a fixed link address. In this way, the kernel is loaded into the virtual memory corresponding to the fixed virtual address when it starts up.

[0004] However, if the operating system kernel runs at a fixed virtual address, attackers can easily obtain the kernel's running address (i.e., the aforementioned fixed virtual address) through buffer overflow attacks, thereby disrupting the stable operation of the operating system kernel and reducing the security of the operating system. Summary of the Invention

[0005] This application provides a kernel boot method, apparatus, electronic device, storage medium, and program product to address the problem of low security during the operation of a trusted operating system.

[0006] In a first aspect, this application provides a kernel boot method, the method being applied to an electronic device running a trusted operating system, wherein the kernel of the trusted operating system is a position-independent executable program, the method comprising:

[0007] Receive power-on command;

[0008] In response to the power-on command, a random number is generated and stored in a first memory space; the first memory space is a hardware-isolated and protected memory space.

[0009] When the kernel is started, the random number is read from the first memory space, and a random offset address is obtained based on the random number;

[0010] The actual virtual address of the kernel is obtained based on the random offset address and the kernel's link address; the random offset address is within a first value range, the link address is within a second value range, the sum of the maximum value of the first value range and the maximum value of the second value range is less than or equal to the maximum value of the kernel's virtual address space, and the sum of the minimum value of the first value range and the minimum value of the second value range is greater than or equal to the minimum value of the virtual address space;

[0011] The kernel runs in the second memory space corresponding to the actual virtual address of the kernel.

[0012] Optionally, the random number includes a first number of bytes; obtaining the random offset address based on the random number includes:

[0013] A second number of bytes are selected from the random numbers to form a seed for generating the random offset address, wherein the second number is less than the first number;

[0014] The mask address is determined based on the kernel's first-level page table granularity and the second value range.

[0015] The random offset address is obtained by performing a bitwise AND operation between the mask address and the seed.

[0016] Optionally, the kernel includes a global offset table and a first code segment, the first code segment storing description information of the symbols to be relocated in the global offset table;

[0017] Running the kernel in the second memory space corresponding to the actual virtual address of the kernel includes:

[0018] Obtain the description information of the symbol to be relocated in the global offset table from the first code segment;

[0019] Based on the description information of the symbol to be relocated in the global offset table and the random offset address, the link address of the symbol to be relocated in the global offset table is relocated to obtain the processed global offset table.

[0020] The kernel runs in the second memory space corresponding to the actual virtual address of the kernel, based on the processed global offset table.

[0021] Optionally, the first code segment is a scrambled code segment;

[0022] The step of obtaining the description information of the symbol to be relocated in the global offset table from the first code segment includes:

[0023] The first code segment is descrambled;

[0024] The description information of the symbol to be relocated in the global offset table is obtained from the first code segment after descrambling.

[0025] Optionally, the step of relocating the link addresses of the symbols to be relocated in the global offset table based on the description information of the symbols to be relocated in the global offset table and the random offset address, to obtain a processed global offset table, includes:

[0026] Based on the description information of the symbol to be relocated in the global offset table, obtain the link address of the symbol to be relocated from the global offset table;

[0027] Add the link address of the symbol to be relocated to the random offset address to obtain the link address after the symbol relocation process;

[0028] The link address after symbol relocation is updated in the global offset table to obtain the processed global offset table.

[0029] Optionally, the method further includes:

[0030] An encryption key is generated using the key stored in the one-time programmable memory and the identifier of the one-time programmable memory;

[0031] The target data is encrypted using an encryption key to obtain encrypted target data; the target data includes: the random number and / or the random offset address;

[0032] The encrypted target data, along with the identifier of the one-time programmable memory, is stored in the read-only code segment of the kernel.

[0033] Optionally, the method further includes:

[0034] When the kernel encounters an anomaly, the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address are obtained.

[0035] The encryption key is generated using the key and the identifier of the one-time programmable memory;

[0036] The encrypted target data is decrypted using the encryption key to obtain the target data.

[0037] Using the target data and the actual virtual address, the link address of the kernel is obtained;

[0038] The kernel is processed according to its link address.

[0039] Optionally, obtaining the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address includes:

[0040] Determine if the kernel's runtime log exists;

[0041] If the operation log exists, then print the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address in the output information of the operation log;

[0042] If the runtime log does not exist, the physical start address of the read-only code segment is accessed to obtain the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address.

[0043] Secondly, this application also provides a kernel booting device, which is applied to an electronic device running a trusted operating system, wherein the kernel of the trusted operating system is a position-independent executable program, and the device includes:

[0044] The receiving module is used to receive the power-on command;

[0045] The generation module is used to generate random numbers in response to the power-on command;

[0046] A storage module is used to store the random number into a first memory space; the first memory space is a hardware-isolated and protected memory space.

[0047] A reading module is used to read the random number from the first memory space when the kernel is started;

[0048] The first acquisition module is used to acquire a random offset address based on the random number;

[0049] The second acquisition module is used to acquire the actual virtual address of the kernel based on the random offset address and the kernel's link address; the random offset address is within a first value range, the link address is within a second value range, the sum of the maximum value of the first value range and the maximum value of the second value range is less than or equal to the maximum value of the kernel's virtual address space, and the sum of the minimum value of the first value range and the minimum value of the second value range is greater than or equal to the minimum value of the virtual address space;

[0050] The runtime module is used to run the kernel in the second memory space corresponding to the actual virtual address of the kernel.

[0051] Thirdly, this application provides an electronic device that runs a trusted operating system, the kernel of which is a position-independent executable program, and the electronic device includes: a processor and a memory communicatively connected to the processor;

[0052] The memory stores computer-executed instructions;

[0053] The processor executes computer execution instructions stored in the memory to implement the method as described in any one of the first aspects.

[0054] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0055] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method as described in any one of the first aspects.

[0056] In a sixth aspect, this application provides a chip on which a computer program is stored, and when the computer program is executed by the chip, it implements the method as described in any one of the first aspects.

[0057] The kernel booting method, apparatus, electronic device, storage medium, and program product provided in this application employ address space layout randomization technology. First, a random number is generated and then stored in hardware-isolated and protected memory. Before kernel boot, this random number is retrieved and a random offset address is generated based on it, enabling the trusted operating system kernel to run at the actual virtual address generated by the random offset address. This method improves the operational security of the trusted operating system kernel. Attached Figure Description

[0058] 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.

[0059] Figure 1 A flowchart illustrating the first kernel boot method provided in this application;

[0060] Figure 2 A flowchart illustrating the second kernel boot method provided in this application;

[0061] Figure 3 A flowchart illustrating the third kernel boot method provided in this application;

[0062] Figure 4A flowchart illustrating the fourth kernel boot method provided in this application;

[0063] Figure 5 A flowchart illustrating the fifth kernel boot method provided in this application;

[0064] Figure 6 A flowchart illustrating the sixth kernel boot method provided in this application;

[0065] Figure 7 A schematic diagram of a kernel boot device provided in this application;

[0066] Figure 8 This is a schematic diagram of the structure of an electronic device 110 provided in this application.

[0067] 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

[0068] 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 as detailed in the appended claims.

[0069] First, let me explain the terms used in this application:

[0070] Trusted Execution Environment (TEE): A trusted runtime environment that operates in isolation from untrusted runtime environments, preventing privileged attackers who can control the operating system and basic input / output system (BIOS) from extracting or tampering with data in the TEE.

[0071] Hardware isolation technology: Hardware protected by hardware isolation technology can ensure the security of its internal data. Hardware protected by hardware isolation technology can restrict access to the data of executable files running in TEE to only executable files running in TEE.

[0072] Trusted Operating System: refers to the operating system running in a TEE.

[0073] The Global Offset Table (GOT) is a table used in the Linux operating system to locate symbols (i.e., global variables and functions) during the execution of executable files. This table stores the link addresses of the symbols.

[0074] Link address: When compiling code into an executable program, the virtual address in virtual memory where the executable program runs is specified. This specified virtual address is the link address.

[0075] The kernel is a fundamental component of the Linux operating system. It's the first layer of software extension based on the hardware, providing the most basic functions of the operating system, such as managing system processes, memory, and device drivers, and determining the system's performance and stability. To ensure the simultaneous execution of multiple executable files, prevent interference between different executables during execution, and speed up execution, executable files need to be loaded into virtual memory space corresponding to virtual addresses, rather than directly into physical memory at physical addresses. Similarly, when running the kernel, compiled into an executable file, it needs to be loaded into virtual memory space corresponding to its virtual addresses.

[0076] In the existing technology, when compiling the kernel of the Linux operating system, the kernel is compiled and linked with a fixed link address. In this way, when an electronic device with the Linux operating system is deployed starts the kernel, the kernel is loaded into the virtual memory corresponding to the link address and runs. The data and programs in the kernel will also run according to the fixed link address.

[0077] A buffer overflow attack is an attack that exploits buffer overflow vulnerabilities. The success of a buffer overflow attack is closely related to whether the attacker can guess the kernel's running address in memory. When the operating system kernel runs at a fixed virtual address, the kernel's memory layout is essentially transparent to the attacker. Therefore, attackers can easily launch attacks on the kernel running in the virtual memory space corresponding to the fixed virtual address through buffer overflow attacks, thereby disrupting the stable operation of the operating system.

[0078] Existing technologies include Address Space Layout Randomization (ASLR), which enables executable files to be loaded into virtual memory spaces corresponding to randomly generated virtual addresses for execution.

[0079] The inventors discovered that if the Linux operating system kernel could run in a virtual memory space corresponding to a randomly generated virtual address, it would increase the difficulty for attackers to obtain the virtual address where the kernel is running, thus preventing attackers from disrupting the operation of the operating system through buffer overflow attacks and improving the operating system's security.

[0080] In view of this, this application provides a kernel boot method. Figure 1 A flowchart illustrating the first kernel boot method provided in this application is shown below. Figure 1 As shown, this method uses ASLR technology to generate random offset addresses based on random numbers, thereby causing the Linux operating system kernel to run at randomly generated virtual addresses. This method increases the difficulty for attackers to obtain critical kernel data and the exact addresses of programs, thus reducing the likelihood of successful buffer overflow attacks and improving the security of the Linux operating system kernel.

[0081] 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.

[0082] The kernel boot method provided in this application is applied to electronic devices running a trusted operating system. These electronic devices can be mobile phones, computers, servers, etc., and this application does not limit them. The execution entity of the kernel boot method provided in this application can be the central processing unit (CPU) in the aforementioned electronic device. The trusted operating system is a Linux system.

[0083] Furthermore, to enable the trusted operating system kernel to run in a virtual memory space corresponding to random addresses, rather than a virtual memory space corresponding to fixed virtual addresses, the kernel needs to be configured as a position-independent executable file. A position-independent executable file is one that can run in any legal memory location. This application does not limit the method of compiling the trusted operating system kernel into a position-independent executable program; those skilled in the art can configure it according to actual needs. For example, it can be configured as follows:

[0084] The kernel of the trusted operating system is compiled using GCC (GNU Compiler Collection). During compilation, options are added to the GCC compilation options to compile the kernel into a position-independent executable, such as -fPIE and -pie options. When generating the executable file, to avoid generating symbols of type R_AARCH64_ABS64, the -Bsymbolic linking option is added, ensuring that the relocation symbols generated after linking are of type R_AARCH64_RELATIVE (0x403). The specific compilation method described above can be found in existing technologies and will not be elaborated further here.

[0085] Figure 2 A flowchart illustrating the second kernel boot method provided in this application is shown below. Figure 2 As shown, it includes the following steps:

[0086] S101, Receive power-on command.

[0087] As one possible implementation, the aforementioned electronic device running a trusted operating system is equipped with physical buttons, and the CPU can receive a power-on command triggered by the aforementioned physical buttons.

[0088] As another possible implementation, after powering on an electronic device running a trusted operating system, the CPU can receive a power-on command triggered by the power-on.

[0089] S102. In response to the power-on command, generate a random number and store the random number in the first memory space.

[0090] For example, the aforementioned random number could be generated by the CPU by running an executable file that performs the initialization operation when initializing the electronic device. (See reference...) Figure 1 The executable file that performs the initialization operation mentioned above can be, for example, a secure loader. This application does not limit the code that performs the initialization operation.

[0091] Alternatively, after initializing the electronic device, the CPU can generate the aforementioned random number using a random number generator. This random number can be either pseudo-random or true random, depending on the type of random number generator. For example, when performing the initialization operation of the electronic device, the CPU runs a secure loader to obtain the random number generated by the random number generator.

[0092] The number of bits and the representation of the random number generated in this application are related to the subsequent implementation of obtaining a random offset address based on the random number.

[0093] For example, if the generated random number is used directly as the random offset address, then the random number needs to meet the requirements for random offset addresses in this application. For instance, the random number needs to use the same representation as the link address, such as hexadecimal representation.

[0094] If the random offset address is constructed based on bytes selected from a random number, there are no limitations on the number of bits or the representation method of the generated random number; those skilled in the art can set them according to the actual situation. For example, the number of bits of the random number can be 64 bits or 256 bits; the random number can be represented by binary characters, decimal characters, or hexadecimal characters.

[0095] The aforementioned first memory space is a hardware-isolated and protected memory space, which is physical memory. As one possible implementation, when configuring an electronic device containing a trusted operating system, one or more memory blocks are selected and protected using hardware isolation technology to obtain the first memory space. This hardware isolation technology can limit the executable programs that can read data from this first memory space. In this application, access to the first memory space and the data stored within it can be limited to executable programs running in a TEE environment. The method of selecting memory can be determined according to actual circumstances, and this application does not limit it; for example, it can be randomly selected.

[0096] S103. When starting the kernel, read a random number from the first memory space and obtain a random offset address based on the random number.

[0097] The random offset address is represented in the same way as the link address. For example, if the link address is represented in hexadecimal characters, the random offset address is also represented in hexadecimal characters; if the link address is represented in binary characters, the random offset address is also represented in binary characters, and so on. Taking a hexadecimal representation of the random offset address as an example, the random offset address could be, for instance, 0xAC00000.

[0098] In this step, the trusted operating system kernel runs in the TEE after booting, possessing high security attributes. In this application, the first memory space, protected by hardware isolation, is configured to be accessible only to executable programs running in the TEE. Therefore, the trusted operating system kernel can read the random numbers stored in the first memory space during boot.

[0099] Random numbers are used to generate random offset addresses and play a crucial role in the implementation of the entire scheme. The above method ensures that, apart from executable files running in the TEE, other programs cannot access or modify the random numbers in the hardware-isolated first memory space. This guarantees that the random numbers will not be leaked or tampered with by other programs, thus ensuring the reliability of the random offset addresses generated later based on these random numbers.

[0100] As one possible implementation, the generated random number can be used directly as the random offset address.

[0101] As another possible implementation, the random number consists of a first number of bytes, from which a second number of bytes are selected, and then a random offset address is constructed based on this second number of bytes. The second number is less than the first number.

[0102] S104. Obtain the actual virtual address of the kernel based on the random offset address and the kernel's link address.

[0103] The aforementioned random offset address is within the first value range, the link address is within the second value range, the maximum value of the first value range and the sum of the maximum values ​​of the second value range are less than or equal to the maximum value of the kernel's virtual address space, and the minimum value of the first value range and the sum of the minimum values ​​of the second value range are greater than or equal to the minimum value of the virtual address space.

[0104] The aforementioned virtual address space is a space comprised of virtual memory corresponding to virtual addresses available for kernel execution. The size of this virtual address space could be, for example, 1GB. The first value range refers to the size of the virtual address space occupied by the range of random offset addresses. The second value range refers to the size of the virtual address space occupied by the range of link addresses.

[0105] It should be noted that this application does not limit the size of the virtual address space, nor does it limit the specific values ​​of the first and second value ranges. Those skilled in the art can set them according to actual needs.

[0106] For example, it's believed that the stronger the randomness of the random offset address value, the stronger the operational security of the operating system kernel. The randomness of the random offset address value is positively correlated with the size of the first value range. Therefore, the virtual address space range can be appropriately expanded to also expand the first value range, thereby enhancing the randomness of the random offset address value. However, expanding the virtual address space also increases the memory occupied by the page tables used to store the mapping relationship between virtual and physical addresses. Excessive memory occupied by the page tables will affect the normal operation of the kernel loaded in the virtual address space. Therefore, when compiling the operating system kernel, the size of the virtual address space can be appropriately expanded by considering both factors, ensuring the randomness of the random offset address while avoiding the impact on kernel operation caused by excessive memory occupation by the page tables.

[0107] For example, taking the kernel's virtual address space as 1G as an example, the first value range can be [0, 1G / 2], and the second value range can be [0, 1G / 2]; or, the first value range can be [0, 2G / 3], and the second value range can be [0, 1G / 3].

[0108] The aforementioned actual virtual address is the virtual address where the kernel actually runs in virtual memory.

[0109] As one possible implementation, the actual virtual address of the kernel can be obtained using the following formula:

[0110] Actual virtual address = link address + random offset address

[0111] For example, if the link address is 0xFFFFFFFFA0000000 and the random offset address is 0xAC00000, then the actual virtual address can be obtained as 0xFFFFFFFFAAC00000.

[0112] This implementation ensures that the virtual memory difference between the kernel's first-level page table granularity and the random offset address remains consistent. For example, if the kernel's first-level page table granularity is 1MB, then the difference in virtual memory between two adjacent random offset addresses will also be 1MB. This application does not limit the virtual memory difference between the kernel's first-level page table granularity and the random offset address.

[0113] As another possible implementation, the actual virtual address of the kernel can be obtained according to the following formula:

[0114] Actual virtual address = Link address + Random offset address / 2

[0115] This implementation method allows the kernel's first-level page table granularity to be consistent with the granularity of the value of "random offset address / 2".

[0116] S105. Run the kernel in the second memory space corresponding to the actual virtual address of the kernel.

[0117] Each virtual address corresponds to a block of virtual memory. In this step, after obtaining the actual virtual address, the kernel is loaded into the virtual memory corresponding to the actual virtual address, i.e., the second memory space, and then the kernel is run. Specific implementation details can be found in existing technologies and will not be elaborated upon here.

[0118] In this embodiment, before each run of the trusted operating system kernel, the CPU obtains a random number and then generates a random offset address based on that number. Further, the CPU determines the actual virtual address based on this random offset address, so that the trusted operating system kernel runs at that actual virtual address. This method ensures that the kernel runs at a newly randomly generated virtual address each time it boots. This increases the difficulty for attackers to obtain the kernel's running address, thus improving the security of the operating system kernel.

[0119] Furthermore, in this embodiment, since the kernel of the trusted operating system is compiled into a position-independent executable file, it does not need to be loaded into a fixed execution address but can run at any execution address. Therefore, when there is insufficient memory space and it is necessary to expand the virtual address space or adjust the kernel's execution address by regenerating a random offset address, there is no need to recompile the kernel and release it based on the new execution address, thus reducing the cost of kernel version maintenance.

[0120] Furthermore, during the initialization operation, a random number is generated and then stored in a hardware-isolated and protected first memory space. This application restricts this hardware-isolated and protected first memory space to be read only by executable programs running in a TEE environment. The trusted operating system kernel in this application is an executable program running in a TEE environment. Therefore, the random number stored in the first memory space can only be read by the executable operating system kernel running in the TEE environment. Since the random offset address is obtained based on the random number, this method prevents the random number from being obtained and tampered with by other executable programs besides those running in the TEE environment, ensuring the randomness of the random number and the random offset address generated accordingly, further guaranteeing system security.

[0121] The following explains how to obtain a random offset address based on a random number in the above embodiments. Specifically, there are two methods:

[0122] Method 1: Directly use the generated random number as the random offset address.

[0123] In this implementation, the generated random number is constrained during generation to ensure it meets the requirements for the random offset address in this embodiment. For example, the generated random number can be represented in the same way as the link address, such as using hexadecimal characters; alternatively, the number of bytes in the random number can be limited to 4. Specifically, the generated random number is constrained based on the actual requirements for the random offset address.

[0124] The above method can quickly obtain a random offset address, which satisfies the requirement that the random offset address is randomly generated and also achieves efficient and fast acquisition of the random offset address.

[0125] Method 2: The random number includes a first number of bytes. A second number of bytes are selected from the random number, and then a random offset address is constructed based on the second number of bytes.

[0126] The method of selecting a second number of bytes from the random number is related to the subsequent implementation of constructing a random offset address based on that second number of bytes.

[0127] As one possible implementation, the aforementioned second number of bytes can be directly used as the random offset address. In this case, the second number of bytes needs to meet the requirements for the random offset address in this application. The second number of random numbers can be selected using a preset method. For example, the value of the second number can be limited to meet the requirements for the random offset address in this application.

[0128] As another possible implementation method Figure 3 A schematic diagram of the third kernel boot method provided in this application is shown below. Figure 3 As shown, it includes the following steps:

[0129] S201. Select a second number of bytes from the random number to form a seed for generating a random offset address.

[0130] The method for selecting the second number of bytes from the random number can be random consecutive selection, random unordered selection, or selection according to a preset method, such as preset selection of the 2nd, 4th, 6th, 8th, and 10th bytes. This application does not limit the method for selecting the second number of bytes from the random number.

[0131] Taking the random number as a hexadecimal character representation as an example, assuming the random number is CEB4EBB44AF9183F1AD7AFBFC03C1A10E1AD1860FC343B2BD240484E66786A06, randomly select 4 consecutive bytes from this random number, for example, it could be 1AD7AFBF.

[0132] This application does not limit the method by which the second number of bytes selected based on a random number constitutes the seed for generating the random offset address. For example, the second number of bytes can be used directly as the seed, or additional bytes can be added to the second number of bytes to form the seed.

[0133] S202. Determine the mask address based on the kernel's first-level page table granularity and the second value range.

[0134] The mask address mentioned above is used to characterize the kernel's first-level page table granularity, as well as the second value range.

[0135] For example, assuming the kernel's first-level page table granularity is 2M and the second value range is [0, 1G / 2], then mask = 0x0FE00000. Here, "00000" on the right side of the mask value indicates that the kernel's first-level page table granularity is 2M, and "0FE" limits the second value range to [0, 1G / 2]. The specific method for obtaining the mask based on the kernel's first-level page table granularity and the second value range can refer to existing technologies and will not be elaborated here.

[0136] S203. Perform a bitwise AND operation between the mask address and the seed to obtain a random offset address.

[0137] For example, let's take the seed as a character representation using hexadecimal:

[0138] Assuming the seed is 0x1AD7AFBF and the mask is 0x0FE00000, then 0x1AD7AFBF&0x0FE00000=0xAC00000, meaning the random offset address is 0xAC00000.

[0139] In this implementation, selecting a second number of bytes from a random number and then using these bytes to construct a random offset address further enhances the randomness of the generated offset address, making it more difficult for attackers to obtain it and improving the security of the operating system kernel. Furthermore, based on the kernel's first-level page table granularity and the second value range, a mask address is determined; then, this mask address is used to limit the obtained random offset address, ensuring that the resulting random offset address meets the preset granularity and value range requirements.

[0140] After obtaining the actual virtual address of the kernel, the kernel can be loaded into that virtual address. When running the kernel, it is necessary to locate the virtual addresses of the symbols recorded in the GOT table within the kernel to reference the symbols required for kernel operation, thus enabling the kernel to run smoothly. However, the addresses in the GOT table are virtual addresses specified during kernel compilation, while in this application, the kernel's running address has undergone a random offset. Therefore, to ensure the smooth operation of the kernel, one possible implementation is to relocate the addresses of the symbols in the GOT table during kernel startup.

[0141] To achieve this goal, the kernel involved in this application can set a first code segment in the code during the development phase, that is, when writing the kernel code. This first code segment stores the description information of the symbols to be relocated in the global offset table.

[0142] The first code segment mentioned above can be a code segment originally included in the kernel, such as the rela.dyn segment, or it can be another code segment added to the kernel; this application does not limit its scope. The above description information includes the position and type of the symbol to be relocated in the global offset table. Based on the above description information, the link address of the symbol to be relocated can be found in the global offset table.

[0143] Accordingly, the following describes how the kernel runs in the second memory space corresponding to the actual virtual address of the kernel in the above embodiments, i.e., step S105 in the above embodiments. Figure 4 A flowchart illustrating the fourth kernel boot method provided in this application is shown below. Figure 4 As shown, the following steps may be included:

[0144] S301. Obtain the description information of the symbol to be relocated in the global offset table from the first code segment.

[0145] The aforementioned first code segment may be scrambled or unscrambled. As one possible implementation, the first code segment is scrambled after the kernel is compiled into an executable file. This scrambling may involve scrambling only the description information of the symbols to be relocated in the first code segment, or it may involve scrambling other content in the first code segment, including the description information of the symbols to be relocated. This application does not limit the method of scrambling the first code segment. For example, the scrambling method may be to encrypt the first code segment using an encryption algorithm, or to add other characters to the code sections in the first code segment that require scrambling.

[0146] When the first code segment is an unscrambled code segment, the description information of the symbol to be relocated can be obtained as follows: Since the header information of the executable file includes the position of the first code segment within the executable file, the first code segment can be accurately located based on the header information of the kernel executable file. Since the code structure in the first code segment is known, the position of the symbol to be relocated can be found based on the code structure of the first code segment, and thus the description information of the symbol to be relocated can be obtained.

[0147] If the first code segment has been scrambled, the following method can be used to obtain the description information of the information to be relocated in the first code segment.

[0148] First, the first code segment is descrambled. Then, the description information of the symbol to be relocated in the global offset table is obtained from the descrambled first code segment.

[0149] The descrambling method described above corresponds to the descrambling method used for the first code segment. After descrambling the first code segment, the description information of the symbol to be relocated in the global offset table can be obtained by referring to the above implementation method for obtaining the description information after scrambling.

[0150] The above methods can further ensure the security of the description information of the symbol to be relocated. Even if an attacker obtains the description information of the scrambled symbol to be relocated, they cannot easily obtain the description information of the descrambled symbol to be relocated, thus preventing attackers from modifying important information in the global offset table and improving system security.

[0151] S302. Based on the description information of the symbol to be relocated in the global offset table and the random offset address, perform relocation processing on the link address of the symbol to be relocated in the global offset table to obtain the processed global offset table.

[0152] Since the global offset table records the link addresses of relocation symbols, after obtaining the description information of the symbol to be relocated from the first code segment above, the position of the symbol to be relocated in the global offset table can be found, and then the link address of the symbol can be obtained.

[0153] In this step, referring to the method in the above embodiment of obtaining the actual virtual address of the kernel based on the link address and the random offset address, the link address of the symbol to be relocated in the global offset table is relocated.

[0154] Taking the kernel's actual virtual address as the sum of the link address and the random offset address as an example, the link address of the symbol to be relocated can be obtained from the global offset table based on the description information of the symbol to be relocated. Then, the link address of the symbol to be relocated is added to the random offset address to obtain the link address after symbol relocation processing. Next, the link address after symbol relocation processing is updated in the global offset table to obtain the processed global offset table.

[0155] For example, the link address of the symbol to be relocated is 0xFFFFFFFFA000123A, and the random offset address is 0xAC00000. The virtual address of the symbol after relocation is 0xFFFFFFFFAAC0123A = 0xFFFFFFFFA000123A + 0xAC00000.

[0156] After relocating all symbols to be relocated in the global offset table, the relocated virtual addresses of all symbols to be relocated are used to replace the unrelocated link addresses, or the relocated virtual addresses are directly added to the GOT table as new content to update the GOT table and obtain the processed global offset table.

[0157] S303. Based on the processed global offset table, run the kernel in the second memory space corresponding to the actual virtual address of the kernel.

[0158] In this step, when the kernel is loaded into the second memory space corresponding to the actual virtual address and is running, if it needs to reference a symbol in the global offset table during operation, the symbol can be obtained according to the address of the symbol to be referenced in the processed global offset table to meet the requirements for normal kernel operation.

[0159] In this embodiment, the description information of the symbol to be relocated in the global offset table is saved to the first code segment. Subsequently, the symbol to be relocated in the global offset table can be corrected based on the description information of the symbol to be relocated in the first code segment. Using this method, symbol relocation can be completed by adding only a small amount of segment information (i.e., only adding description information about the symbol to be relocated to the first code segment). This reduces the size of the compiled kernel, saves storage space, and improves the kernel's running speed.

[0160] The above embodiments illustrate how to load the kernel of a trusted operating system into an actual virtual address for execution. The following describes how to handle exceptions that occur during the kernel's operation. Figure 5 A flowchart illustrating the fifth kernel boot method provided in this application is shown below. Figure 5 As shown, it includes the following steps:

[0161] S401. Using the key in the one-time programmable memory and the identifier of the one-time programmable memory, generate an encryption key.

[0162] The aforementioned one-time programmable memory can be, for example, an electrically programmed fuse (eFuse). Information recorded in the one-time programmable memory cannot be changed or erased again. This one-time programmable memory resides in a chip within an electronic device on which a trusted operating system is deployed; this chip can be, for example, a CPU chip.

[0163] The aforementioned key can be a preset key stored in a one-time programmable memory.

[0164] The identifier for the aforementioned one-time programmable memory may be, for example, the serial number of the chip containing the one-time programmable memory, an identity document (ID), etc. This application does not limit its use.

[0165] As one possible implementation, an encryption key is generated using an encryption algorithm by utilizing a key stored in a one-time programmable memory and the identifier of the one-time programmable memory. The encryption algorithm can be a hash algorithm or other algorithms, and this application does not limit its application. The method for generating the encryption key using the encryption algorithm described above can refer to existing technologies, and this application does not limit its application.

[0166] S402. Use the encryption key to encrypt the target data to obtain the encrypted target data.

[0167] The target data mentioned above includes: random numbers and / or random offset addresses.

[0168] Based on the above embodiments, since a random offset address can be obtained from a random number, in this embodiment, the target data may only include a random number. If a random offset address is needed later, it can be obtained from the random number. Alternatively, the target data may only include a random offset address. Or, the target data may include both a random number and a random offset address. When using the random offset address later, a random offset address can be generated from the random number and verified against the recorded random offset address to ensure the accuracy of the obtained random offset address.

[0169] As one possible implementation, the target data is encrypted using a symmetric encryption algorithm and the aforementioned encryption key to obtain the encrypted target data. Specifically, the implementation method for encrypting the target data using a symmetric algorithm and encryption key can refer to existing technologies and will not be elaborated upon here.

[0170] S403. Store the encrypted target data and the identifier of the one-time programmable memory into the kernel's read-only code segment.

[0171] The aforementioned read-only code segment can be an existing read-only code segment in the kernel executable file, such as the rodata segment, or it can be another newly added code segment. This application does not limit it.

[0172] In this step, the encrypted target data, along with the identifier of the one-time programmable memory, is stored in the kernel's read-only code segment. This prevents the encrypted target data from being accidentally tampered with. This ensures that when a kernel malfunctions, the target data stored in this read-only code segment can be accurately retrieved, and the precise address of the kernel's execution can be determined based on this data, facilitating debugging of the malfunctioning kernel.

[0173] Optionally, the target data and the identifier of the one-time programmable memory can be stored at the beginning of the read-only code segment for later retrieval.

[0174] It should be noted that the execution order of this embodiment is not different from the execution order of relocating the GOT table in the above embodiments, and this application does not limit it.

[0175] In this embodiment, an encryption key is generated using the key in the one-time programmable memory and the identifier of the one-time programmable memory. Then, the target data is encrypted using the encryption key to obtain encrypted target data. This target data includes a random number and / or a random offset address. Through the above operations, the target data is scrambled, reducing the risk of the target data being exposed externally and improving system security. In addition, in this embodiment, the encrypted target data and the identifier of the one-time programmable memory are stored in a read-only code segment, preventing the above-mentioned important information from being accidentally tampered with. This allows the target data to be accurately obtained when kernel operation encounters an anomaly, enabling debugging of the kernel anomaly and improving system operational stability.

[0176] When a trusted operating system kernel malfunctions, debugging tools can be used for debugging. Since commonly used debugging tools employ link addresses, it's necessary to obtain the link address based on a random offset address and the actual virtual address, and then use the debugging tool to perform debugging based on that link address. Figure 6 A flowchart illustrating the sixth kernel boot method provided in this application is shown below. Figure 6 As shown, it includes the following steps:

[0177] S501: When a kernel exception occurs, obtain the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address.

[0178] Based on the above embodiments, since the encrypted target data and the identifier of the one-time programmable memory are stored in the read-only code segment, this step retrieves the encrypted target data and the identifier of the one-time programmable memory when a kernel exception occurs. Simultaneously, the actual virtual address of the kernel is obtained. In this step, since the behavior when a kernel exception occurs may differ—sometimes the trusted operating system kernel's runtime log is output, and sometimes it is not—there are two possibilities depending on whether a runtime log exists when a kernel exception occurs:

[0179] Scenario 1: Run logs exist.

[0180] In this case, since there is an operation log, the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address in the above embodiment can be printed directly in the output information of the operation log.

[0181] Case 2: No runtime log exists.

[0182] In this scenario, since there is no runtime log, the aforementioned information cannot be directly obtained from it. Instead, the physical start address of the read-only code segment can be accessed to obtain the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address.

[0183] As one possible implementation, a debugging tool (e.g., trace32) is used to access the physical start address of the kernel's read-only code segment (e.g., the rodata segment) to obtain the encrypted target data and the identifier of the one-time programmable memory. The actual virtual address is then obtained using the same debugging tool. The specific methods for obtaining the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address using the debugging tool are relevant to existing technologies and will not be elaborated upon here. This application does not limit the methods used to obtain the encrypted target data, the one-time programmable memory identifier, and the actual virtual address after accessing the physical start address of the read-only code segment.

[0184] S502. Using the key and the identifier of the one-time programmable memory, generate an encryption key.

[0185] The aforementioned key is the preset key in the one-time programmable memory.

[0186] As one possible implementation, the kernel of the trusted operating system stores the aforementioned key in the electronic device on which it is deployed. When an exception occurs during kernel operation, the CPU automatically retrieves the key and, based on the identifier of the one-time programmable memory, generates an encryption key using the same method as in the above embodiments. For example, if a digest algorithm is used to generate the encryption key in the above embodiments, the same digest algorithm is used in this step to generate the same encryption key.

[0187] As another possible implementation, when an exception occurs during kernel operation, the CPU obtains the key input by the user as an instruction, and then obtains the encryption key in the same way as in the above embodiment based on the instruction.

[0188] In this implementation, since the preset key can only be known by the user who set the key, it can be ensured that the encryption key cannot be obtained by attackers, thus improving the security of kernel operation.

[0189] S503. Use the encryption key to decrypt the encrypted target data to obtain the target data.

[0190] Since the above embodiments use a symmetric encryption algorithm and encryption key to encrypt the target data, the encrypted target data can be decrypted by using the same encryption algorithm and the same encryption key.

[0191] S504: Using the target data and the actual virtual address, obtain the kernel's link address.

[0192] In this step, a random offset address is obtained based on the target data. For example, if the target data is a random number, the random offset address is obtained using the same method as in the above embodiments. Then, the link address is obtained by reverse engineering, referring to the method used in the above embodiments to obtain the actual virtual address based on the link address and the random offset address.

[0193] For example, assuming the actual virtual address = link address + random offset address, then we can conclude that the link address = actual virtual address - random offset address.

[0194] S505 processes the kernel based on its link address.

[0195] Since debug tools typically use the link address as the actual runtime address, once the kernel's link address is obtained, debug tools can be used to process the kernel. Specific implementation methods can be found in existing technologies and will not be elaborated upon here.

[0196] In this embodiment, because the kernel uses a random offset address to process the link address during kernel startup, the kernel runs in the actual virtual address. However, when kernel operation encounters an error, commonly used debugging tools often use the link address for debugging. Therefore, in this embodiment, the encrypted target data and the identifier of the one-time programmable memory are obtained, and then the target data is decrypted according to the encryption method described in the previous embodiment. The actual virtual address of the kernel is obtained, and the link address of the kernel is further obtained based on the actual virtual address and the target data. Then, the kernel is processed according to the link address. Through the above method, the security of kernel operation is ensured. On the other hand, when the kernel needs to be debugged, the link address can be obtained based on the encrypted target data pre-existing in the read-only code segment and the identifier of the one-time programmable memory to implement the debugging operation, further ensuring the safe and stable operation of the kernel.

[0197] This application also provides a kernel boot device, which is applied to an electronic device running a trusted operating system, wherein the kernel of the trusted operating system is a position-independent executable program. Figure 7 This is a schematic diagram of a kernel boot device provided in this application. Figure 7 As shown, the kernel boot device includes: a receiving module 11, a generating module 12, a storage module 13, a reading module 14, a first acquisition module 15, a second acquisition module 16, and a running module 17. Optionally, the kernel boot device may also include, for example, the following modules: an encryption module 18 and a processing module 19.

[0198] Receiver module 11 is used to receive power-on commands;

[0199] Generation module 12 is used to generate random numbers in response to the power-on command;

[0200] Storage module 13 is used to store the random number into a first memory space; the first memory space is a hardware-isolated and protected memory space;

[0201] Reading module 14 is used to read the random number from the first memory space when the kernel is started;

[0202] The first acquisition module 15 is used to acquire a random offset address based on the random number;

[0203] The second acquisition module 16 is used to acquire the actual virtual address of the kernel based on the random offset address and the kernel's link address; the random offset address is within a first value range, the link address is within a second value range, the sum of the maximum value of the first value range and the maximum value of the second value range is less than or equal to the maximum value of the kernel's virtual address space, and the sum of the minimum value of the first value range and the minimum value of the second value range is greater than or equal to the minimum value of the virtual address space;

[0204] The execution module 17 is used to run the kernel in the second memory space corresponding to the actual virtual address of the kernel.

[0205] As one possible implementation, the random number includes a first number of bytes; the first acquisition module 15 is specifically used to select a second number of bytes from the random number to form a seed for generating the random offset address; determine the mask address based on the kernel's first-level page table granularity and the second value range; and perform a bitwise AND operation between the mask address and the seed to obtain the random offset address. The second number is less than the first number.

[0206] In one possible implementation, the kernel includes a global offset table and a first code segment, which stores description information of symbols to be relocated in the global offset table. In this implementation, the execution module 17 is specifically configured to obtain the description information of the symbols to be relocated in the global offset table from the first code segment; perform relocation processing on the link addresses of the symbols to be relocated in the global offset table based on the description information of the symbols to be relocated in the global offset table and the random offset address, to obtain a processed global offset table; and run the kernel in the second memory space corresponding to the actual virtual address of the kernel based on the processed global offset table.

[0207] For example, the first code segment is a code segment that has been scrambled; the running module 17 is specifically used to descramble the first code segment; and to obtain the description information of the symbol to be relocated in the global offset table from the descrambled first code segment.

[0208] In this example, the execution module 17 is specifically used to obtain the link address of the symbol to be relocated from the global offset table according to the description information of the symbol to be relocated in the global offset table; add the link address of the symbol to be relocated to the random offset address to obtain the link address after the symbol relocation processing; and update the link address after the symbol relocation processing to the global offset table to obtain the processed global offset table.

[0209] As one possible implementation, the generation module 12 is also used to generate an encryption key using a key in a one-time programmable memory and an identifier of the one-time programmable memory;

[0210] Encryption module 18 is used to encrypt target data using an encryption key to obtain encrypted target data; the target data includes: the random number and / or the random offset address;

[0211] The storage module 13 is also used to store the encrypted target data and the identifier of the one-time programmable memory into the read-only code segment of the kernel.

[0212] As one possible implementation, the first acquisition module 15 is also used to acquire the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address when the kernel encounters an exception;

[0213] The generation module 12 is further configured to generate the encryption key using the key and the identifier of the one-time programmable memory;

[0214] The encryption module 18 is also used to decrypt the encrypted target data using the encryption key to obtain the target data;

[0215] The first acquisition module 15 is further configured to use the target data and the actual virtual address to acquire the link address of the kernel;

[0216] Processing module 19 is used to process the kernel according to the kernel's link address.

[0217] As one possible implementation, the second acquisition module 16 is specifically used to determine whether the kernel's runtime log exists; if the runtime log exists, the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address are printed in the output information of the runtime log; if the runtime log does not exist, the physical start address of the read-only code segment is accessed to obtain the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address.

[0218] The kernel boot device provided in this application embodiment can execute the kernel boot method in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0219] It should be noted that the above Figure 7 The division of modules shown is merely illustrative. This application does not limit the division of modules or the naming of modules.

[0220] Figure 8 This is a schematic diagram of the structure of an electronic device 110 provided in this application. Figure 8 As shown, the electronic device may include at least one processor 111 and a memory 112.

[0221] The memory 112 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0222] The memory 112 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0223] The processor 111 is used to execute computer execution instructions stored in the memory 112 to implement the kernel boot method described in the foregoing method embodiments. The processor 111 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0224] The electronic device 110 may also include a communication interface 113, through which it can communicate and interact with external devices, such as user terminals (e.g., mobile phones, tablets). In specific implementations, if the communication interface 113, memory 112, and processor 111 are implemented independently, they can be interconnected via a bus to complete communication. 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., but this does not imply that there is only one bus or one type of bus.

[0225] Optionally, in a specific implementation, if the communication interface 113, memory 112, and processor 111 are integrated on a single chip, then the communication interface 113, memory 112, and processor 111 can communicate through an internal interface.

[0226] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used for the kernel booting method in the above embodiments.

[0227] This application also provides a computer program product including executable instructions stored in a readable storage medium. At least one processor of an electronic device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the electronic device to implement the kernel boot methods provided in the various embodiments described above.

[0228] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0229] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A kernel boot method, characterized in that, The method is applied to an electronic device running a trusted operating system, wherein the kernel of the trusted operating system is a position-independent executable program, and the trusted operating system refers to an operating system running in a trusted execution environment. The method includes: Receive power-on command; In response to the power-on command, a random number is generated and stored in a first memory space; the first memory space is a hardware-isolated and protected memory space and is configured to be accessible only by programs running in a trusted execution environment; When the kernel is started, the random number is read from the first memory space, and a random offset address is obtained based on the random number; The actual virtual address of the kernel is obtained based on the random offset address and the kernel's link address; the random offset address is within a first value range, the link address is within a second value range, the sum of the maximum value of the first value range and the maximum value of the second value range is less than or equal to the maximum value of the kernel's virtual address space, and the sum of the minimum value of the first value range and the minimum value of the second value range is greater than or equal to the minimum value of the virtual address space; The kernel runs in the second memory space corresponding to the actual virtual address of the kernel. The random number includes a first number of bytes; obtaining the random offset address based on the random number includes: A second number of bytes are selected from the random numbers to form a seed for generating the random offset address, wherein the second number is less than the first number; The mask address is determined based on the kernel's first-level page table granularity and the second value range. The random offset address is obtained by performing a bitwise AND operation between the mask address and the seed.

2. The method according to claim 1, characterized in that, The kernel includes a global offset table and a first code segment, which stores description information of the symbols to be relocated in the global offset table. Running the kernel in the second memory space corresponding to the actual virtual address of the kernel includes: Obtain the description information of the symbol to be relocated in the global offset table from the first code segment; Based on the description information of the symbol to be relocated in the global offset table and the random offset address, the link address of the symbol to be relocated in the global offset table is relocated to obtain the processed global offset table. The kernel runs in the second memory space corresponding to the actual virtual address of the kernel, based on the processed global offset table.

3. The method according to claim 2, characterized in that, The first code segment is a code segment that has been scrambled; The step of obtaining the description information of the symbol to be relocated in the global offset table from the first code segment includes: The first code segment is descrambled; The description information of the symbol to be relocated in the global offset table is obtained from the first code segment after descrambling.

4. The method according to claim 2 or 3, characterized in that, The step of relocating the link addresses of the symbols to be relocated in the global offset table based on the description information of the symbols to be relocated in the global offset table and the random offset address, to obtain a processed global offset table, includes: Based on the description information of the symbol to be relocated in the global offset table, obtain the link address of the symbol to be relocated from the global offset table; Add the link address of the symbol to be relocated to the random offset address to obtain the link address after the symbol relocation process; The link address after symbol relocation is updated in the global offset table to obtain the processed global offset table.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: An encryption key is generated using the key stored in the one-time programmable memory and the identifier of the one-time programmable memory; The target data is encrypted using an encryption key to obtain encrypted target data; the target data includes: the random number and / or the random offset address; The encrypted target data, along with the identifier of the one-time programmable memory, is stored in the read-only code segment of the kernel.

6. The method according to claim 5, characterized in that, The method further includes: When the kernel encounters an anomaly, the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address are obtained. The encryption key is generated using the key and the identifier of the one-time programmable memory; The encrypted target data is decrypted using the encryption key to obtain the target data. Using the target data and the actual virtual address, the link address of the kernel is obtained; The kernel is processed according to its link address.

7. The method according to claim 6, characterized in that, The step of obtaining the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address includes: Determine if the kernel's runtime log exists; If the operation log exists, then print the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address in the output information of the operation log; If the runtime log does not exist, the physical start address of the read-only code segment is accessed to obtain the encrypted target data, the identifier of the one-time programmable memory, and the actual virtual address.

8. A kernel boot device, characterized in that, The device is applied to an electronic device running a trusted operating system, wherein the kernel of the trusted operating system is a position-independent executable program, and the trusted operating system refers to an operating system running in a trusted execution environment. The device includes: The receiving module is used to receive the power-on command; The generation module is used to generate random numbers in response to the power-on command; A storage module is used to store the random number into a first memory space; the first memory space is a hardware-isolated and protected memory space, and is configured to be accessible only by programs running in a trusted execution environment; A reading module is used to read the random number from the first memory space when the kernel is started; The first acquisition module is used to acquire a random offset address based on the random number; The second acquisition module is used to acquire the actual virtual address of the kernel based on the random offset address and the kernel's link address; the random offset address is within a first value range, the link address is within a second value range, the sum of the maximum value of the first value range and the maximum value of the second value range is less than or equal to the maximum value of the kernel's virtual address space, and the sum of the minimum value of the first value range and the minimum value of the second value range is greater than or equal to the minimum value of the virtual address space; A runtime module, used to run the kernel in the second memory space corresponding to the actual virtual address of the kernel; The random number includes a first number of bytes; the first acquisition module is specifically used for: A second number of bytes are selected from the random numbers to form a seed for generating the random offset address, wherein the second number is less than the first number; The mask address is determined based on the kernel's first-level page table granularity and the second value range. The random offset address is obtained by performing a bitwise AND operation between the mask address and the seed.

9. An electronic device, characterized in that, The electronic device runs a trusted operating system, the kernel of which is a position-independent executable program. The electronic device includes a processor and a memory communicatively connected to the processor. The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, 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 to 7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 7.

Images