Mechanism for securing execution environment

Abstract

Various embodiments include methods and devices for a secure execution environment in a computing device. Embodiments may include generating a binary executable file for execution in the secure execution environment by generating hash values for instructions of a function, inserting a start hash instruction and a stop hash instruction in target code of the function, and generating a binary executable file having the function including the start hash instruction and the stop hash instruction. Embodiments may include implementing the secure execution environment by generating a hash value of an instruction of a function in parallel while executing the function, comparing the generated hash value of the instruction of the function with a stored hash value of an instruction of the function, and issuing an exception, the exception indicates to the processor that execution of the function is not secure due to any difference between the generated hash value of the instruction of the function and the stored hash value of the instruction of the function.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 933,866, filed on September 21, 2022; the entire contents of which are incorporated herein by reference. Background Art

[0003] The secure execution environment is a platform provided in the core of the central processor unit (CPU) for providing a high level of trust for the code executed in this environment, so that threats from other areas of the computing device can be ignored. Currently, the secure execution environment implements isolation zones in hardware, such as trust zones, where code should be executed in a higher privileged execution mode. In addition, the secure execution environment also implements a combination of hardware and software, such as offline signing of ELF and authentication of the signed ELF by a coprocessor before executing the image generated by the signed ELF on the target processor. Summary of the invention

[0004] The various aspects disclosed in the present invention include an apparatus and method for generating a binary executable file for execution in a secure execution environment. The various aspects may include: generating a hash value of an instruction of a function, inserting a start hash instruction and a stop hash instruction into an object code of the function, and generating a binary executable file having the function including the start hash instruction and the stop hash instruction.

[0005] In some aspects, inserting a start hash instruction and a stop hash instruction in the object code of the function may include inserting a start hash instruction in a prologue of the function and inserting a stop hash instruction in an epilogue of the function.

[0006] Some aspects may also include encrypting a program header of the hash value of the instructions for the function and storing the encrypted program header of the hash value of the instructions for the function to a dedicated memory.

[0007] Some aspects may also include: using a software development tool chain to receive an indication of a hash algorithm, wherein generating a hash value for the instructions of the function may include generating a hash value for the instructions of the function using the indicated hash algorithm (ie, identified in the indication of the hash algorithm).

[0008] Some aspects may also include receiving a private key using a software development tool chain, and encrypting a program header of a hash value of instructions for the function using an encryption algorithm and the private key.

[0009] Some aspects may also include receiving, using a software development tool chain, an indication of an encryption algorithm, and encrypting a program header of a hash value of instructions for the function using the indicated encryption algorithm (ie, identified in the indication of the encryption algorithm).

[0010] In some aspects, generating a hash value for the instructions of the function may include using an assembler to generate a hash value for the instructions of the function, inserting a start hash instruction and a stop hash instruction into an object code of the function may include using an assembler to insert a start hash instruction and a stop hash instruction into an object code of the function, and generating a binary executable file having the function including the start hash instruction and the stop hash instruction may include using a linker to generate a binary executable file having the function including the start hash instruction and the stop hash instruction.

[0011] Additional aspects include apparatus and methods for executing in a secure execution environment of a processor at runtime to maintain a secure execution environment. Such aspects may include generating a hash value of instructions of the function in parallel while executing the function, comparing the generated hash value of the instructions of the function with a stored hash value of the instructions of the function, and issuing an exception indicating to the processor that the execution of the function is unsafe due to any difference between the generated hash value of the instructions of the function and the stored hash value of the instructions of the function.

[0012] Some aspects may also include: determining whether there is a start hash instruction for the function, wherein generating a hash value of the instructions of the function in parallel when executing the function may include: generating a hash value of the instructions of the function in response to determining that there is a start hash instruction for the function, and issuing an exception in response to determining that there is no start hash instruction for the function, the exception indicating to the processor that execution of the function is unsafe.

[0013] Some aspects may also include determining whether to end generating hash values ​​for instructions of the function based on reaching a stop hash instruction for the function, wherein the generated hash values ​​for instructions of the function are compared with stored hash values ​​for instructions of the function in response to determining to end generating hash values ​​for instructions of the function.

[0014] Some aspects may also include determining whether a secure execution environment is enabled for the processor, wherein a hash value of the instructions of the function is generated in parallel while executing the function in response to determining that the secure execution environment is enabled for the processor.

[0015] Some aspects may also include: decrypting the encrypted and stored program header of the hash value of the instructions for the function to generate a decrypted program header of the hash value of the instructions for the function, and retrieving the stored hash value of the instructions for the function from the dedicated memory based on the decrypted program header of the hash value of the instructions for the function.

[0016] Some aspects may also include determining whether an encrypted and stored program header of the hash value of the instructions for the function exists in dedicated memory, wherein the encrypted and stored program header of the hash value of the instructions for the function is decrypted in response to determining that the encrypted and stored program header of the hash value of the instructions for the function exists in dedicated memory.

[0017] Additional aspects include a computing device having a processing device configured to perform the operations of any of the methods outlined above. Additional aspects include a computing device having components for performing the functions of any of the methods outlined above. Additional aspects include a non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a processor and other components of the computing device to perform the operations of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate example embodiments in various embodiments and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0019] Figure 1 is a component block diagram illustrating an example computing device suitable for implementing various embodiments.

[0020] Figure 2 is a block diagram and flow chart illustrating an example of a software development tool chain for implementing various embodiments, the software development tool chain for generating binary executable files for execution in a secure execution environment.

[0021] Figure 3 is a block diagram illustrating an example of an assembler for implementing various embodiments.

[0022] Figure 4 is a block diagram illustrating an example of a linker for implementing various embodiments.

[0023] Figure 5 is a process flow diagram illustrating a method performed in a computing device for generating a binary executable file for execution in a secure execution environment according to an embodiment.

[0024] Figure 6 are block diagrams and flow charts illustrating examples of boot components for implementing various embodiments for implementing a secure execution environment.

[0025] Figure 7 is a block diagram illustrating an example of a secure execution environment for implementing various embodiments.

[0026] Figure 8 is a process flow diagram illustrating a method for booting a processor to implement a secure execution environment according to an embodiment.

[0027] Fig. 9 is a process flow diagram illustrating a method for implementing a secure execution environment according to an embodiment.

[0028] Fig.10 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0029] Fig.11 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0030] Fig.12 is a component block diagram illustrating an example server suitable for implementing various embodiments. DETAILED DESCRIPTION

[0031] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0032] Various embodiments include methods, and computing devices that implement such methods of protecting execution environments. Various embodiments may include a software development tool chain for generating binary executable files for software, wherein a hash value of a function is generated for the software to verify the function of the binary executable file at runtime. In some embodiments, a hash value is generated for each function of the binary executable file, and these hash values ​​are stored in a specified memory and encrypted. The embodiment may also include hardware for verifying the function of the binary executable file at runtime. In some embodiments, the hardware may generate a hash value of the function executed at runtime, and the hash value generated at runtime is compared with the hash value of the function of the binary executable file stored in a dedicated memory to verify the function executed at runtime.

[0033] The term "computing device" may refer to a fixed computing device, including a personal computer, a desktop computer, an all-in-one computer, a workstation, a supercomputer, a mainframe computer, an embedded computer (such as embedded in a vehicle and other larger systems), a computer system in a vehicle, a server, a multimedia computer, and a game console. The terms "computing device" and "mobile computing device" are used interchangeably herein to refer to any or all of the following: a cellular telephone, a smart phone, a personal or mobile multimedia player, a personal data assistant (PDA), a laptop computer, a tablet computer, a convertible laptop / tablet computer (2-in-1 computer), a smartbook, an ultrabook, a netbook, a palmtop computer, a wireless email receiver, an Internet-enabled multimedia cellular telephone, a mobile game console, a wireless game controller, and similar personal electronic devices that include a memory and a programmable processor.

[0034] For ease of explanation and clarity, although various embodiments are described in terms of code (e.g., processor executable instructions), similarly applicable to any data, such as code, program data, or other information stored in memory. The terms "code," "data," and "information" are used interchangeably herein and are not intended to limit the scope of the claims and specification to the types of code, data, or information used as examples in describing various embodiments.

[0035] Current secure execution environments rely on preset isolation of code execution from vulnerable attack vectors and / or previously verified code to ensure the security of code execution. However, such secure execution environments do not support the execution of verified code during runtime and therefore cannot detect attacks such as session hijacking implemented via injection of malicious code (e.g., via network packets), probing and replacing stack frames during runtime, and replacing DLLs during runtime.

