CN115544516A

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

Info

Publication number: CN115544516A
Application number: CN202211131115.5A
Authority: CN
Inventors: 朱站清; 曲洪丽
Original assignee: Beijing Ziguang Zhanrui Communication Technology Co Ltd
Current assignee: Beijing Ziguang Zhanrui Communication Technology Co Ltd
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2022-12-30

Abstract

The application provides a kernel starting method, a kernel starting device, electronic equipment, a storage medium and a program product. The method is applied to the electronic equipment running with a trusted operating system, wherein the kernel of the trusted operating system is an executable program independent of the position, and the method comprises the following steps: receiving a starting-up instruction; responding to the starting instruction, generating a random number, and storing the random number into a first memory space; the first memory space is a memory space with hardware isolation protection; when the kernel is started, reading the random number from the first memory space, and acquiring a random offset address according to the random number; acquiring an actual virtual address of the kernel according to the random offset address and a link address of the kernel; and operating the kernel in a second memory space corresponding to the actual virtual address of the kernel. The method improves the running safety of the trusted operating system.

Description

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

Technical Field

The present application relates to operating system technologies, and in particular, to a kernel booting method and apparatus, an electronic device, a storage medium, and a program product.

Background

The kernel is a basic component of the Linux operating system, is a first-layer software extension based on hardware, provides the most basic functions of the operating system, such as managing processes, memories, device drivers and the like of the system, and determines the performance and stability of the system. In order to ensure that multiple executable files can be run simultaneously, avoid mutual influence of different executable files in the execution process, and increase the running speed, the executable files need to be loaded to the virtual memory corresponding to the virtual address for running, rather than being directly loaded to the physical memory corresponding to the physical address for running. Similarly, when a kernel compiled into an executable file is to be run, it needs to be loaded into a virtual memory corresponding to a virtual address for running.

In the prior art, when compiling a kernel of a Linux operating system, the kernel is compiled and linked by a fixed link address, so that the kernel is loaded to a virtual memory corresponding to the fixed virtual address to run when being started.

However, if the kernel of the operating system runs according to the fixed virtual address, an attacker can easily acquire the running address of the kernel (i.e. the fixed virtual address) through buffer overflow attack, and further, the stable running of the kernel of the operating system is damaged, and the running safety of the operating system is reduced.

Disclosure of Invention

The application provides a kernel starting method, a kernel starting device, electronic equipment, a storage medium and a program product, which are used for solving the problem of low security in the running process of a trusted operating system.

In a first aspect, the present application provides a kernel booting method, where the method is applied to an electronic device running a trusted operating system, where a kernel of the trusted operating system is a location-independent executable program, and the method includes:

receiving a starting-up instruction;

responding to the starting instruction, generating a random number, and storing the random number into a first memory space; the first memory space is a memory space with hardware isolation protection;

when the kernel is started, reading the random number from the first memory space, and acquiring a random offset address according to the random number;

acquiring an actual virtual address of the kernel according to the random offset address and a link address of the kernel; the random offset address is located in a first value range, the link address is located in 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 smaller than or equal to the maximum value of the virtual address space of the kernel, and the sum of the minimum value of the first value range and the minimum value of the second value range is larger than or equal to the minimum value of the virtual address space;

and operating the kernel in a second memory space corresponding to the actual virtual address of the kernel.

Optionally, the random number includes a first number of bytes; the obtaining a random offset address according to the random number includes:

selecting a second number of bytes from the random number to form a seed for generating the random offset address, the second number being less than the first number;

determining a mask address according to the first-level page table granularity of the kernel and the second value range;

and operating the mask address and the seed to obtain the random offset address.

Optionally, the kernel includes a global offset table and a first code segment, where the first code segment stores description information of a symbol to be relocated in the global offset table;

the operating the kernel in a second memory space corresponding to the actual virtual address of the kernel includes:

obtaining description information of a symbol to be relocated in the global offset table from the first code segment;

according to the description information of the symbol to be relocated in the global offset table and the random offset address, relocating the link address of the symbol to be relocated in the global offset table to obtain a processed global offset table;

and operating the kernel in a second memory space corresponding to the actual virtual address of the kernel according to the processed global offset table.

Optionally, the first code segment is a code segment after scrambling;

the obtaining the description information of the symbol to be relocated in the global offset table from the first code segment includes:

descrambling the first code segment;

and acquiring the description information of the symbol to be relocated in the global offset table from the first code segment after descrambling processing.

Optionally, the relocating, according to 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 to obtain a processed global offset table, including:

acquiring a link address of a 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;

adding the link address of the symbol to be relocated and the random offset address to obtain the link address after the symbol relocation;

and updating the link address after the symbol relocation processing into the global offset table to obtain the processed global offset table.

Optionally, the method further includes:

generating an encryption key by using a key in a one-time programmable memory and an identifier of the one-time programmable memory;

encrypting the target data by using the encryption key to obtain encrypted target data; the target data includes: the random number and/or the random offset address;

and storing the encrypted target data and the identifier of the one-time programmable memory to a read-only code segment of the kernel.

Optionally, the method further includes:

when the kernel is abnormal, acquiring the encrypted target data, the identifier of the one-time programmable memory and the actual virtual address;

generating the encryption key by using the key and the identification of the one-time programmable memory;

decrypting the encrypted target data by using the encryption key to obtain the target data;

acquiring a link address of the kernel by using the target data and the actual virtual address;

and processing the kernel according to the link address of the kernel.

Optionally, the obtaining the encrypted target data, the identifier of the otp memory, and the actual virtual address includes:

determining whether a running log of the kernel exists;

if the running log exists, printing the encrypted target data, the identifier of the one-time programmable memory and the actual virtual address in output information of the running log;

and if the running log does not exist, accessing the physical starting address of the read-only code segment to acquire the encrypted target data and the identifier of the one-time programmable memory and acquire the actual virtual address.