[0036] Various embodiments provide solutions to the aforementioned problems, thereby enabling runtime verification of functions executed in a processor, which runtime verification can be used to detect session hijacking so that measures can be taken to prevent the adverse effects of the attack. Various embodiments include a software development tool chain that can generate a hash value for each function of the software code as part of generating a binary executable file (e.g., ELF, PE, Mach-O, etc.) of the software. The embodiments also include processor hardware that is configured to generate hash values ​​for functions executed in the processor at runtime, and verify these functions at runtime by comparing the hash values ​​generated by the software development tool chain with the hash values ​​generated using the processor hardware.

[0037] The software development tool chain may include a compiler, an assembler, and a linker. The software development tool chain identifies each function of the software code, generates a hash value for each function, and inserts a hash instruction in each function, which may trigger the generation of a hash value for each function. Generating a hash value for each function may include hashing all instructions of each function. The hash value of each function may be generated using a hash function provided by a developer to the software development tool chain. The hash function may be stored in a hash-specific memory.

[0038] The software development tool chain can encrypt the hash value of each function and store the encrypted hash value in a hash-specific memory. The encryption of the hash value can be achieved using a private key provided by the developer to the software development tool chain and an encryption function pre-configured in the processor hardware and / or provided by the developer to the software development tool chain. The encryption scheme used to encrypt the hash value can be symmetric and / or asymmetric. The hash-specific memory may include any memory accessible to the processor, including memory that is only accessible to the processor, such as a dedicated partition of the memory, and / or a memory that is only accessible to the processor hardware. Accessing the hash-specific memory from software may result in the generation of an exception.

[0039] For example, using an asymmetric encryption scheme, a developer may store a public key for decrypting dedicated memory in processor hardware. A hash instruction may indicate the start of a function and trigger the generation of a hash value for the function at runtime, and may indicate the end of a function and stop the generation of a hash value for the function at runtime. The hash instruction may be included in a binary executable file of the software.

[0040] At runtime, the processor hardware for verifying the function of the software code executed in the processor may encounter a hash instruction for the executed function in the binary executable file of the software. The hash instruction may trigger the processor hardware to generate a hash value for each executed function in a manner similar to a tool chain. Generating a hash value for each executed function may include hashing all instructions of each executed function. The hash value of each executed function may be generated using a hash function (such as a hash function stored in a hash dedicated memory) pre-configured in the processor hardware by the manufacturer of the processor and / or by the developer. The processor hardware may decrypt the hash value of the function of the software code from the hash dedicated memory and retrieve the decrypted hash value from the hash dedicated memory. At runtime, the processor hardware may verify the executed function by comparing the hash value generated for the executed function at runtime with the decrypted hash value of the function for the software retrieved from the hash dedicated memory. If the executed function is verified to be valid, the software code may be allowed to continue to execute. If the executed function is verified to be invalid, the processor hardware may be triggered to issue an exception.

[0041] For clarity and ease of explanation, various embodiments are described with hashing of instructions of a function and hash values ​​as non-limiting examples. Those skilled in the art will appreciate that other components such as other algorithm components may be implemented to generate representations of instructions of a function and representations of instructions of a function.

[0042] Various embodiments enable processor hardware to quickly validate functions before executing them at runtime, thereby improving the functionality and security of software executing on a processor of a computing device.

[0043] Figure 1 A system including a computing device 100 suitable for use with various embodiments is illustrated. The computing device 100 may include a SoC 102 having a central processing unit 104, a memory 106, a communication interface 108, a memory interface 110, a peripheral device interface 120, and a processing device 124. The computing device 100 may also include a communication component 112 (such as a wired or wireless modem), a memory 114, an antenna 116 for establishing a wireless communication link, and / or a peripheral device 122. The processor 124 may include any of a variety of processing devices (e.g., multiple processor cores).

[0044] The term "system on chip" or "SoC" is used herein to refer to a group of interconnected electronic circuits, typically but not exclusively including a processing device, a memory, and a communication interface. The processing device may include a variety of different types of processors 124 and / or processor cores, such as a general-purpose processor, a central processing unit (CPU) 104, a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a security processing unit (SPU), an intellectual property unit (IPU), a subsystem processor for a specific component of the computing device (such as an image processor for a camera subsystem or a display processor for a display), an auxiliary processor, a peripheral device processor, a single-core processor, a multi-core processor, a controller, and / or a microcontroller. The processing device may further implement other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), other programmable logic devices, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and / or a time reference. The integrated circuit may be configured so that the components of the integrated circuit reside on a single piece of semiconductor material (such as silicon).

[0045] SoC 102 may include one or more CPUs 104 and processors 124. Computing device 100 may include more than one SoC 102, thereby increasing the number of CPUs 104, processors 124, and processor cores. Computing device 100 may also include CPUs 104 and processors 124 that are not associated with SoC 102. Individual CPUs 104 and processors 124 may be multi-core processors. CPUs 104 and processors 124 may each be configured for a specific purpose that may be the same or different from other CPUs 104 and processors 124 of computing device 100. One or more of the CPUs 104, processors 124, and processor cores of the same or different configurations may be grouped together. A group of CPUs 104, processors 124, or processor cores may be referred to as a multi-processor cluster.

[0046] The memory 106 of SoC 102 may be a volatile or non-volatile memory configured to store data and processor executable code for access by CPU 104, processor 124 or other components of SoC 102. The computing device 100 and / or SoC 102 may include one or more memories 106 configured for various purposes. One or more memories 106 may include volatile memory, such as random access memory (RAM) or main memory, or cache memory. These memories 106 may be configured to temporarily hold a limited amount of data received from a data sensor or subsystem, data and / or processor executable code instructions loaded from non-volatile memory to memory 106 in anticipation of future access based on various factors requested from non-volatile memory, and / or intermediate processing data and / or processor executable code instructions generated by CPU 104 and / or processor 124 and temporarily stored for fast access without being stored in non-volatile memory. In some embodiments, any number and combination of memories 106 may include one-time programmable or read-only memory.

[0047] The memory 106 may be configured to at least temporarily store data and processor executable code loaded to the memory 106 from another memory device, such as another memory 106 or memory 114, for access by one or more of the CPU 104, the processor 124, or other components of the SoC 102. The data or processor executable code loaded to the memory 106 may be loaded in response to execution of a function by the CPU 104, the processor 124, or by other components of the SoC 102. The loading of the data or processor executable code to the memory 106 in response to execution of the function may originate from a memory access request to another memory 106 or memory 114, and the data or processor executable code may be loaded to the memory 106 for later access.

[0048] The memory interface 110 and the memory 114 may work together to allow the computing device 100 to store data and processor executable code on volatile and / or non-volatile storage media and retrieve data and processor executable code from the volatile and / or non-volatile storage media. The memory 114 may be configured like the embodiment of the memory 106, where the memory 114 may store data or processor executable code for access by one or more of the CPU 104, the processor 124, or other components of the SoC 102. In some embodiments, the non-volatile memory 114 may retain information after the computing device 100 has been powered off. When power is re-applied and the computing device 100 restarts, the information stored on the memory 114 may be available to the computing device 100. In some embodiments, the volatile memory 114 may not retain information after the computing device 100 has been powered off. The memory interface 110 may control access to the memory 114 and allow the CPU 104, the processor 124, or other components of the SoC 12 to read data from and write data to the memory 114.

[0049] Some or all of the components of computing device 100 and / or SoC 102 may be arranged and / or combined differently while still providing the functionality of the various embodiments. Computing device 100 may not be limited to one of each of the components, and multiple instances of each component may be included in various configurations of computing device 100.

[0050] Figure 2 An example of a software development tool chain for implementing various embodiments is illustrated, the software development tool chain being used to generate binary executable files for execution in a secure execution environment. Figure 1 and Figure 2 , the software development tool chain 200 may be implemented in a processor (e.g., CPU 104, processor 124) and may include a compiler 206, an assembler 210, and a linker 216. The software development tool chain 200 may be used by a developer of a processor (e.g., CPU 104, processor 124) and / or for a computing device (e.g., computing device 100) having a processor configured to implement a secure execution environment to execute software developed using the software development tool chain 200.

[0051] The software development tool chain 200 may receive an input 204 for generating a binary executable file 220 with a hash instruction, and generating, encrypting and storing a hash value for a function of the software, such as an encrypted hash value and function 218. The input 204 may include software source code to be converted into a binary executable file, and a command to compile the software source code. In some embodiments, the input 204 may also include an indication of a hash algorithm for generating a hash value for a function of the software. In another example, the input 204 may include an indication of a private key and / or an encryption algorithm for encrypting a hash value for a function of the software.

[0052] The compiler 206 may receive software source code for the input 204 of the software development tool chain 200 and generate assembly code 208 for the source code. In some embodiments, the compiler 206 may also receive an indication of a hash algorithm, a private key, and / or an indication of an encryption algorithm for the input 204. The compiler 206 may provide one or more of these inputs to one or more of the components of the software development tool chain 200. For example, the compiler 206 may provide an indication of a hash algorithm to the assembler 210. As another example, the compiler 206 may provide an indication of a private key and / or an encryption algorithm to the linker 216.

[0053] Assembler 210 may receive assembly code 208 and an indication of a hash algorithm and generate a hash value and data for function 212 and target code 214 with hash instructions. Assembler 210 may also generate a program header or fragment for the hash value and data for function 212, which may be part of target code 214 with hash instructions. Figure 3 An example of the assembler 210 is illustrated. Figures 1 to 3 , the assembler 210 may include a function identification module 300, a hash generation module 302, and a hash instruction insertion module 304, which may be implemented as part of the assembler 210 to generate a hash value and data of a function 212 and a target code 214 with a hash instruction.

[0054] The function identification module 300 may be implemented using any of a variety of known methods for identifying different functions of the software in the assembly code 208. For example, the function identification module 300 may identify a function between a prologue and an epilogue of a function in the assembly code 208. In a specific and non-limiting example, the function identification module 300 may identify a function between a push instruction of the prologue and a pop instruction of the epilogue for managing data of a stack.

[0055] The hash generation module 302 can generate hash values ​​and data for the function 212 for the assembler 210. For example, the hash generation module 302 can use an indication of a hash algorithm received by the assembler 210 to determine a hash algorithm that the assembler 210 will use to generate the hash value and data for the function 212. In some embodiments, the indication of the hash algorithm can indicate a hash algorithm that is preconfigured on the processor. The indication of the hash algorithm can be a direct and / or indirect reference to a hash algorithm in a memory (e.g., the memory 106), and the hash generation module 302 can retrieve the hash algorithm from the memory based on the indication of the hash algorithm. In some embodiments, the indication of the hash algorithm itself can be a hash algorithm that the hash generation module 302 can execute. The hash algorithm can be stored in the memory (e.g., Figure 1 In the memory 106), such as stored in a hash-specific memory.

[0056] The hash generation module 302 can generate a hash value for each instruction of each function of the software in the assembly code 208. In some embodiments, the hash value of each instruction of each function of the software may include the hash value of the push instruction after the instruction of the function. The hash generation module 302 can also associate the hash value for each instruction with the function to which it belongs. For example, each function may have a function identifier, which may include any components for uniquely identifying each function of the software, such as the address of the function. The hash generation module 302 can generate a hash value and the data of the function 212 so that the hash value for each instruction is associated with the appropriate function identifier. The association can be based on the format and / or structure of the hash value and the data of the function 212.

[0057] The hash instruction insertion module 304 can generate a target code 214 with a hash instruction for the assembler 210. For example, the hash instruction insertion module 304 can insert a hash instruction into the target code of the software. The hash instruction can include a start hash instruction and a stop hash instruction, which can cause the processor of the computing device that executes the function to start and stop generating hash values ​​of the instructions of the execution function at runtime. The stop hash instruction can also cause the processor to compare the hash values ​​of the instructions of the function generated using the software development tool chain 200, such as the hash value and the function 212. The stop hash function can also cause the processor to generate an exception in response to the comparison result of the hash value being that the hash value does not match. In the target code, the start hash instruction can be inserted before the instruction of the function, and the stop hash instruction can be inserted after the instruction of the function. For example, the start hash instruction can be inserted into the prologue of the function, and the stop hash instruction can be inserted into the epilogue of the function. For a specific and non-limiting example, the start hash instruction can be inserted before the push instruction, and the stop hash instruction can be inserted before the pop instruction.

[0058] See again Figure 2 , the linker 216 may receive the data of the hash value and function 212 and the target code 214 with the hash instruction, encrypt the program header or fragment for the data of the hash value and function 212, store the hash value and function 218 and the encrypted program header or fragment 219 for the hash value and function in a hash-specific memory, and generate a binary executable file 220 with the hash instruction from the target code 214 with the hash instruction. In some embodiments, the linker 216 may receive an indication of a private key and / or an encryption algorithm, and use the private key and / or the indication of the encryption algorithm to encrypt the program header or fragment for the hash value and function 212. Figure 4 An example of linker 216 is illustrated. Figures 1 to 4 , the linker 216 may include an encryption module 400 and a storage module 402, both of which may be implemented as part of the linker 216 to encrypt a program header or fragment for a hash value and function 212, and store the encrypted program header or fragment 219 of the hash value and function 218 and the data for the hash value and function in a hash-specific memory.

[0059] The encryption module 400 may encrypt a program header or fragment for the hash value and function 212, thereby generating an encrypted program header or fragment 219 for the hash value and function. The encryption module 400 may use a private key received by the linker 216 and in combination with an encryption algorithm to encrypt the program header or fragment for the hash value and function 212. For example, the encryption module 400 may use an indication of an encryption algorithm received by the linker 216 to determine an encryption algorithm that the linker 216 may use to encrypt the program header or fragment for the hash value and function 212. In some embodiments, the indication of the encryption algorithm may indicate an encryption algorithm pre-configured on the processor. The indication of the encryption algorithm may be a direct and / or indirect reference to an encryption algorithm in a memory (e.g., memory 106), and the encryption module 400 may retrieve the encryption algorithm from the memory based on the indication of the encryption algorithm. In some embodiments, the indication of the encryption algorithm itself may be an encryption algorithm executable by the encryption module 400.