In a second aspect, the present application further provides a kernel boot apparatus, where the apparatus is applied to an electronic device running a trusted operating system, a kernel of the trusted operating system is a location-independent executable program, and the apparatus includes:

the receiving module is used for receiving a starting instruction;

the generating module is used for responding to the starting instruction and generating a random number;

the storage module is used for storing the random number into a first memory space; the first memory space is a memory space with hardware isolation protection;

a reading module, configured to read the random number from the first memory space when the kernel is started;

the first acquisition module is used for acquiring a random offset address according to the random number;

a second obtaining module, configured to obtain an actual virtual address of the kernel according to the random offset address and a link address of the kernel; the random offset address is located in a first value range, the link address is located in 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 smaller than or equal to the maximum value of the virtual address space of the kernel, and the sum of the minimum value of the first value range and the minimum value of the second value range is larger than or equal to the minimum value of the virtual address space;

and the running module is used for running the kernel in a second memory space corresponding to the actual virtual address of the kernel.

In a third aspect, the present application provides an electronic device, where the electronic device runs a trusted operating system, and a kernel of the trusted operating system is a location-independent executable program, and the electronic device includes: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any of the first aspects.

In a fourth aspect, the present application provides a computer-readable storage medium having stored thereon computer-executable instructions for implementing the method according to any one of the first aspect when executed by a processor.

In a fifth aspect, the present application provides a computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of the first aspect.

In a sixth aspect, the present application provides a chip having a computer program stored thereon, which, when executed by the chip, implements the method according to any of the first aspects.

According to the kernel starting method, the kernel starting device, the electronic equipment, the storage medium and the program product, by adopting an address space layout randomization technology, a random number is generated firstly, then the random number is stored in a memory with hardware isolation protection, then the random number is obtained before the kernel is started, and a random offset address is generated according to the random number, so that the kernel of the trusted operating system runs at an actual virtual address generated according to the random offset address. By the method, the running safety of the trusted operating system kernel is improved.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.

Fig. 1 is a schematic flowchart of a first kernel booting method provided in the present application;

fig. 2 is a schematic flowchart of a second kernel booting method provided in the present application;

fig. 3 is a schematic flowchart of a third kernel booting method provided in the present application;

fig. 4 is a schematic flowchart of a fourth kernel booting method provided in the present application;

fig. 5 is a schematic flowchart of a fifth kernel booting method provided in the present application;

fig. 6 is a schematic flowchart of a sixth kernel boot method provided in the present application;

fig. 7 is a schematic structural diagram of a kernel boot apparatus provided in the present application;

fig. 8 is a schematic structural diagram of an electronic device 110 provided in the present application.

With the above figures, there are shown specific embodiments of the present application, which will be described in more detail below. These drawings and written description are not intended to limit the scope of the inventive concepts in any manner, but rather to illustrate the inventive concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terms referred to in this application are explained first:

trusted Execution Environment (TEE): the trusted operating environment is isolated from the untrusted operating environment, so that a privileged attacker who can control an operating system and a Basic Input Output System (BIOS) cannot extract or tamper with data in the TEE.

Hardware isolation technology: the hardware protected by the hardware isolation technology can ensure the security of data inside the hardware, and the hardware protected by the hardware isolation technology can limit that only the executable file running in the TEE can access the hardware protected by the hardware isolation technology to acquire the data in the hardware.

The trusted operating system: refers to the operating system running in the TEE.

Global Offset Table (GOT): is a table for positioning symbols (namely global variables and functions) in the running process of an executable file in the Linux operating system. The table stores link addresses for symbolic operations.

The link address is as follows: when compiling code into an executable program, a virtual address of the executable program when running in the virtual memory is specified, and the specified virtual address is a link address.

The kernel is a basic component of the Linux operating system, is a first-layer software extension based on hardware, provides the most basic functions of the operating system, such as managing processes, memories, device drivers and the like of the system, and determines the performance and stability of the system. In order to ensure that a plurality of executable files can be run simultaneously, avoid mutual influence of different executable files in the execution process, and accelerate the running speed, the executable files need to be loaded into the virtual memory space corresponding to the virtual address to run, but not directly loaded into the physical memory corresponding to the physical address to run. Similarly, when a kernel compiled into an executable file is to be run, it needs to be loaded into a virtual memory corresponding to a virtual address for running.

In the prior art, when compiling a kernel of a Linux operating system, the kernel is compiled and linked with a fixed link address, so that when an electronic device with the Linux operating system is started up, the kernel is loaded to a virtual memory corresponding to the link address to run, and data and programs in the kernel also run according to the fixed link address.

The buffer overflow attack is an attack action performed by using a buffer overflow bug, and whether the buffer overflow attack succeeds or not is closely related to whether an attacker can guess a running address of a kernel in a memory or not. When the kernel of the operating system runs according to the fixed virtual address, the memory layout of the kernel is transparent for an attacker, so the attacker can easily attack the kernel running in the virtual memory space corresponding to the fixed virtual address through buffer overflow attack, and further the stable running of the operating system is damaged.

In the prior art, an Address Space Layout Randomization (ASLR) technology exists, which can load an executable file into a virtual memory Space corresponding to a randomly generated virtual Address to operate.

The inventor finds that if the kernel of the Linux operating system can run in the virtual memory space corresponding to the randomly generated virtual address, the difficulty of an attacker for acquiring the virtual address where the kernel runs can be improved, so that the attacker cannot attack and damage the running of the operating system through buffer overflow, and the running safety of the operating system is improved.

In view of the above, the present application provides a kernel booting method. Fig. 1 is a schematic flowchart of a first kernel booting method provided in the present application, and as shown in fig. 1, the method generates a random offset address according to a random number by using an ASLR technique, so that a kernel of a Linux operating system runs according to a randomly generated virtual address. By the method, the difficulty of an attacker in acquiring the key data of the kernel and the exact address of the program can be increased, so that the possibility of successful buffer overflow attack is reduced, and the running safety of the kernel of the Linux operating system is improved.