[0060] The storage module 402 can be stored in a memory (e.g., Figure 1 The hash value and function 218 and the encrypted program header or fragment 219 of the data used for the hash value and function are stored in a memory 106 in the computing device (such as a hash-specific memory). The memory can be any memory that can be accessed by the processor of the computing device. In some embodiments, the memory can be a memory that can only be accessed by the hardware of the computing device (such as the hardware of the processor used to implement the secure execution environment).

[0061] See again Figure 2, the linker 216 can use various known methods to generate a binary executable file 220 with a hash instruction from the target code 214 with the hash instruction. The linker 216 can use known methods to generate a binary executable file. In addition, since the target code used by the linker 216 to generate the binary executable file includes a hash instruction, the binary executable file also includes a hash instruction.

[0062] Figure 5 A method 500 is illustrated that may be implemented in a computing device that performs operations of a software development tool chain that includes compiler, assembler, and linker functions for generating a binary executable file for execution in a secure execution environment according to some embodiments. Figures 1 to 5 , the method 500 may be executed in a computing device (e.g., computing device 100), in hardware of a computing device, in software executed in a processor of a computing device, or in a combination of a processor configured in software and dedicated hardware. For example, the method 500 may be executed in a CPU 104 or processor 124 executing a software development tool chain 200, which includes a compiler 206, an assembler 210, a linker 216, a function identification module 300, a hash generation module 302, a hash instruction insertion module 304, a linker 216, an encryption module 400, and a storage module 402. The method 500 may also be executed in whole or in part in other separate components, such as various memories / caches (e.g., memories 106, 114) and various memory / cache controllers. To encompass alternative configurations of hardware and software that may perform method 500 in various embodiments, the hardware that implements method 500 is referred to herein as a "processing device," which may be configured with processor-executable instructions (software) that may be stored in a non-transitory processor-readable medium (e.g., memory 106, 114).

[0063] In block 502, a processing device may receive a software development tool chain (e.g., Figure 2 The software development tool chain 200 in the example (e.g., Figure 2 The processing device may use these inputs to generate a binary executable file with hash instructions (e.g., Figure 2 A binary executable file 220 having hash instructions therein, and a function that generates, encrypts and stores cryptographic hash values ​​and functions of the software (e.g., Figure 2The inputs may include the software source code to be converted into a binary executable file. In some embodiments, the inputs may also include an indication of a hash algorithm used to generate a hash value for the function of the software. In some embodiments, the inputs may include a private key and / or an indication of an encryption algorithm used to encrypt the hash value of the function of the software. In some embodiments, the processing device that receives the input of the software development tool chain in block 502 may be a processor (e.g., CPU 104, processor 124), a software development tool chain, and / or a compiler (e.g., Figure 2 Compiler 206 in).

[0064] In block 504, the processing device may generate assembly code from the source code. The processing device may generate assembly code via various known methods, such as using a compiler to generate assembly code from the source code. In some embodiments, the processing device that generates assembly code from the source code in block 504 may be a processor, a software development tool chain, and / or a compiler.

[0065] In block 506, the processing device may identify the function in the assembly code. The processing device may receive the assembly code generated in block 504. The processing device may use various known methods to identify different functions of the software in the assembly code. For example, the processing device may identify the function between the prologue and the epilogue of the function in the assembly code. In a specific and non-limiting example, the processing device may identify the function between the push instruction of the prologue and the pop instruction of the epilogue for managing data on the stack. In some embodiments, the processing device that identifies the function in the assembly code in block 506 may be a processor, a software development tool chain, an assembler (e.g., Figure 2 and Figure 3 assembler 210) and / or a function identification module (e.g., function identification module 300).

[0066] In block 508, the processing device may generate the target code from the assembly code. The processing device may generate the target code using various known methods, such as using an assembler to generate the target code from the assembly code. In some embodiments, the processing device that generates the target code from the assembly code in block 508 may be a processor, a software development tool chain, and / or an assembler.

[0067] In block 510, the processing device may insert a hash instruction into each function of the target code. The processing device may generate the target code with the hash instruction by inserting the hash instruction into each function of the target code (e.g., Figure 2214). The hash instructions may include a start hash instruction and a stop hash instruction, which may cause a processor (e.g., CPU 104, processor 124) of a computing device (e.g., computing device 100) that executes a function to start and stop generating hash values ​​of instructions for executing the function at runtime. In the target code, the start hash instruction may be inserted before the instruction of the function, and the stop hash instruction may be inserted after the instruction of the function. For example, the start hash instruction may be inserted into the prologue of the function, and the stop hash instruction may be inserted into the epilogue of the function. For a specific and non-limiting example, the start hash instruction may be inserted before the push instruction, and the stop hash instruction may be inserted before the pop instruction. In some embodiments, inserting the hash instruction into each function of the target code in box 510 may be implemented after generating the target code from the assembly code in box 508 and / or concurrently with generating the target code from the assembly code. In some embodiments, the processing device that inserts the hash instruction into each function of the target code in box 510 can be a processor, a software development tool chain, an assembler and / or a hash instruction insertion module (e.g., the hash instruction insertion module 304).

[0068] In block 512, the processing device may generate a hash value for the function in the object code (e.g., Figure 2 The processing device may implement a hash function to generate a hash value for each instruction of the function identified in block 508. For example, the hash generation module 302 may use an indication of the input hash algorithm to determine the hash algorithm to be used to generate the hash values. In some embodiments, the indication of the hash algorithm may indicate a hash algorithm preconfigured on the processing device. The indication of the hash algorithm may be a direct and / or indirect reference to a hash algorithm in a memory (e.g., memory 106) (such as a hash-specific memory), and the processing device may retrieve the hash algorithm from the memory based on the indication of the hash algorithm. A start hash instruction may trigger the generation of a hash value for any function, and a stop hash instruction inserted into the function may terminate the generation of a hash value. In some embodiments, the indication of the hash algorithm itself may be a hash algorithm executable by the processing device. In some embodiments, the hash value for each instruction of each function of the software may include a hash value of a push instruction following the instruction of the function.

[0069] The processing device may also associate the hash value for each instruction with the function to which it belongs. For example, each function may have a function identifier, which may include any components for uniquely identifying each function of the software, such as the address of the function. The processing device may generate a hash value in association with the function identifier of the function that has generated the hash value. The association may be based on the format and / or structure of the data of the hash value and the function identifier. In some embodiments, the hash value of the function generated in the target code in frame 510 may be implemented after the target code is generated from the assembly code in frame 508 and / or concurrently with the target code generated from the assembly code. In some embodiments, the processing device that generates the hash value of the function in the target code in frame 510 may be a processor, a software development tool chain, an assembler and / or a hash generation module (e.g., a hash generation module 302).

[0070] In block 514, the processing device may generate a binary executable file (e.g., Figure 2 The processing device may generate a binary executable file with a hash instruction from a target code with a hash instruction using various known methods. The processing device may generate a binary executable file using known methods. In addition, since the target code used by the processing device to generate the binary executable file includes a hash instruction, the binary executable file also includes a hash instruction. In some embodiments, the processing device that generates the binary executable file with a hash instruction in block 514 may be a processor, a software development tool chain, and / or a linker (e.g., Figure 2 and Figure 4 Linker 216 in).

[0071] In block 516, the processing device may perform a program header or segment (e.g., Figure 2 The processing device may encrypt the program header or segment for the hash value and function to generate an encrypted program header or segment for the hash value and function (e.g., Figure 2219). The processing device may use the input private key in conjunction with the encryption algorithm to encrypt the data of the hash value and function. For example, the processing device may use an indication of the input encryption algorithm to determine the encryption algorithm to be used to encrypt the data of the hash value and function. In some embodiments, the indication of the encryption algorithm may indicate an encryption algorithm preconfigured on the processor. The indication of the encryption algorithm may be a direct and / or indirect reference to an encryption algorithm in a memory (e.g., memory 106), and the processing device may retrieve the encryption algorithm from the memory based on the indication of the encryption algorithm. In some embodiments, the indication of the encryption algorithm itself may be an encryption algorithm executable by the processing device. In some embodiments, the processing device that encrypts the program header or fragment for the hash value and function in block 516 may be a processor, a software development tool chain, a linker, and / or an encryption module (e.g., encryption module 400).

[0072] In block 518, the processing device may store the hash value and the function (eg, Figure 2 The processing device may store the hash value and function and the encrypted program header or fragment for the hash value and function in a hash-specific memory (e.g., memory 106). The memory may be any memory that can be accessed by the processing device. In some embodiments, the memory may be a memory that is accessible only by the processing device. In some embodiments, the processing device that stores the hash value and function and the encrypted program header or fragment for the hash value and function in block 518 may be a processor, a software development tool chain, a linker, and / or a storage module (e.g., storage module 402).

[0073] Figure 6 An example of a boot component for implementing a secure execution environment for implementing various embodiments is illustrated. Figures 1 to 6 , a computing device (e.g., computing device 100) may implement a boot component 600 in a processor (e.g., CPU 104, processor 124). Boot component 600 may include hardwired reset code 602, reset handler 604, main function 606, and function 608. Boot component 600 may be implemented in hardware, firmware, and / or software, and may be implemented in a boot or reset sequence for a computing device. The boot component may be embedded in hardware and / or stored in and accessed from a memory (e.g., memory 106, 114).

[0074] The hardwired reset code 602 may be configured to cause the processor to determine whether a secure execution environment is implemented, and if a secure execution environment is implemented, to initialize the secure execution environment. In some embodiments, the hardwired reset code 602 may be implemented as microcode on the processor and stored in a memory that is a read-only memory. For example, the hardwired reset code 602 may check the state of the eFuse to determine whether a secure execution environment is implemented. The state of the eFuse may indicate to the hardwired reset code 602 whether the secure execution environment is an enabled feature of the processor. In response to the state of the eFuse indicating that the secure execution environment is an enabled feature of the processor, the hardwired reset code 602 may initialize the secure execution environment.

[0075] To initialize the secure execution environment, the hardwired reset code 602 may check for an encrypted program header or fragment for hash values ​​and functions (e.g., Figure 2 Whether the encrypted program header or fragment 219 for the hash value and function in the cipher exists for the loaded binary executable file (e.g., Figure 2 The hash-specific memory may be located in a hash-specific memory (e.g., memory 106) of a binary executable file 220 having hash instructions in it. The hash-specific memory may be located in a memory known to the hardwired reset code 602 and / or in a location in memory accessible only by hardware, and may be checked for the presence of data. The hash-specific memory filled with data may indicate to the hardwired reset code 602 that an encrypted program header or fragment for hash values ​​and functions is present in the hash-specific memory for the loaded binary executable file.

[0076] The hardwired reset code 602 may retrieve and decrypt the encrypted program header or fragment for the hash value and function, and use the decrypted program header or fragment for the hash value and function to retrieve the stored hash value and function from the hash-specific memory (e.g., Figure 2 The hardwired reset code 602 may store the hash value and function 218 in a secure execution environment dedicated memory (e.g., memory 106). The secure execution environment dedicated memory may be part and / or all of the memory accessible by hardware for implementing the secure execution environment, and / or hardware accessible only by hardware for implementing the secure execution environment.

[0077] With the secure execution environment initialized, hardwired reset code 602 may hand over control of the boot process to a reset vector, which may continue the boot process using various known methods, such as implementing a reset handler 604 that may include calling a main function 606. Main function 606 may include a call to function 608.

[0078] Function 608 may be a function of a loaded binary executable file that may be executed using a software development tool chain (e.g., Figure 2 The software development tool chain 200 in is used to generate.

[0079] Function 608 may include a start hash instruction before the instructions of function 608 and a stop hash instruction after the instructions of function 608. For example, the start hash instruction may be included in the prologue of function 608, such as before a push instruction for pushing data to a stack. The start hash instruction may cause a processor executing function 608 to start generating hash values ​​for the instructions executing function 608 at runtime.

[0080] The stop hash instruction may be included in the epilogue of function 608, such as before a pop instruction for removing data from the stack. The stop hash instruction may cause a processor executing function 608 to stop generating hash values ​​for instructions executing function 608 at runtime. The stop hash instruction may cause the processor to stop generating hash values ​​for instructions after the pop instruction. In other words, a start hash instruction may be used to generate a hash value for a pop instruction.

[0081] The stop hash instruction may also cause the processor to compare a hash value of function 608 generated by the processor at runtime with a hash value of the secure execution environment dedicated memory. The processor may retrieve a hash value associated with the executed function 608 from the secure execution environment dedicated memory and compare the generated hash value with the retrieved hash value at runtime to determine whether the hash values ​​match. A hash value match may indicate to the processor that function 608 has not been edited, while a hash value mismatch may indicate to the processor that function 608 has been edited and may be malicious.

[0082] Execution of the unedited function 608 may indicate that execution of the function 608 is safe, while execution of the edited function 608 may indicate that execution of the function 608 is unsafe. In response to the indication that execution of the function 608 is safe, the stop hash instruction may allow safe execution to continue without interruption. In response to the indication that execution of the function 608 is unsafe, the stop hash instruction may trigger the generation of an exception, thereby indicating to the processor that execution of the function 608 is unsafe. The stop hash instruction may reset the hardware of the processor implementing the start hash and / or stop hash instructions for subsequent functions 608.

[0083] Figure 7 An example of a secure execution environment for implementing various embodiments is illustrated. Figures 1 to 7, the secure execution environment 700 may be implemented in hardware components of a processor (e.g., CPU 104, processor 124) and / or SoC (e.g., SoC 102). The hardware components for implementing the secure execution environment 700 may include a processor core 702, hash generation hardware (referred to herein as a "hash generator") 706, temporary hash storage hardware 708 (e.g., memory 106), secure execution environment dedicated memory 710 ("secure memory") (e.g., memory 106), and hash comparator hardware (referred to herein as a "hash comparator") 712. The hash generator 706 and the hash comparator 712 may be implemented in a secure hardware component coupled to or associated with the processor core 702.

[0084] The processor core 702 may execute a function (“Function 1”) (e.g., function 608). The pipeline 704 implemented in the processor core 702 may fetch instructions from the function (e.g., “Start Hash”, “Instruction 1”, “Instruction 2”, “Instruction 3”, “Stop Hash”). The pipeline may decode the fetched instructions, and may execute the decoded instructions, and provide the decoded instructions to the hash generator 706 in parallel.

[0085] In parallel with the execution of instructions by the processor core 702, the hardware components 706-712 may implement a start hash instruction and a stop hash instruction. The start hash instruction may cause the hash generator 706 to generate a hash value of the instruction of the function in parallel with the execution of the instruction of the function. The hash generator 706 may use a hash algorithm pre-configured for the hash generator 706, and store the generated hash value to the temporary hash storage hardware 708. The temporary hash storage hardware 708 may include any memory accessible to the processor, including memory that can only be accessed by the processor, such as a dedicated partition of memory, and / or memory that can only be accessed by the processor hardware. The temporary hash storage hardware 708 may include any memory accessible to the hash generator 706 and the hash comparator 712, including memory that can only be accessed by the hash generator 706 and the hash comparator 712, such as a dedicated partition of memory, and / or memory that can only be accessed by the hardware.

[0086] The stop hash instruction may cause the hash generation hardware 706 to stop generating hash values ​​for instructions and retrieve a hash value for a function from the secure execution environment dedicated memory 710 and provide the retrieved hash value to the hash comparator hardware 712 in parallel with the execution of the instructions for the function. The hash generation hardware 706 may use a function identifier retrieved by the processor core 702 from a function provided by the processor core 702 to the hash generator 706 to identify and retrieve a hash value associated with the function identifier in the secure execution environment dedicated memory 710. In some embodiments, retrieving the hash value for the function from the secure execution environment dedicated memory 710 and providing the retrieved hash value to the hash comparator 712 may involve prompting the secure execution environment dedicated memory 710 to provide the retrieved hash value to the hash comparator 712.

[0087] In response to filling the temporary hash storage hardware 708 with a hash value and / or receiving a retrieved hash value from the hash generator 706, the hash comparator 712 may compare the hash value generated by the hash generator 706 for the function with the retrieved hash value for the function and determine whether the hash values ​​match.

[0088] If the result of the comparison is that all hash values ​​match, it may indicate that the execution of the function is safe, and the hash comparator 712 may allow the safe execution to continue without interruption. If the result of the comparison is that there are any unmatched hash values, it may indicate that the execution of the function is unsafe, and the hash comparator 712 may generate an exception, thereby indicating to the processor that the execution of the function is unsafe. For example, due to unauthorized editing of the stack with instructions of function 1, the processor core may obtain, decode and execute function 2 instead of the expected hash value of instruction 2. The hash generator 706 may generate a hash value of function 2 instead of instruction 2, and the hash comparator 712 may compare the generated hash value of function 2 with the retrieved hash value of instruction 2, and the result of the comparison may be that the hash values ​​do not match, which may cause the hash generator 706 to issue an exception. The stop hash instruction may cause the hash generation hardware 706, the temporary hash storage hardware 708 and the hash comparator 712 to reset for subsequent functions.

[0089] Figure 8 The method 800 for booting a processor to implement a secure execution environment that can be executed in a processing device of a computing device according to some embodiments is illustrated. The method 800 can be performed in a computing device (e.g., computing device 100), in hardware (e.g., Figure 1104, processor 124), in computer code executed in a processor (e.g., hardwired reset code 602, reset handler 604), or in a processor configured in computer code and including other separate components (such as various memories / caches (e.g., secure execution environment dedicated memory 710, Figure 1 The method 800 is implemented in a combination of dedicated hardware such as the memory 106 and 114 in the processor 106 and 114 and various memory / cache controllers. To cover alternative configurations implemented in various embodiments, the hardware implementing the method 800 is referred to herein as a "processing device."

[0090] In determination block 802, the processing device may determine whether a secure execution environment (eg, secure execution environment 700) is a processor (eg, processor core 702, Figure 1 104 and processor 124 in . In some embodiments, the processing device may check the state of an eFuse (referred to herein as a "secure eFuse") to determine whether the secure execution environment feature is enabled for the processor. The state of the secure eFuse may indicate to the processing device whether the secure execution environment is an enabled feature of the processor. A blown security eFuse may indicate to the processing device that the secure execution environment is an enabled feature of the processor. A full security eFuse may indicate to the processing device that the secure execution environment is not an enabled feature of the processor. In some embodiments, the processing device may check values ​​in an immutable memory (e.g., memory 106, 114), values ​​at dedicated input pins, etc., which are configured to indicate to the processing device whether the secure execution environment is an enabled feature of the processor. In some embodiments, the processing device that determines in determination block 802 whether the secure execution environment is an enabled feature of the processor may be a processor (e.g., processor core 702, Figure 1 104 and processor 124 in ) and / or a hardwired reset code (e.g., hardwired reset code 602).

[0091] In response to determining that the secure execution environment is an enabled feature of the processor (ie, determination block 802 = "Yes"), the processing device may determine in determination block 804 an encrypted program header or fragment (eg, Figure 2 The processing device may check whether the encrypted program header or fragment for the hash value and function exists in the loaded binary executable file (e.g., Figure 2The hash dedicated memory may be located at a location in a memory known to the processing device and / or a memory accessible only by hardware, and may be checked for the presence of data. The hash dedicated memory filled with data may indicate to the processing device that an encrypted program header or fragment for hash values ​​and functions exists in the hash dedicated memory for the loaded binary executable file. In some embodiments, the processing device may check the value at a dedicated location in the hash dedicated memory, the value at a dedicated input pin, etc., which are configured to indicate to the processing device whether the encrypted hash value and function exist in the hash dedicated memory for the loaded binary executable file. In some embodiments, the processing device that determines in determination block 804 whether the encrypted program header or fragment for hash values ​​and functions exists in the memory may be a processor and / or a hardwired reset code.

[0092] In response to determining that the encrypted hash value and function are present in memory (i.e., determination block 804 = "Yes"), the processing device may decrypt the encrypted program header or fragment for the hash value and function in memory in block 806. The processing device may be pre-configured with a public key and a decryption algorithm and use the public key and decryption algorithm to decrypt the encrypted hash value and function. In some embodiments, the processing device that decrypts the encrypted program header or fragment for the hash value and function in memory in block 806 may be a processor and / or hardwired reset code.

[0093] In block 808, the processing device may combine the hash value and the function (eg, Figure 2 The hash value and function 218 stored in the secure execution environment are retrieved into a memory (e.g., secure execution environment dedicated memory 710, Figure 1 106 in the memory to temporarily store these hash values ​​and functions. The memory can be a secure execution environment dedicated memory, which can include any memory accessible to the processor, including memory that can only be accessed by the processor, such as a dedicated partition of the memory, and / or a memory that can only be accessed by the processor hardware. The hash values ​​and functions stored in the memory may include hash values ​​stored in association with each other and function identifiers of functions of these hash values. The association can be based on the format and / or structure of the data of the hash values ​​and function identifiers. In some embodiments, the processing device that extracts the hash values ​​and functions to the memory in box 808 can be a processor and / or a hardwired reset code.

[0094] In response to determining that the secure execution environment is not an enabled feature of the processor (i.e., determination block 802 = "No"), in response to determining that the cryptographic program header or fragment for the hash value and function is not present in memory, or after fetching the hash value and function to memory in block 808, in block 810, the processing device may execute a reset handler (e.g., reset handler 604). In some embodiments, the processing device executing the reset handler in block 810 may be a processor.

[0095] Fig. 9 1 illustrates a method 900 for booting a processor to implement a secure execution environment that may be executed by a processing device of a computing device according to an embodiment. The method 900 may be performed in a computing device (e.g., computing device 100), in hardware (e.g., processor core 702, hash generation hardware 706, temporary hash storage hardware 708, secure execution environment dedicated memory 710, hash comparator hardware 712, Figure 1 104 and processor 124 in the CPU ... Figure 1 The method 900 is implemented in a combination of dedicated hardware (e.g., secure execution environment 700) including memory 106 and 114 in the SEE 106 and 114 and various memory / cache controllers in the SEE 106 and 114 ...

[0096] In determination block 902, the SEE device may determine whether there is a processor (eg, processor core 702, Figure 1 The SEE device may receive a decoded instruction of a function to be executed in the processor. One such instruction (which may be the first instruction received by the SEE device during execution of the function by the processor) may be a start hash instruction. In response to receiving a start hash instruction from the processor, the SEE device may determine that there is a start hash instruction for the function to be executed in the processor. In response to receiving an instruction that does not include a start hash instruction, such as not receiving a start hash instruction as the first instruction or not receiving a start hash instruction after a specified number of instructions, the SEE device may determine that there is no start hash instruction for the function to be executed in the processor. In some embodiments, the SEE device that determines in determination block 902 whether there is a start hash instruction for the function to be executed in the processor may be a processor (e.g., processor core 702, Figure 1104 and processor 124) and / or hash generation hardware (e.g., hash generation hardware 706).

[0097] In response to determining that there is a start hash instruction for a function executed in the processor (i.e., determination block 902 = "yes"), in block 904, the SEE device may generate a hash value for the instruction of the function executed in the processor. When executing the function, the SEE device may receive instructions from the processor for execution in the processor. The SEE device may be pre-configured with a hash algorithm that can be used to generate a hash value for the received instruction of the function executed in the processor. In some embodiments, the SEE device that generates a hash value for the instruction of the function executed in the processor in block 904 may be a processor and / or hash generation hardware.

[0098] In block 906, the SEE device may store the hash value of the instruction for the function executed in the processor to a temporary storage (eg, temporary hash storage hardware 708, Figure 1 The temporary memory may include any memory accessible to the processor, including memory accessible only by the processor, such as a dedicated partition of memory, and / or memory accessible only by processor hardware. The hash may be stored in any organization known to the SEE device for comparison with other hash values ​​further described herein. For example, the hash values ​​may be stored in the order in which the hash values ​​were generated or in the reverse order, in ascending or descending order, etc. In some embodiments, the SEE device that stores the hash values ​​of the instructions for the function executed in the processor to the temporary memory in box 906 may be a processor, hash generation hardware, and / or temporary hash storage hardware (e.g., temporary hash storage hardware 708).

[0099] In determination block 908, the SEE device may determine whether to terminate the generation of hash values ​​for the instructions of the function executed in the processor. The function may include a stop hash instruction, and the SEE device may receive a stop hash function from the processor that reaches the stop hash instruction during the execution of the function. The stop hash instruction may cause the SEE device to stop generating hash values ​​for the instructions of the function executed in the processor. The stop hash instruction may cause the SEE device to stop generating hash values ​​for the instructions after the pop-up instruction for managing the data of the stack. In other words, the hash value of the pop-up instruction may be generated before the instruction generation of hash values ​​for the function executed in the processor is stopped. The SEE device that determines whether to terminate the generation of hash values ​​for the instructions of the function executed in the processor in determination block 908 may be a processor and / or hash generation hardware.

[0100] In response to determining that the generation of hash values ​​for the instructions of the function executed in the processor is not finished (i.e., determination block 908 = "No"), in block 904, the SEE device may again generate hash values ​​for the instructions of the function executed in the processor. The SEE device may receive subsequent instructions for the function executed in the processor and generate hash values ​​for the subsequent instructions. In some embodiments, the SEE device that generates hash values ​​for the instructions of the function executed in the processor in block 904 may be a processor and / or hash generation hardware.

[0101] In response to determining that the hash value generation for the instruction of the function executed in the processor has ended (i.e., determination block 908 = "Yes"), the SEE device may retrieve the hash value for the function executed in the processor from a specified memory (e.g., secure execution environment dedicated memory 710). The specified memory may be a secure execution environment dedicated memory, which may include any memory accessible to the processor, including memory that is only accessible by the processor, such as a dedicated partition of the memory, and / or memory that is only accessible by the processor hardware. The specified memory may store decrypted hash values ​​and functions, which may include hash values ​​stored in association with each other and function identifiers of the functions of these hash values. The association may be based on the format and / or structure of the data of the hash value and the function identifier. The SEE device may retrieve a hash value associated with the function executed in the processor. For example, the SEE device may receive a function identifier of the function from the processor and retrieve a hash value associated with the function identifier. In some embodiments, the SEE device that retrieves the hash value for the function executed in the processor from the designated memory in box 910 can be a processor, hash generation hardware and / or hash comparator hardware (e.g., hash comparator hardware 712).

[0102] In frame 912, SEE equipment can compare the hash value of the function from the specified memory with the hash value generated for the instruction of the function executed in the processor from the temporary memory. SEE equipment can compare these hash values ​​to determine whether they match. For example, SEE equipment can compare hash result values ​​to determine whether they are identical. SEE equipment can compare hash result values ​​in any order, which enables SEE equipment to compare the hash value of the same instruction from the specified memory with the hash value generated from the function executed in the processor. In some embodiments, the SEE equipment that compares the hash value of the function from the specified memory with the hash value generated for the instruction of the function executed in the processor from the temporary memory in frame 912 can be a processor and / or hash comparator hardware.

[0103] In frame 914, the SEE device can determine whether the hash value of the function from the specified memory matches the hash value generated for the instruction of the function being executed. According to the comparison in frame 912, the SEE device can determine whether the hash value matches. If the result of this comparison is that all hash values ​​match, then the execution safety of the function can be indicated. If the result of this comparison is that there is any unmatched hash value, then the execution of the function can be indicated to be unsafe. In some embodiments, the SEE device that determines whether the hash value of the function from the specified memory matches the hash value generated for the instruction of the function being executed in determination frame 914 can be a processor and / or hash comparator hardware.

[0104] In response to the SEE device determining that the hash value of the function from the specified memory matches the hash value generated for the instruction of the function being executed (i.e., determining block 914 = "yes"), in block 916, the SEE device may trigger the reset of the SEE device. The SEE device may signal and implement the dumping of data for the function executed in the processor. For example, the SEE device may dump data for generating hash values, data stored in temporary storage, and / or data for comparing hash values. For another example, the SEE device may reset the state of a component or part of the SEE device for generating hash values, storing data in temporary storage, and / or comparing these hash values. In some embodiments, the SEE device that triggers the reset of the SEE device in block 916 may be a processor and / or hash comparator hardware.

[0105] In response to determining that there is no start hash instruction for the function executed in the processor (i.e., determination block 902 = "No"), or in response to the SEE device determining that the hash value of the function from the specified memory does not match the hash value generated for the instruction of the function being executed (i.e., determination block 914 = "No"), in block 918, the SEE device may issue an exception. The SEE device may issue an exception to the processor executing the function. The exception may indicate to the processor that the execution of the function is unsafe, which may trigger the processor to handle the unsafe function execution. For example, the processor may dump the data generated by the execution of the function, thereby preventing another function or output from the processor from using the data. In some embodiments, the SEE device that issues an exception in block 918 may be a processor and / or hash comparator hardware.

[0106] In some embodiments, frame 910-918 can be implemented in parallel with frame 904-908.Therefore, frame 910-918 can be implemented before the instruction generation hash value for the function executed in the processor is terminated, rather than waiting for the instruction generation hash value for the function executed in the processor to be terminated.For example, frame 910-918 can be implemented for each hash value when the instruction generation hash value for the function executed in the processor is generated, until the hash value of the last instruction is generated, the hash value of the last instruction can be determined in a manner similar to the manner described in frame 908 herein.Some such embodiments can abandon frame 906, and in frame 912, SEE equipment can compare the hash value of the function from the specified memory with the hash value generated when the instruction generation hash value for the function executed in the processor is generated.In some such embodiments, frame 916 can be implemented after the hash value of the last instruction is generated, and the hash value of the last instruction can be determined in a manner similar to the manner described in frame 908 herein.

[0107] According to various embodiments (including but not limited to the above reference Figures 1 to 9 The system of the embodiments described herein can be implemented in a variety of computing systems including mobile computing devices. An example of a mobile computing device suitable for use with various embodiments is Fig.10 1000. The mobile computing device 1000 may include a processor 1002 coupled to a touch screen controller 1004 and an internal memory 1006. The processor 1002 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 1006 may be a volatile or non-volatile memory, and may also be a secure and / or encrypted memory, or an unsecure and / or unencrypted memory, or any combination thereof. Examples of memory types that may be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touch screen controller 1004 and the processor 1002 may also be coupled to a touch screen panel 1012, such as a resistive sensing touch screen, a capacitive sensing touch screen, an infrared sensing touch screen, and the like. In addition, the display of the mobile computing device 1000 does not need to have touch screen capabilities.

[0108] The mobile computing device 1000 may have one or more radio signal transceivers 1008 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radios) coupled to each other and / or to the processor 1002 and an antenna 1010 for transmitting and receiving communications. The transceiver 1008 and antenna 1010 may be used with the circuits mentioned above to implement various wireless transmission protocol stacks and interfaces. The mobile computing device 1000 may include a cellular network wireless modem chip 1016 that enables communication via a cellular network and is coupled to the processor.

[0109] The mobile computing device 1000 may include a peripheral device connection interface 1018 coupled to the processor 1002. The peripheral device connection interface 1018 may be configured solely to accept one type of connection, or may be configured to accept various types of physical and communication connections that are shared or proprietary, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 1018 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0110] The mobile computing device 1000 may also include a speaker 1014 for providing audio output. The mobile computing device 1000 may also include a housing 1020 for housing all or some of the components described herein, the housing being constructed of plastic, metal, or a combination of materials. The mobile computing device 1000 may include a power source 1022 coupled to the processor 1002, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive a charging current from a source external to the mobile computing device 1000. The mobile computing device 1000 may also include a physical button 1024 for receiving user input. The mobile computing device 1000 may also include a power button 1026 for turning the mobile computing device 1000 on and off.

[0111] According to various embodiments (including but not limited to the above reference Figures 1 to 9 The system of the embodiment described in the present invention can be implemented in a variety of computing systems including a laptop computer 1100, an example of which is shown in FIG. Fig.1111. Many laptop computers include a touchpad touch surface 1117 that serves as a pointing device for the computer and can therefore receive drag, scroll, and tap gestures similar to those implemented on computing devices equipped with a touch screen display and as described above. The laptop computer 1100 will typically include a processor 1102 coupled to a volatile memory 1112 and a disk drive 1113 of a large capacity non-volatile memory such as flash memory. In addition, the computer 1100 may have one or more antennas 1108 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link, and / or a cellular telephone transceiver 1116 coupled to the processor 1102. The computer 1100 may also include a floppy disk drive 1114 and a compact disk (CD) drive 1115 coupled to the processor 1102. In a notebook configuration, the computer housing includes a touchpad 1117, a keyboard 1118, and a display 1119, all coupled to the processor 1102. Other configurations of computing devices may include a computer mouse or trackball coupled to a processor (eg, via USB input) as is well known, which may also be used in conjunction with various embodiments.

[0112] According to various embodiments (including but not limited to the above reference Figures 1 to 9 The system of the described embodiments) may also be implemented in a fixed computing system, such as any of a variety of commercially available servers. Fig.12 An example server 1200 is illustrated in FIG. Such a server 1200 typically includes one or more multi-core processor assemblies 1201 coupled to a volatile memory 1202 and a large capacity non-volatile memory (such as a disk drive 1204). Fig.12 As shown, a multi-core processor assembly 1201 can be added to a server 1200 by inserting it into a chassis of the assembly. The server 1200 may also include a floppy disk drive, a compact disk (CD), or a digital versatile disk (DVD) disk drive 1206 coupled to the multi-core processor assembly 1201. The server 1200 may also include a network access port 1203 coupled to the multi-core processor assembly 1201 for establishing a network interface connection with a network 1205, such as a local area network coupled to other broadcast system computers and servers, the Internet, a public switched telephone network, and / or a cellular data network (e.g., CDMA, TDMA, GSM, PCS, 3G, 4G, LTE, 5G, or any other type of cellular data network).

[0113] Specific implementation examples are described in the following paragraphs. Although some of the following specific implementation examples are described in terms of example methods, other example implementations may include: the example methods discussed in the following paragraphs implemented in a computing device, the computing device including a processing device configured with processing device executable instructions for performing the operations of the example methods; the example methods discussed in the following paragraphs implemented in a computing device, the computing device including a hash generator, a hash comparator, and / or a processor configured to perform the operations of these example methods; the example methods discussed in the following paragraphs implemented in a computing device, the computing device including a component for performing the functions of the example methods; and the example methods discussed in the following paragraphs implemented as a non-transitory processor-readable storage medium having processor executable instructions stored thereon, the processor executable instructions being configured to cause a processor of the computing device to perform the operations of the example methods.

[0114] Embodiment 1. A computing device method for generating a binary executable file for execution in a secure execution environment, the method comprising: generating a hash value of an instruction of a function, inserting a start hash instruction and a stop hash instruction into a target code of the function, and generating a binary executable file having the function including the start hash instruction and the stop hash instruction.

[0115] Embodiment 2. The method according to embodiment 1, wherein inserting the start hash instruction and the stop hash instruction into the target code of the function comprises: inserting the start hash instruction into the prologue of the function, and inserting the stop hash instruction into the epilogue of the function.

[0116] Embodiment 3. The method according to any one of Embodiments 1 or 2 further includes: encrypting a program header of the hash value of the instruction for the function, and storing the encrypted program header of the hash value of the instruction for the function in a dedicated memory.

[0117] Embodiment 4. The method according to any one of embodiments 1 to 3 further includes: using a software development tool chain to receive an indication of a hash algorithm, wherein generating the hash value of the instruction of the function may include using the indicated (i.e., identified in the indication of the hash algorithm) hash algorithm to generate the hash value of the instruction of the function.

[0118] Embodiment 5. The method according to any one of embodiments 1 to 4 further includes: using a software development tool chain to receive a private key, and using an encryption algorithm and the private key to encrypt a program header of the hash value of the instruction for the function.

[0119] Embodiment 6. The method according to any one of embodiments 1 to 5 further includes: using a software development tool chain to receive an indication of an encryption algorithm, and using the indicated (i.e., identified in the indication of the encryption algorithm) encryption algorithm to encrypt a program header of the hash value of the instruction for the function.

[0120] Embodiment 7. A method according to any one of embodiments 1 to 6, wherein generating the hash value of the instruction of the function includes using an assembler to generate the hash value of the instruction of the function, inserting the start hash instruction and the stop hash instruction into the target code of the function may include using the assembler to insert the start hash instruction and the stop hash instruction into the target code of the function, and generating the binary executable file having the function including the start hash instruction and the stop hash instruction includes using a linker to generate the binary executable file having the function including the start hash instruction and the stop hash instruction.

[0121] Embodiment 8. A method for executing in a secure execution environment of a processor at runtime to maintain the secure execution environment, the method comprising: generating a hash value of the instructions of the function in parallel when executing the function, comparing the generated hash value of the instructions of the function with the stored hash value of the instructions of the function, and issuing an exception, the exception indicating to the processor that the execution of the function is unsafe due to any difference between the generated hash value of the instructions of the function and the stored hash value of the instructions of the function.

[0122] Embodiment 9. The method according to embodiment 8 further includes: determining whether there is a start hash instruction for the function, wherein generating the hash value of the instruction of the function in parallel when executing the function includes: generating the hash value of the instruction of the function in response to determining that there is the start hash instruction for the function, and issuing an exception in response to determining that there is no start hash instruction for the function, wherein the exception indicates to the processor that the execution of the function is unsafe.

[0123] Embodiment 10. The method according to any one of Embodiments 8 or 9 further includes: determining whether to end generating the hash value of the instruction of the function based on reaching a stop hash instruction for the function, wherein in response to determining to end generating the hash value of the instruction of the function, the generated hash value of the instruction of the function is compared with the stored hash value of the instruction of the function.

[0124] Embodiment 11. The method according to any one of embodiments 8 to 10 further includes: determining whether the secure execution environment is enabled for the processor, wherein the hash value of the instruction of the function is generated in parallel when executing the function in response to determining that the secure execution environment is enabled for the processor.

[0125] Embodiment 12. The method according to any one of embodiments 8 to 12 further includes: decrypting an encrypted and stored program header of a hash value of the instruction for the function, thereby generating a decrypted program header of the hash value of the instruction for the function, and retrieving the stored hash value of the instruction for the function from a dedicated memory based on the decrypted program header of the hash value of the instruction for the function.

[0126] Embodiment 13. The method according to embodiment 12 further includes: determining whether the encrypted and stored program header of the hash value of the instruction of the function exists in the dedicated memory, wherein the encrypted and stored program header of the hash value of the instruction of the function is decrypted in response to determining that the encrypted and stored program header of the hash value of the instruction of the function exists in the dedicated memory.

[0127] Computer program code or "program code" for executing on a programmable processor to perform the operations of the various embodiments can be written in a high-level programming language (such as C, C++, C#, Smalltalk, Java, JavaScript, VisualBasic), a structured query language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or programs stored on a computer-readable storage medium as used in the present application can refer to machine language code (such as, object code) whose format can be understood by a processor.

[0128] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter", "then", "next", etc. are not intended to limit the order of operations; these words are only used to guide the reader to read the description of the method. In addition, any reference to a claim element in the singular form (e.g., a reference using the article "one", "an", or "said") should not be interpreted as limiting the element to the singular.

[0129] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with the various embodiments may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Although the technician may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as departing from the scope of the claims.

[0130] The hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein can be implemented or executed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic, a discrete hardware component, or any combination thereof designed to perform the functions described herein. Although a general-purpose processor can be a microprocessor, in an alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods can be performed in circuits specific to a given function.

[0131] In one or more embodiments, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, each function can be stored as one or more instructions or codes on a non-transient computer-readable medium or a non-transient processor-readable medium. The operation of the method or algorithm disclosed herein can be implemented in a processor executable software module, which can reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium can be any storage medium that can be accessed by a computer or a processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination is also included in the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0132] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the universal principles defined herein may be applied to other embodiments and implementations without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for generating a binary executable file for execution in a secure execution environment, the method comprising: Generate the hash value of the function's instructions; inserting a start hash instruction and a stop hash instruction into the object code of the function; as well as A binary executable file having the function including the start hash instruction and the stop hash instruction is generated.

2. The method of claim 1 , wherein inserting the start hash instruction and the stop hash instruction into the object code of the function comprises: inserting the start hash instruction in the prologue of the function; as well as The stop hashing instruction is inserted at the end of the function.

3. The method according to claim 1, further comprising: encrypting a program header of the hash value of the instruction for the function; as well as An encrypted program header of the hash value for the instruction of the function is stored in dedicated memory.

4. The method according to claim 1, further comprising: An indication of a hash algorithm is received using a software development tool chain, wherein generating the hash value of the instructions of the function includes generating the hash value of the instructions of the function using the indicated hash algorithm.

5. The method according to claim 1, further comprising: Use the software development toolchain to receive the private key; as well as A program header of the hash value of the instruction for the function is encrypted using an encryption algorithm and the private key.

6. The method according to claim 1, further comprising: Using a software development tool chain to receive instructions for encryption algorithms; as well as A program header of the hash value of the instructions for the function is encrypted using the indicated encryption algorithm.

7. The method according to claim 1, wherein Generating the hash value of the instructions of the function includes using an assembler to generate the hash value of the instructions of the function; Inserting the start hash instruction and the stop hash instruction in the object code of the function includes using the assembler to insert the start hash instruction and the stop hash instruction in the object code of the function; and Generating the binary executable file having the function including the start hash instruction and the stop hash instruction includes using a linker to generate the binary executable file having the function including the start hash instruction and the stop hash instruction.

8. A computing device, comprising: Memory; and a processor coupled to the memory and configured to: Generate the hash value of the function's instructions; inserting a start hash instruction and a stop hash instruction into the object code of the function; and A binary executable file having the function including the start hash instruction and the stop hash instruction is generated.

9. The computing device of claim 8, wherein the processor is further configured to cause the processor to insert the start hash instruction and the stop hash instruction into the object code of the function in the following manner: inserting the start hash instruction in the prologue of the function; and The stop hashing instruction is inserted at the end of the function.

10. The computing device of claim 8, wherein the processor is further configured to: encrypting a program header of the hash value of the instruction for the function; and An encrypted program header of the hash value for the instruction of the function is stored in the memory.

11. The computing device of claim 8, wherein the processor is further configured to: Receiving an indication of a hash algorithm at a software development tool chain; and The hash value of the instruction of the function is generated using the indicated hash algorithm.

12. The computing device of claim 8, wherein the processor is further configured to: Receiving a private key at a software development toolchain; and A program header of the hash value of the instruction for the function is encrypted using an encryption algorithm and the private key.

13. The computing device of claim 8, wherein the processor is further configured to: Receiving an indication of an encryption algorithm at a software development tool chain; and A program header of the hash value of the instructions for the function is encrypted using the indicated encryption algorithm.

14. The computing device of claim 8, wherein the processor is further configured to: generating, using an assembler, the hash value of the instructions of the function; inserting the start hash instruction and the stop hash instruction in the object code of the function using the assembler; and A linker is used to generate the binary executable file having the function including the start hash instruction and the stop hash instruction.

15. A method for executing in a secure execution environment of a processor at runtime to maintain the secure execution environment, the method comprising: generating hash values ​​of instructions of the function in parallel while executing the function; comparing the generated hash value of the instruction of the function with the stored hash value of the instruction of the function; as well as An exception is raised, the exception indicating to the processor that execution of the function is unsafe due to any difference between the generated hash value of the instructions of the function and the stored hash value of the instructions of the function.

16. The method according to claim 15, further comprising: determining whether there is a start hash instruction for the function, wherein generating the hash value of the instruction of the function in parallel while executing the function comprises: generating the hash value of the instruction of the function in response to determining that there is the start hash instruction for the function; and In response to determining that the start hash instruction is not present for the function, an exception is raised, the exception indicating to the processor that execution of the function is unsafe.

17. The method according to claim 15, further comprising: A determination is made whether to end generating the hash value for the instructions of the function based on reaching a stop hash instruction for the function, wherein the generated hash value for the instructions of the function is compared with the stored hash value for the instructions of the function in response to determining to end generating the hash value for the instructions of the function.

18. The method according to claim 15, further comprising: A determination is made as to whether the secure execution environment is enabled for the processor, wherein the hash value of the instructions of the function is generated in parallel while executing the function in response to a determination that the secure execution environment is enabled for the processor.

19. The method according to claim 15, further comprising: decrypting the encrypted and stored program header of the hash value of the instructions for the function to generate a decrypted program header of the hash value of the instructions for the function; as well as The stored hash value of the instruction of the function is retrieved from dedicated memory based on the decrypted program header for the hash value of the instruction of the function.

20. The method according to claim 19, further comprising: determining whether the encrypted and stored program header for the hash value of the instructions of the function is present in the dedicated memory, wherein the encrypted and stored program header for the hash value of the instructions of the function is decrypted in response to determining that the encrypted and stored program header for the hash value of the instructions of the function is present in the dedicated memory.

21. A computing device, the computing device comprising: processor; a hash generator connected to the processor and configured to generate hash values ​​for instructions of the function in parallel as the processor executes the function; and a hash comparator coupled to the processor and configured to: comparing the generated hash value of the instruction of the function with the stored hash value of the instruction of the function; as well as An exception is raised, the exception indicating to the processor that execution of the function is unsafe due to any difference between the generated hash value of the instructions of the function and the stored hash value of the instructions of the function.

22. The computing device of claim 21, wherein: The hash generator is further configured to: determining whether there is a start hash instruction for the function; and generating the hash value of the instruction of the function in response to determining that the start hash instruction for the function exists; and The hash comparator is further configured to raise an exception in response to determining that the start hash instruction for the function is not present, the exception indicating to the processor that execution of the function is unsafe.

23. The computing device of claim 21, wherein: The hash generator is further configured to: determine whether to end generating the hash value of the instruction of the function based on reaching a stop hash instruction for the function; and The hash comparator is further configured to compare the generated hash value of the instruction of the function with the stored hash value of the instruction of the function in response to determining that generating the hash value of the instruction of the function is finished.

24. The computing device of claim 21, wherein: The processor is configured to determine whether the secure execution environment is enabled for the processor; and The hash generator is further configured to generate the hash value of the instructions of the function in parallel while executing the function in response to determining that the secure execution environment is enabled for the processor.

25. The computing device of claim 21, wherein the processor is configured to: decrypting the encrypted and stored program header of the hash value of the instructions for the function to generate a decrypted program header of the hash value of the instructions for the function; and The stored hash value of the instruction of the function is retrieved from dedicated memory based on the decrypted program header for the hash value of the instruction of the function.

26. The computing device of claim 25, wherein the processor is further configured to: causing the processor to determine whether the encrypted and stored program header for a hash value of the instruction of the function is present in the dedicated memory; and The encrypted and stored program header of the hash value of the instructions for the function is decrypted in response to determining that the encrypted and stored program header of the hash value of the instructions for the function is present in the dedicated memory.

Images