The following describes the technical solutions of the present application and how to solve the above technical problems with specific embodiments. The following several specific embodiments may be combined with each other, and details of the same or similar concepts or processes may not be repeated in some embodiments. Embodiments of the present application will be described below with reference to the accompanying drawings.

The kernel starting method is applied to the electronic equipment running with the trusted operating system. The electronic device may be a mobile phone, a computer, a server, etc., and the application is not limited thereto. The execution main body of the kernel starting method provided by the present application may be a Central Processing Unit (CPU) in the electronic device. The trusted operating system is a Linux system.

In addition, in order to enable the kernel of the trusted operating system to support the kernel to run in the virtual memory space corresponding to the random address, rather than in the virtual memory space corresponding to the fixed virtual address, the kernel of the trusted operating system needs to be configured as a location-independent executable file. An executable file that is not location dependent may be an executable file that runs in any legitimate memory. The present application does not limit the way in which the kernel of the trusted operating system is compiled into a location-independent executable program, and those skilled in the art can set this according to the actual situation. Illustratively, the setting may be made in the following manner:

the kernel of the trusted operating system is compiled using GCC (GNU Compiler Collection). During compilation, an option that can compile the kernel into a location-independent executable program, such as the-fPIE, -pie option, is added to the GCC compilation option. To avoid generating symbols of the R _ AARCH64_ ABS64 type when generating the executable file, a-Bsymbolic linking option is added so that the relocation symbol type generated after linking is R _ AARCH64_ RELATIVE (0 x 403). The above specific compiling method may refer to the prior art, and is not described herein again.

Fig. 2 is a schematic flowchart of a second kernel booting method provided in the present application, and as shown in fig. 2, the method includes the following steps:

s101, receiving a starting instruction.

As a possible implementation manner, the electronic device running with the trusted operating system is configured with a physical key, and the CPU may receive a boot instruction triggered by the physical key.

As another possible implementation manner, after the electronic device running with the trusted operating system is powered on, the CPU may receive a power-on instruction triggered by power-on.

S102, responding to the starting instruction, generating a random number, and storing the random number into a first memory space.

For example, the random number may be generated by the CPU running an execution file for performing an initialization operation when the initialization electronic device operation is performed. Referring to fig. 1, the execution file for executing the initialization operation may be, for example, a Secure loader (Secure loader), and the present application does not limit the code for executing the initialization operation.

Alternatively, the CPU generates the random number by a random number generator after initializing the electronic device. The random number may be a pseudo random number or a true random number, depending on the type of random number generator. Illustratively, the CPU, when performing operations to initialize the electronic device, runs a Secure loader to acquire a random number generated by the random number generator.

The number of bits and the representation mode of the generated random number are related to the implementation mode of obtaining the random offset address based on the random number.

For example, if the generated random number is directly used as the random offset address, the random number needs to satisfy the requirement of the random offset address in the present application. For example, the random numbers need to be represented in the same way as the link addresses, e.g., in hexadecimal notation.

If the random offset address is constructed according to the bytes selected from the random number, the number of bits and the representation of the generated random number are not limited, and those skilled in the art can set the random offset address according to actual situations. Illustratively, the number of bits of the random number may be 64 bits, 256 bits; the random number may be represented in binary, decimal, or hexadecimal characters.

The first memory space is a memory space protected by hardware isolation, and the first memory space is a physical memory. As a possible implementation manner, when configuring an electronic device in which a trusted operating system is located, one or more memories are selected, and the memories are protected by using a hardware isolation technology, so as to obtain a first memory space. The hardware isolation technology can limit an execution program which can read the data in the first memory space. In the application, it may be limited that only the execution program running in the TEE environment can access the first memory space and obtain the data stored therein. The memory selection method may be determined according to actual conditions, and the method is not limited in the present application, and may be, for example, randomly selected.

S103, when the kernel is started, reading a random number from the first memory space, and acquiring a random offset address according to the random number.

The random offset address is expressed in the same manner as the link address. Illustratively, when the link address is represented by hexadecimal characters, the random offset address is also represented by hexadecimal characters; when the link address is represented by binary characters, the random offset address is also represented by binary characters, and so on. For example, the random offset address may be 0xAC00000, represented in hexadecimal characters.

In this step, the trusted operating system kernel runs in the TEE after being started, and has a higher security attribute. In the application, the first memory space protected by the hardware isolation is set to be only accessible and readable by an executive program running in the TEE, so that the kernel of the trusted operating system can read the random number stored in the first memory space when the kernel is started.

The random number is used to generate a random offset address, which plays a critical role in the implementation of the overall scheme. By the method, except the executable file running in the TEE, other programs can not acquire or modify the random number in the first memory space protected by hardware isolation, so that the random number is prevented from being leaked to the outside or being tampered by other programs, and the reliability of the random offset address generated based on the random number at the later stage is ensured.

As a possible implementation, the generated random number is directly used as the random offset address.

As another possible implementation, the random number includes a first number of bytes, a second number of bytes is selected from the random number, and then the random offset address is constructed from the second number of bytes. The second number is smaller than the first number.

And S104, acquiring the actual virtual address of the kernel according to the random offset address and the link address of the kernel.

The random offset address is located in a first value range, the link address is located in 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 smaller than or equal to the maximum value of the virtual address space of the kernel, and the sum of the minimum value of the first value range and the minimum value of the second value range is larger than or equal to the minimum value of the virtual address space.

The virtual address space is a space formed by virtual memories corresponding to preset virtual addresses which can be used for the kernel to run. The size of the virtual address space may be 1G, for example. The first value range refers to the size of the virtual address space occupied by the value range of the random offset address. The second value range refers to the size of the virtual address space occupied by the value range of the link address.

It should be noted that, the size of the virtual address space is not limited in the present application, and specific values of the first value range and the second value range are also not limited, and those skilled in the art can set the values according to actual requirements.

For example, consider that the more random the value of the random offset address is, the more secure the kernel of the operating system is running. And the randomness of the random offset address value is positively correlated with the size of the first value range. Therefore, the range of the virtual address space can be properly expanded, so that the range of the first value can also be properly expanded, and the randomness of the value of the random offset address is enhanced. However, while the virtual address space is expanded, the memory occupied by the page table for storing the mapping relationship between the virtual address and the physical address is also expanded, and the normal operation of the kernel loaded in the virtual address space is affected by the overlarge memory occupied by the page table. Therefore, when compiling the kernel of the operating system, the size of the virtual address space can be properly enlarged by combining two factors, thereby not only ensuring the randomness of the random offset address, but also avoiding the influence on the kernel operation caused by excessive memory occupation of the page table.

For example, taking the virtual address space of the kernel as 1G, the first value range may be [0,1G/2], and the second value range may be [0,1G/2]; alternatively, the first range of values may be [0,2G/3], and the second range of values may be [0,1G/3].

The actual virtual address is a virtual address where the kernel actually operates in the virtual memory.

As a possible implementation manner, the actual virtual address of the kernel is obtained according to the following formula:

real virtual address = link address + random offset address

Illustratively, if the link address is 0 xfffffffa 0000000 and the random offset address is 0xAC00000, then the actual virtual address is 0 xfffffffa 00000.

Under the implementation mode, the kernel level page table granularity and the virtual memory difference value corresponding to the value of the random offset address can be kept consistent. For example, if the granularity of the first-level page table of the core is 1M, the difference between the virtual memories corresponding to two adjacent random offset addresses is also 1M. The virtual memory difference value corresponding to the granularity of the first-level page table of the kernel and the value of the random offset address is not limited.

As another possible implementation, the actual virtual address of the kernel is obtained according to the following formula:

real virtual address = link address + random offset address/2

In this implementation, the kernel's one-level page table granularity and the granularity of the value of "random offset address/2" can be kept consistent.

And S105, operating the kernel in a second memory space corresponding to the actual virtual address of the kernel.

In this step, after the actual virtual address is obtained, the kernel is loaded to the virtual memory corresponding to the actual virtual address, that is, the second memory space, and the kernel is operated. The specific implementation manner may refer to the prior art, and is not described herein again.

In this embodiment, before running the trusted operating system kernel each time, the CPU obtains a random number, and then generates a random offset address according to the random number. Further, the CPU determines an actual virtual address according to the random offset address, so that the trusted operating system kernel runs at the actual virtual address. By the method, the kernel runs at the new randomly generated virtual address every time the kernel is started. Therefore, the difficulty of an attacker in acquiring the kernel running address is improved, and the running safety of the kernel of the operating system is improved.

In addition, in this embodiment, since the kernel of the trusted operating system is compiled into the location-independent executable file, the kernel does not need to be loaded to a fixed running address, but supports running at an arbitrary running address. Therefore, when the space in the memory is insufficient, the virtual address space needs to be enlarged, or the running address of the kernel is adjusted by regenerating the random offset address, the kernel does not need to be recompiled according to the new running address and then issued, and the cost of kernel version maintenance is reduced.

And when the initialization operation is executed, generating a random number, and then storing the random number into the first memory space with hardware isolation protection. Since the first memory space that defines the hardware isolation protection in this application can only be read by the executive running in the TEE environment. In the present application, the trusted operating system kernel is an execution program running in the TEE environment. The random number stored in the first memory space is therefore only readable by the kernel of the executable operating system running in the TEE environment. Because the random offset address is obtained according to the random number, the method can prevent the random number from being obtained and falsified by other executive programs except the random number running in the TEE environment, ensure the randomness of the random number and the random offset address generated according to the random number, and further ensure the system security.

How to obtain the random offset address according to the random number in the above embodiment is explained below. Specifically, there are 2 ways:

mode 1: the generated random number is directly used as the random offset address.

In this implementation, the random number is limited when the random number is generated, so that the generated random number satisfies the requirement of the random offset address in the embodiment. For example, the generated random numbers may be limited to be represented in the same manner as the link addresses, for example, in hexadecimal characters; the number of bytes of the random number may also be limited to 4. Specifically, the generated random number is limited according to the requirement of random offset address in actual use.

By the method, the random offset address can be quickly acquired, namely the random offset address is randomly generated, and the random offset address can be efficiently and quickly acquired.

Mode 2: the random number includes a first number of bytes, a second number of bytes is selected from the random number, and a random offset address is constructed from the second number of bytes.

The manner in which the second number of bytes is selected from the random number is related to the subsequent implementation of the random offset address from the second number of bytes.

As a possible implementation, the second number of bytes may be directly used as the random offset address. This second number of bytes then needs to satisfy the random offset address requirement in this application. The second number of random numbers may be selected by presetting the manner in which the second number of random numbers is selected. Illustratively, the requirement of the application for a random offset address may be met by defining a second number of values.

As another possible implementation manner, fig. 3 is a flowchart illustrating a third kernel booting method provided by the present application, and as shown in fig. 3, the method includes the following steps:

s201, selecting a second number of bytes from the random number according to the random number to form a seed for generating the random offset address.

The manner of selecting the second number of bytes from the random number may be random continuous selection, random unordered selection, or selection according to a preset manner, for example, the 2 nd, 4 th, 6 th, 8 th, and 10 th bytes are preset. The manner in which the second number of bytes is selected from the random number is not limited in this application.

Taking the hexadecimal character representation as an example of the random number, assuming that the random number is CEB4EBB44AF9183F1AD7AFBFC03C1a10E1AD1860FC343B2BD240484E66786a06, 4 consecutive bytes in the random number are randomly selected, which may be 1AD7AFBF, for example.

The manner in which the second number of bytes selected based on the random number constitutes a seed for generating the random offset address is not limited by this application. For example, the second number of bytes may be directly used as the seed, or another byte may be added to the second number of bytes to form the seed.

S202, determining a mask address according to the first-level page table granularity of the kernel and the second value range.

The mask address is used to characterize a first level page table granularity of the kernel, and a second range of values.

For example, assuming that the primary page table granularity of the kernel is 2M, and the second range of values is [0,1G/2], it is determined that mask =0x0FE00000. Wherein the granularity of the first-level page table of the kernel is represented as 2M by '00000' on the right side of the mask value, and the second value range is limited by '0 FE' to be [0,1G/2]. Specifically, the method for obtaining the mask according to the granularity of the first-level page table of the kernel and the second value range may refer to the prior art, and is not described herein again.

And S203, performing AND operation on the mask address and the seed to obtain a random offset address.

Illustratively, taking the seed as a hexadecimal character representation as an example:

assuming that the seed is 0x1AD7AFBF, mask =0x0FE00000, 0x1AD7AFBF &, 0x0FE00000 =0xXC00000, that is, the random offset address is 0xAC00000.

In the implementation mode, a second number of bytes are selected from the random number, and then the random offset address is formed according to the second number of bytes, so that the randomness of the generated random offset address can be further improved, the difficulty of an attacker in obtaining the random offset address is improved, and the running safety of the kernel of the operable system is improved. Determining a mask address according to the granularity of a first-level page table of the kernel and a second value range; and then, the mask address is limited to obtain a random offset address, so that the obtained random offset address can meet the requirements of preset granularity and value range.

After the actual virtual address of the kernel is obtained, the kernel may be loaded to the actual virtual address. When the kernel is operated, the kernel can be operated smoothly only when the address refers to the symbol required by the operation of the kernel according to the virtual address of the symbol recorded in the GOT table in the kernel. However, the addresses in the GOT table are virtual addresses specified when the kernel is compiled, and in the present application, the running addresses of the kernel are randomly offset. Therefore, in order to ensure the smooth operation of the kernel, one possible implementation way is to relocate the addresses of the symbols in the GOT table when the kernel is started.

To achieve this, the kernel referred to in this application, during the development phase, i.e. when writing kernel code, may set a first code segment in the code, where the first code segment holds description information of the symbols to be relocated in the global offset table.

The first code segment may be a code segment originally included in the kernel, for example, a rela.dyn segment, or may be another code segment newly added in the kernel, which is not limited in this application. The description information comprises the position, type and other information of the symbol to be relocated in the global offset table, and the link address of the symbol to be relocated can be found in the global offset table according to the description information.

Accordingly, how to run the kernel in the second memory space corresponding to the actual virtual address of the kernel in the above embodiment, that is, step S105 in the above embodiment, is described below. Fig. 4 is a flowchart illustrating a fourth kernel booting method provided in the present application, and as shown in fig. 4, the method may include the following steps:

s301, obtaining the description information of the symbol to be relocated in the global offset table from the first code segment.

The first code segment may or may not be scrambled. As a possible implementation, after the kernel is compiled to generate the executable file, the first code segment is scrambled. The scrambling process may be to scramble only the description information of the symbol to be relocated in the first code segment, or to scramble other contents of the first code segment including the description information of the symbol to be relocated. The scrambling method is not limited to the way of scrambling the first code segment, and for example, the scrambling method may be to encrypt the first code segment by using an encryption algorithm, or to add other characters to a code that needs to be scrambled in the first code segment.

When the first code segment is a code segment that has not been subjected to scrambling processing, description information of symbols to be relocated can be acquired in the following manner. Because the position of the first code segment in the executable file is included in the information of the file header of the executable file, the first code segment is accurately positioned according to the information of the file header of the executable file of the kernel. Since the code formation in the first code segment is known, the position of the symbol to be relocated is found from the code formation of the first code segment, and the description information of the symbol to be relocated is obtained.

If the first code segment is scrambled, the following method may be used to obtain the description information of the information to be relocated in the first code segment.

First, descrambling processing is performed on the first code segment. Then, the description information of the symbol to be relocated in the global offset table is obtained from the first code segment after the descrambling processing.

The descrambling scheme is a descrambling scheme corresponding to a scheme of scrambling the first code segment. After descrambling the first code segment, the description information of the symbols to be relocated in the global offset table may be obtained with reference to the above-described implementation of obtaining the above description information for the scrambled process.

The security of the description information of the symbol to be relocated can be further ensured by the method. Even if an attacker acquires the description information of the scrambled symbol to be relocated, the description information of the descrambled symbol to be relocated cannot be easily acquired, so that the attacker is prevented from modifying important information in the global offset table, and the system operation safety is improved.

S302, according to 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 a processed global offset table.

Since the link address of the relocation symbol is recorded in the global offset table, after the description information of the symbol to be relocated acquired from the first code segment is obtained, the position of the symbol to be relocated in the global offset table can be found, and the link address of the symbol can be acquired.

In this step, the link address of the symbol to be relocated in the global offset table is relocated with reference to the manner in which the actual virtual address of the kernel is obtained according to the link address and the random offset address in the above embodiment.

Taking the actual virtual address of the kernel 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 according to the description information of the symbol to be relocated in the global offset table. And then adding the link address of the symbol to be relocated and the random offset address to obtain the link address after the symbol relocation processing. And then, updating the link address after the symbol relocation processing into the global offset table to obtain the processed global offset table.

Illustratively, the link address of the symbol to be relocated is 0 xfffffffa 000123A, the random offset address is 0xAC00000, and the post-relocation virtual address of the symbol to be relocated is 0 xfffffffffaaac0123A =0 xfffffffffa 000123a +0xac00000.

After all the symbols to be relocated in the global offset table are relocated, replacing the link addresses which are not relocated with the relocated virtual addresses of all the symbols to be relocated, or directly adding the relocated virtual addresses into the GOT table as new contents to update the GOT table, so as to obtain the processed global offset table.

And S303, running the kernel in a second memory space corresponding to the actual virtual address of the kernel according to the processed global offset table.

In this step, when the kernel is loaded into the second memory space corresponding to the actual virtual address and runs, if a symbol in the global offset table needs to be referred in the running process, the symbol can be obtained according to the address of the symbol to be referred in the processed global offset table, so as to meet the requirement of normal running of the kernel.

In this embodiment, the description information of the symbol to be relocated in the global offset table is stored in the first code segment. Subsequently, the correction of the symbol to be relocated in the global offset table may be implemented according to the description information of the symbol to be relocated in the first code segment. By the above method, relocation of symbols can be done by only adding less segment information (i.e. only adding description information about symbols to be relocated in the first code segment). Therefore, the size of the compiled kernel can be reduced, the storage space is saved, and the running speed of the kernel is increased.

The above embodiment describes how to load the kernel of the trusted operating system to the actual virtual address for operation, and how to handle the kernel when an exception occurs during the operation process. Fig. 5 is a schematic flowchart of a fifth kernel booting method provided in the present application, and as shown in fig. 5, the method includes the following steps:

s401, generating an encryption key by using the key in the one-time programmable memory and the identification of the one-time programmable memory.

The one-time programmable memory may be, for example, an electrically programmable fuse (eFuse). For information recorded into the otp memory, it will not be altered and cleared again. The one-time programmable memory is located in a chip, which may be a CPU chip, in an electronic device deployed by a trusted operating system.

The key may be stored in the otp memory as preset.

The identifier of the otp memory may be, for example, a serial number, an Identity Document (ID), or the like of a chip on which the otp memory is located. This application is not limited thereto.

As a possible implementation, an encryption algorithm is used to generate an encryption key using a key in the otp memory and an identifier of the otp memory. The above encryption algorithm may be a digest algorithm, or may be other algorithms, and the present application does not limit the present invention. The above method for generating an encryption key by using an encryption algorithm may refer to the prior art, and the present application does not limit the method.

S402, encrypting the target data by using the encryption key to obtain the encrypted target data.

The target data includes: a random number and/or a random offset address.

Based on the above embodiment, since the random offset address can be obtained according to the random number, in this embodiment, the target data may only include the random number, and if the random offset address is needed in the later period, the random offset address can be obtained according to the random number; alternatively, the target data may include only random offset addresses; or, the target data may include both the random number and the random offset address, and when the random offset address is used subsequently, the random offset address may be generated according to the random number and verified with the recorded random offset address to ensure the accuracy of the acquired random offset address.

As a possible implementation manner, a symmetric encryption algorithm and the encryption key are used to encrypt the target data, so as to obtain encrypted target data. Specifically, the implementation manner of encrypting the target data by using the symmetric algorithm and the encryption key may refer to the prior art, and is not described herein again.

And S403, storing the encrypted target data and the identifier of the one-time programmable memory to the read-only code segment of the kernel.

The read-only code segment may be an original read-only code segment in the kernel executable file, such as a rodata segment, or may be another newly added code segment, which is not limited in this application.

In this step, the encrypted target data and the identifier of the one-time programmable memory are stored in the read-only code segment of the kernel, so that the encrypted target data can be prevented from being accidentally tampered. Therefore, when the kernel runs abnormally, the target data stored in the read-only code segment can be accurately acquired, the accurate address of the kernel running is determined based on the data, and debugging (debug) processing can be conveniently carried out on the kernel with the abnormal running.

Optionally, the target data and the id of the otp memory may be stored at the beginning of the read-only code segment, so as to facilitate subsequent searching.

It should be noted that, the execution order of this embodiment is not sequential to the execution of relocating the GOT table in the foregoing embodiment, and this application does not limit this.

In the embodiment, an encryption key is generated by using a secret key in the one-time programmable memory and an identifier of the one-time programmable memory; and then, encrypting the target data by using the encryption key to obtain the encrypted target data. The target data includes a random number, and/or a random offset address. Through the operation, the target data are scrambled, the risk of exposing the target data to the outside is reduced, and the system safety is improved. In addition, in the embodiment, the encrypted target data and the identifier of the one-time programmable memory are stored in the read-only code segment, so that the important information is prevented from being accidentally tampered, the target data can be accurately acquired subsequently when the kernel is abnormally operated, the kernel is abnormally debugged, and the system operation stability is improved.

When the operation of the trusted operating system kernel is abnormal, a debug tool can be adopted to perform debug processing. Since the debug processing is performed by using the link address in the debug common tool, the link address needs to be acquired according to the random offset address and the actual virtual address, and then the debug processing is performed by using the debug tool based on the link address. Fig. 6 is a flowchart illustrating a sixth kernel booting method provided in the present application, and as shown in fig. 6, the method includes the following steps:

s501, when the kernel is abnormal, the encrypted target data, the identifier of the one-time programmable memory and the actual virtual address are obtained.

On the basis of the above embodiment, the encrypted target data and the identification of the one-time programmable memory are stored in the read-only code segment. Therefore, in this step, when the kernel is abnormal, the encrypted target data and the identifier of the one-time programmable memory are obtained. Meanwhile, the actual virtual address of the kernel is obtained. In this step, because the performance may be different when the kernel is abnormal in operation, the operation log of the kernel of the trusted operating system may be output sometimes, and the operation log cannot be output sometimes. Therefore, depending on whether or not there is a running log when an exception occurs in the kernel, there are two cases:

case 1: there is a running log.

In this case, since the execution log exists, the encrypted target data, the identification of the otp memory, and the actual virtual address in the above-described embodiment can be directly printed in the output information of the execution log.

Case 2: there is no running log.

In this case, since there is no execution log, the above-described contents cannot be directly acquired from the execution log. At this time, the physical starting address of the read-only code segment can be accessed to obtain the encrypted target data and the identifier of the one-time programmable memory, and the actual virtual address is obtained at the same time.

As a possible implementation, a debugging tool (e.g., trace 32) is used to access the physical starting address of the kernel read-only code segment (e.g., the data segment), obtain the encrypted target data, and identify the otp memory. A debug tool (e.g., trace 32) is used to obtain the actual virtual address. The specific manner of obtaining the encrypted target data, the id of the otp memory and the actual virtual address by using the debug tool may refer to the prior art, and is not described herein again. The method for acquiring the encrypted target data and the one-time programmable storage identifier after accessing the physical starting address of the read-only code segment and acquiring the actual virtual address is not limited.

S502, generating an encryption key by using the key and the identification of the one-time programmable memory.

The key is a key preset in the one-time programmable memory.

As a possible implementation manner, the key is recorded in the electronic device deployed by the kernel of the trusted operating system, and when the kernel is abnormal in operation, the CPU automatically obtains the key and generates an encryption key by using the same method as in the above embodiment according to the identifier of the one-time programmable memory. For example, if the digest algorithm is used to generate the encryption key in the above embodiment, the same digest algorithm is used to generate the same encryption key in this step.

As another possible implementation manner, after the kernel runs abnormally, the CPU obtains a key input by the user as an instruction, and then obtains an encryption key based on the instruction in the same manner as in the above embodiment.

In this implementation manner, since the preset secret key can only be known by the user who sets the secret key, it can be ensured that the encryption secret key cannot be acquired by an attacker, and the security of kernel operation is improved.

S503, decrypting the encrypted target data by using the encryption key to obtain the target data.

In the above embodiment, the target data is encrypted by using the symmetric encryption algorithm and the encryption key, so that the encrypted target data can be decrypted by using the same encryption algorithm and the same encryption key.

S504, acquiring the link address of the kernel by using the target data and the actual virtual address.

In this step, a random offset address is obtained according to the target data. Illustratively, if the target data is a random number, the random offset address is obtained according to the same method as the above embodiment. The link address is then obtained in a backward push with reference to the manner in which the actual virtual address is obtained from the link address and the random offset address in the above embodiment.

For example, assuming that the real virtual address = link address + random offset address, it follows that the link address = real virtual address-random offset address.

And S505, processing the kernel according to the link address of the kernel.

Since the link address is usually used as the actual operating address in the debug tool, after the link address of the kernel is obtained, the kernel can be processed by using the debug tool. The specific implementation manner can refer to the prior art, and is not described herein again.

In this embodiment, the kernel is run in the actual virtual address because the kernel uses the random offset address to process the link address when starting. However, when the kernel runs abnormally, the conventional debug tool mostly uses the link address to perform debug processing. Therefore, in this embodiment, the encrypted target data and the identifier of the otp memory are obtained, and then the target data is decrypted according to the manner of encrypting the target data in the above embodiment. And acquiring an actual virtual address of the kernel, and further acquiring a link address of the kernel according to the actual virtual address and the target data. Then, the kernel is processed according to the link address of the kernel. By the method, on one hand, the running safety of the kernel is ensured. On the other hand, when the debug processing needs to be performed on the kernel, the link address can be acquired according to the encrypted target data pre-stored in the read-only code segment and the identifier of the one-time programmable memory, so that the debug operation is realized, and the safe and stable operation of the kernel is further ensured.

The application also provides a kernel starting device, which is applied to the electronic equipment running with the trusted operating system, wherein the kernel of the trusted operating system is an executable program irrelevant to the position. Fig. 7 is a schematic structural diagram of a kernel boot apparatus provided in the present application. As shown in fig. 7, the kernel boot apparatus includes: the device comprises a receiving module 11, a generating module 12, a storing module 13, a reading module 14, a first obtaining module 15, a second obtaining module 16 and an operating module 17. Optionally, the kernel starting apparatus may further include, for example, the following modules: an encryption module 18 and a processing module 19.

The receiving module 11 is configured to receive a boot instruction;

a generating module 12, configured to generate a random number in response to the power-on instruction;

a storage module 13, configured to store the random number in a first memory space; the first memory space is a memory space with hardware isolation protection;

a reading module 14, configured to read the random number from the first memory space when the kernel is started;

a first obtaining module 15, configured to obtain a random offset address according to the random number;

a second obtaining module 16, configured to obtain an actual virtual address of the kernel according to the random offset address and a link address of the kernel; the random offset address is located in a first value range, the link address is located in 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 smaller than or equal to the maximum value of the virtual address space of the kernel, and the sum of the minimum value of the first value range and the minimum value of the second value range is larger than or equal to the minimum value of the virtual address space;

and the running module 17 is configured to run the kernel in a second memory space corresponding to the actual virtual address of the kernel.

As a possible implementation, the random number includes a first number of bytes; a first obtaining module 15, configured to specifically select a second number of bytes from the random number to form a seed for generating the random offset address; determining a mask address according to the first-level page table granularity of the kernel and the second value range; and operating the mask address and the seed to obtain the random offset address. The second number is less than the first number.

As a possible implementation manner, the kernel includes a global offset table, and a first code segment, where the first code segment holds description information of a symbol to be relocated in the global offset table. In this implementation, the running module 17 is specifically configured to obtain, from the first code segment, description information of a symbol to be relocated in the global offset table; according to the description information of the symbol to be relocated in the global offset table and the random offset address, relocating the link address of the symbol to be relocated in the global offset table to obtain a processed global offset table; and operating the kernel in a second memory space corresponding to the actual virtual address of the kernel according to the processed global offset table.

For example, the first code segment is a code segment after scrambling; an operation module 17, specifically configured to perform descrambling processing on the first code segment; and obtaining the description information of the symbol to be relocated in the global offset table from the first code segment after descrambling processing.

In this example, the running module 17 is specifically configured to obtain, according to the description information of the symbol to be relocated in the global offset table, a link address of the symbol to be relocated from the global offset table; adding the link address of the symbol to be relocated and the random offset address to obtain a link address after the symbol relocation processing; and updating the link address after the symbol relocation processing into the global offset table to obtain the processed global offset table.

As a possible implementation manner, the generating module 12 is further configured to generate an encryption key by using a key in the one-time programmable memory and an identifier of the one-time programmable memory;

the encryption module 18 is configured to encrypt the target data by using the encryption key to obtain encrypted target data; the target data includes: the random number and/or the random offset address;

the storage module 13 is further configured to store the encrypted target data and the identifier of the one-time programmable memory to the read-only code segment of the kernel.

As a possible implementation manner, the first obtaining module 15 is further configured to obtain, when the kernel is abnormal, the encrypted target data, the identifier of the otp memory, and the actual virtual address;

a generating module 12, further configured to generate the encryption key using the key and the identifier of the otp memory;

the encryption module 18 is further configured to decrypt the encrypted target data by using the encryption key to obtain the target data;

the first obtaining module 15 is further configured to obtain a link address of the kernel by using the target data and the actual virtual address;

and the processing module 19 is configured to process the kernel according to the link address of the kernel.

As a possible implementation manner, the second obtaining module 16 is specifically configured to determine whether there is a running log of the kernel; if the running log exists, printing the encrypted target data, the identifier of the one-time programmable memory and the actual virtual address in output information of the running log; and if the running log does not exist, accessing the physical starting address of the read-only code segment to acquire the encrypted target data and the identifier of the one-time programmable memory and acquire the actual virtual address.

The kernel starting device provided in the embodiment of the present application may execute the kernel starting method in the foregoing method embodiments, and the implementation principle and technical effects are similar, which are not described herein again.

The division of the modules shown in fig. 7 is merely an illustration, and the present application does not limit the division of the modules and the names of the modules.

Fig. 8 is a schematic structural diagram of an electronic device 110 provided in the present application. As shown in fig. 8, the electronic device may include: at least one processor 111, a memory 112.

A memory 112 for storing programs. In particular, the program may include program code including computer operating instructions.

The memory 112 may comprise high-speed RAM memory, and may also include non-volatile memory (non-volatile memory), such as at least one disk memory.

The processor 111 is configured to execute computer-executable 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 the present Application.

The electronic device 110 may further include a communication interface 113, so that the external device may be communicatively interacted with through the communication interface 113, and the external device may be, for example, a user terminal (e.g., a mobile phone, a tablet). In a specific implementation, if the communication interface 113, the memory 112 and the processor 111 are implemented independently, the communication interface 113, the memory 112 and the processor 111 may be connected to each other through a bus and perform communication with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended ISA (EISA) bus, or the like. Buses may be classified as address buses, data buses, control buses, etc., but do not represent only one bus or type of bus.

Alternatively, in a specific implementation, if the communication interface 113, the memory 112 and the processor 111 are integrated into a chip, the communication interface 113, the memory 112 and the processor 111 may complete communication through an internal interface.

The present application also provides a computer-readable storage medium, which may include: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, are specifically, the computer-readable storage medium stores program instructions, and the program instructions are used for the method for starting the kernel in the above embodiment.

The present application also provides a computer program product comprising executable instructions stored in a readable storage medium. The at least one processor of the electronic device may read the execution instruction from the readable storage medium, and the execution of the execution instruction by the at least one processor causes the electronic device to implement the kernel boot method provided in the various embodiments described above.

Other embodiments of the present application will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the invention following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the invention pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It will be understood that the present application is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims

1. A kernel boot method, applied to an electronic device running a trusted operating system, a kernel of the trusted operating system being a location-independent executable program, the method comprising:

receiving a starting-up instruction;

2. The method of claim 1, wherein the random number comprises a first number of bytes; the obtaining a random offset address according to the random number includes:

3. The method according to claim 1 or 2, characterized in that the kernel comprises a global offset table, and a first code segment holding description information of symbols to be relocated in the global offset table;

the running the kernel in a second memory space corresponding to the actual virtual address of the kernel includes:

4. The method of claim 3, wherein the first code segment is a scrambled code segment;

descrambling the first code segment;

and obtaining the description information of the symbol to be relocated in the global offset table from the first code segment after descrambling processing.

5. The method according to claim 3 or 4, wherein the obtaining the processed global offset table by performing relocation processing on the link address of the symbol to be relocated in the global offset table according to the description information of the symbol to be relocated in the global offset table and the random offset address comprises:

adding the link address of the symbol to be relocated and the random offset address to obtain a link address after the symbol relocation processing;

6. The method according to any one of claims 1-5, further comprising:

and storing the encrypted target data and the identification of the one-time programmable memory to a read-only code segment of the kernel.

7. The method of claim 6, further comprising:

and processing the kernel according to the link address of the kernel.

8. The method of claim 7, wherein obtaining the identification of the one-time programmable memory of the encrypted target data and the actual virtual address comprises:

determining whether a running log of the kernel exists;

and if the running log does not exist, accessing the physical initial address of the read-only code segment to acquire the encrypted target data and the identifier of the one-time programmable memory and acquire the actual virtual address.

9. A kernel boot apparatus, applied to an electronic device running a trusted operating system, a kernel of the trusted operating system being a location-independent executable program, the apparatus comprising:

the receiving module is used for receiving a starting instruction;

10. An electronic device, wherein the electronic device runs a trusted operating system, and a kernel of the trusted operating system is a location-independent executable program, the electronic device comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored by the memory to implement the method of any of claims 1-8.

11. A computer-readable storage medium having computer-executable instructions stored thereon, which when executed by a processor, are configured to implement the method of any one of claims 1 to 8.

12. A computer program product, comprising a computer program which, when executed by a processor, implements the method of any one of claims 1 to 8.