WO2023001366A1

WO2023001366A1 - Device and method for protecting code integrity

Info

Publication number: WO2023001366A1
Application number: PCT/EP2021/070236
Authority: WO
Inventors: Qiming Li; Kui Wang
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-07-20
Filing date: 2021-07-20
Publication date: 2023-01-26

Abstract

The present disclosure relates to methods and devices for protecting a native code, in particular a dynamically generated native code. The dynamically generated native code is generated by a compiler (103) based on a bytecode provided by an interpreter (105). A protection device (101) is configured to communicate with the compiler (103) and the interpreter (105). In particular, during a compilation of the bytecode, the protection device (101) receives each generated native instruction from the compiler and generates protection information based on each generated native instruction, optionally by using a cryptographic algorithm. When the compilation is finished, the protection device (101) locks the protection information, which is used to verify the integrity of the native code before its execution.

Description

DEVICE AND METHOD FOR PROTECTING CODE INTEGRITY

TECHNICAL FIELD

The present disclosure relates to devices and methods for protecting integrity of executable code in the field of computer technology. In particular, the disclosure relates to a protection device and a method for generating protection information during a dynamic code compilation.

BACKGROUND

In some programming languages, a source code is not directly compiled into a native code (also known as an executable code or a machine code). That is, a source code is not entirely pre compiled before execution. Instead, a bytecode comprising instructions that are hardware- independent is firstly generated. The bytecode is also known as an intermediate representation (IR), and the instructions comprised in bytecode are also known as IR instructions. When a function of the source code is called during execution, the bytecode is sent to a virtual machine or to an interpreter, and is translated into a native code. The translated native code is executable by a processor, e.g., a central processing unit (CPU). Examples of such programming languages include, but are not limited to, Java, Python, JavaScript, and C#.

To improve the performance and to reduce on-the-fly interpretation overhead of the above- mentioned process, functions may be categorized at different optimization levels. For instance, depending on the number of executions, functions may be categorized as cold and hot. For a hot function (also known as hot method) that is called more frequent than a cold function, a compiler can be employed to compile the hot function into a native code. When the hot function is called again, the native code is directly executed instead of interpreting the corresponding bytecode. This compiler is also known as a just-in-time (JIT) compiler, and a JIT compilation is also known as a dynamic compilation or translation. The JIT compilation is widely used, such as in web browsers and on mobile devices. An example of the JIT compilation is illustrated in FIG.7. In particular, FIG. 7 depicts that a source code is “interpreted” into a bytecode. Then this bytecode is compiled into a machine code.

Code integrity is a security property of a computer program or a native code, which assures that the computer program or the native code is not modified in unauthorized ways. To ensure code integrity of the native code, various methods may be used. For example, a writable shadow memory region may be allocated and used during the compilation. During the compilation, an output is firstly stored in the shadow memory region. Once the compilation is complete, the final output, i.e., the compiled native code, is then copied to an actual memory region where it is configured as read-and-executable only. The shadow memory region is allocated in a manner that is more difficult to be guessed than the actual memory region. A reason behind this method is that memory copy is much faster than code compilation. Therefore, an attacker is less likely to alter or tamper with the compiled native code that is stored in the shadow memory region and is copied from the shadow memory region to the actual memory region.

Alternatively, an out-of-process compilation may be used to ensure code integrity. In particular, a dedicated compile server is employed. When a main process (also known as a content process) needs to compile a piece of bytecode, it sends the bytecode to the dedicated compile server, and receives an address of a memory region that is mapped read-and-execute in its process address space. This memory region is in fact shared between the content process and the dedicated compile server, and is mapped read-write in an address space of the dedicated compile server.

In this way, the dedicated compile server can freely write the compiled native code into the shared memory, but the memory content is not modifiable from the content process. As a result, the vulnerable time window where the code memory region is writable can be avoided entirely in the content process.

SUMMARY

One problem of the conventional methods to ensure code integrity is that vulnerabilities still exist. In particular, regarding the method using the shadow memory region, there are at least three vulnerabilities. One vulnerability is that a location of the shadow memory region is not always difficult to guess, especially when there is another data-leak vulnerability that allows the attacker to obtain critical information from the memory or CPU registers. A second vulnerability is that, although there is only a small time window to launch an attack during the memory copy, it does not mean that it is absolutely not exploitable. A third vulnerability is that this method fails to deal with a type of attach that memory content is modified outside of a program process. That is, if memory corruption happens outside the program process, the method cannot detect such code corruption because of the memory corruption. For the method using the dedicated compile server, one disadvantage is that the method requires additional units to manage the shared memory, in order to map memory pages correctly in each process and to ensure that the correctness of inter-process communication. The presence of additional units leads to additional attack possibilities that can be exploitable. Another disadvantage is that, similar to the method using the shadow memory region, this method cannot detect code corruption because of the memory corruption that happens outside the program process.

In view of the above-mentioned problems and disadvantages, embodiments of the invention aim to improve code integrity protection of a compiled code, in particular of a dynamically generated code.

These and other objectives are achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

An idea described in the present disclosure with respect to the embodiments, is to use a trusted third party to ensure the integrity of the compiled code, instead of imposing access control of the memory.

A first aspect of the present disclosure provides a device for protecting a native code generated by a compiler. In particular, the native code comprises a set of instructions generated by the compiler based on a compilation of a bytecode. The device is configured to perform the following steps: receive, from the compiler, indication information indicating a start of the compilation of the bytecode, initialize protection information; obtain, from the compiler, each instruction generated during the compilation of the bytecode;

- update the protection information based on the obtained instruction; lock the protection information when the compilation of the bytecode is finished; wherein the device is further configured to, in response to a verification request received from an interpreter: obtain the native code from a memory region;

- verify the protection information related to the native code; and provide a verification result to the interpreter.

In particular, the compilation may be a JIT compilation.

Optionally, for initializing the protection information, the device may assign a null value for the protection information, or may assign a storage space for the protection information. Then, the device may update the protection information once the device obtains from the compiler any instruction, e.g., a first instruction, generated during the compilation of the bytecode. Moreover, each instruction generated during the compilation of the bytecode may be a machine instruction.

Optionally, for updating the protection information based on the obtained instruction, the device may be configured to employ an algorithm that maps input data of arbitrary size to output data of fixed size in one way that is practically infeasible to invert or reverse the mapping.

Optionally, the memory region may be a storage location that may be assigned by a main processor or the interpreter to store the compiled native code in a memory. Further, the memory may be a shared memory among the device, the compiler, and the interpreter. The memory region may be indicated and accessed by a memory address that may be commonly known among the device, the compiler, and the interpreter.

Moreover, the device may be configured to perform the steps of verification only in response to the receiving of the verification request from the interpreter. That is, the device may be configured not to perform the steps of obtaining the native code, verifying the protection information, and providing the verification result, if no verification request is received from the interpreter. Nevertheless, the device locks the protection information and may store the protection information, so that the device may be ready to verify the protection information in response to any received verification request at any time.

Moreover, it is noted that the bytecode may be generally referred to as a non-executable code, whereas the native code may be generally referred to as an executable code. Moreover, all the codes in the present disclosure, including but not limited to, the bytecode, the native code, the non-executable code, may be a code segment.

In this way, non- forgettable protection information may be generated during the compilation and may be used to validate the integrity of the compiled code, i.e., native code. Since the generated protection information is locked and the native code is retrieved from the memory region and validated against the protection information, there is no writable window that could cause memory region corruption. As a result, it is more resistant to memory errors and exploitations.

In an implementation form of the first aspect, the indication information may comprise a request to generate the protection information for the compilation of the bytecode.

In particular, the device may determine whether to generate the protection information for different native codes with different security levels. For example, if a to-be-generated native code is related to a system process, then the device may indicate, by comprising the request, to generate the protection information. If the to-be-generated native code is related to a user process, then the device may indicate, by not comprising the request, not to generate the protection information. Alternatively, the request information may also be a bit value indicating whether or not to generate the protection information.

In this way, the protection information may be generated on demand and the flexibility for verifying the native code may be increased.

In another implementation form of the first aspect, for initializing and updating the protection information, the device may be configured to employ one or more of the following: a checksum algorithm; a hashing algorithm; a message authentication code algorithm; and a digital signature.

In particular, for different native codes with different security levels, the device may determine to use one or more of the above-mentioned algorithms independently or collaboratively. Moreover, the device may predetermine one or more of the above-mentioned algorithms. That is, the device may use a fixed method based on the one or more of the above-mentioned algorithms to generate the protection information until it is configured otherwise.

Alternatively, the device may also dynamically determine to use one or more of the above- mentioned algorithms to generate the protection information. That is, for different native codes, different algorithms may be used.

In this way, the protection information may be generated based on different security requirements, and the flexibility for verifying the native code may be increased.

In another implementation form of the first aspect, the protection information may comprise an identifier associated with the native code.

In this way, the device may efficiently index the generated protection information based on the identifier.

In another implementation form of the first aspect, the protection information may comprise algorithm information indicating one or more algorithms used to generate the protection information.

In particular, the device may designate a specific value for a particular algorithm used for generating the protection information.

In this way, it is more convenient for the device to determine the algorithm that has been used to generate the protection information when verifying a to-be-executed native code.

In another implementation form of the first aspect, the device may be further configured to: receive, from the interpreter, a further verification request to verify a previously compiled native code, obtain the previously compiled native code from the memory region; and - verify previously generated protection information related to the previously compiled native code. In particular, any protection information that is generated and locked may be stored by the device so that the previously compiled native code may be validated when it is executed multiple times.

Optionally, the device may retrieve the previously generated protection information according to the previously compiled native code.

Optionally, the memory region may be a corresponding memory region where the previously compiled native code is stored. The device may obtain the previously compiled native code from the corresponding memory region.

Optionally, for verifying the previously generated protection information, the device may generate to-be-compared protection information based on the previously compiled native code obtained from the memory region by using the same algorithm for generating the previously generated protection information. Then, the device may compare the to-be-compared protection information with the previously generated protection information. In case of a match, the device may send a positive verification result. In case of a mismatch, the device may send a negative verification result.

In this way, the device may be able to detect such code corruption because of the memory corruption. Therefore, the reliability and safety for verifying the native code may be increased.

In another implementation form of the first aspect, the device may be a secure cryptoprocessor.

Optionally, the secure cryptoprocessor may be, or may be incorporated in one of the following modules: one of the following hardware: a trusted execution environment (TEE) module, secure element (SE), trusted platform module (TPM), trusted cryptographic module (TCM), secure enclave, hardware security module (HSM), and the like.

In this way, the device may be fended off physical attacks and side-channel attacks. Therefore, the security level of the device may be increased.

In another implementation form of the first aspect, the device may be further configured to secure communications between the compiler and the interpreter. In particular, the communication between any two of the device, the compile, and the interpreter may be encrypted.

Optionally, the device may be configured with a secure on-chip communication architecture.

In this way, attacks on communication links may be further mitigated. Therefore, the security level of the device may be further increased. The reliability and safety for verifying the native code may be increased as well.

A second aspect of the present disclosure provides a compiler configured to: obtain, from an interpreter, a bytecode; compile the bytecode into a native code comprising a set of instructions; send indication information to a device for protecting the native code, wherein the indication information is indicative of a start of a compilation of the bytecode; provide each instruction generated during the compilation to the device; and inform the device and the interpreter of a completion of the compilation.

Optionally, for obtaining the bytecode, the compiler may obtain an address of the bytecode from the interpreter. The address may be a memory address or a storage address where the bytecode is located. Then, the compiler may obtain the bytecode according to the address.

Further, the bytecode may comprise a set of functions. The function may also be referred to as an IR instruction. The compiler may compile each function into a set of instructions. Each compiled instruction may be, in particular, a machine instruction. The machine instruction may comprise several bytes that instruct a processor to perform a particular machine task, such as a load, a store, a jump, or an arithmetic logic unit (ALU) operation on one or more units of data in one or more processor registers or memory.

In an implementation form of the second aspect, the indication information may comprise a request to generate the protection information for the compilation of the bytecode.

In another implementation form of the second aspect, the compiler may be further configured to secure communications between the device and the interpreter. A third aspect of the present disclosure provides an interpreter configured to: provide a bytecode to a compiler for compilation;

- when the compilation is finished, mark a memory region corresponding to a compiled native code as readable, not writable, and not executable; send a request for verifying the compiled native code to a device for protecting the compiled native code; and mark the memory region as executable in response to a positive verification result from the device.

Optionally, before providing the bytecode to the compiler, the interpreter may mark the memory region as writable, not readable, and not executable.

By marking the memory region corresponding to the compiled native code as “readable, not writable, and not executable” after the compilation and before the verification, malicious acts may be prevented, and security of the compiled native code may be enhanced.

In an implementation form of the third aspect, the interpreter may be further configured to secure communications between the device and the compiler.

In another implementation form of the third aspect, the interpreter may be further configured to send a further verification request to the device to verify a previously compiled native code before executing the previously compiled native code. In this case, only when receiving a positive verification result from the device, the interpreter executes the previously compiled native code.

A fourth aspect of the present disclosure provides a method for protecting a native code generated by a compiler. The native code comprises a set of instructions generated by the compiler based on a compilation of a bytecode. The method is performed by a device and comprises the following steps: receiving, from the compiler, indication information indicating a start of the compilation of the bytecode, initializing protection information; obtaining, from the compiler, each instruction generated during the compilation of the bytecode;

- updating the protection information based on the obtained instruction; locking the protection information when the compilation of the bytecode is finished;

- wherein the method further comprises, in response to a verification request received from an interpreter: obtaining the native code from a memory region;

- verifying the protection information related to the native code; and providing a verification result to the interpreter.

In an implementation form of the fourth aspect, the indication information may comprise a request to generate the protection information for the compilation of the bytecode.

In another implementation form of the fourth aspect, for initializing and updating the protection information, the method comprises employing one or more of the following algorithms: a checksum algorithm; a hashing algorithm; a message authentication code algorithm; and a digital signature.

In another implementation form of the fourth aspect, the protection information may comprise an identifier associated with the native code.

In another implementation form of the fourth aspect, the protection information may comprise algorithm information indicating one or more algorithms used to generate the protection information.

In another implementation form of the fourth aspect, the method may further comprise: receiving, from the interpreter, a further verification request to verify a previously compiled native code, obtaining the previously compiled native code from the memory region; and

- verifying previously generated protection information related to the previously compiled native code. In another implementation form of the fourth aspect, the method may be performed by the device being a secure cryptoprocessor.

In another implementation form of the fourth aspect, the method may further comprise securing communications between the compiler and the interpreter.

A fifth aspect of the present disclosure provides a method for protecting a native code generated by a compiler. The method is executed by the compiler and comprises the following steps: obtaining, from an interpreter, a bytecode; compiling the bytecode into a native code comprising a set of instructions; sending indication information to a device for protecting the native code, wherein the indication information is indicative of a start of a compilation of the bytecode; providing each instruction generated during the compilation to the device; and informing the device and the interpreter of a completion of the compilation.

In particular, the compilation of the bytecode may be a continuous process. Therefore, the third step to the fifth step in the fifth aspect may be performed during an entire process of the second step.

In an implementation form of the fifth aspect, the indication information may comprise a request to generate the protection information for the compilation of the bytecode.

In another implementation form of the fifth aspect, the method may further comprise securing communications between the device and the interpreter.

A sixth aspect of the present disclosure provides a method for protecting a native code generated by a compiler. The method is executed by an interpreter and comprises the following steps: providing a bytecode comprising a set of functions to the compiler for a compilation;

- when the compilation is finished, marking a memory region corresponding to a compiled native code as readable, not writable, and not executable; sending a request for verifying the compiled native code to a device for protecting the compiled native code; and marking the memory region as executable in response to a positive verification result from the device. In an implementation form of the sixth aspect, the method may further comprise securing communications between the device and the compiler.

In another implementation form of the sixth aspect, the method further comprises: sending a further verification request to the device to verify a previously compiled native code before executing the previously compiled native code; and executing the previously compiled native code only when receiving a positive verification result from the device.

A seventh aspect of the present disclosure provides a computer program product comprising a program code for performing the method according to the fourth aspect or any implementation form thereof, when executed on a computer.

An eighth aspect of the present disclosure provides a computer program product comprising a program code for performing the method according to the fifth aspect or any implementation form thereof, when executed on a computer.

A ninth aspect of the present disclosure provides a computer program product comprising a program code for performing the method according to the sixth aspect or any implementation form thereof, when executed on a computer.

A tenth aspect of the present disclosure provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of the fourth aspect or any implementation form thereof.

An eleventh aspect of the present disclosure provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of the fifth aspect or any implementation form thereof.

A twelfth aspect of the present disclosure provides a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of the sixth aspect or any implementation form thereof. A thirteenth aspect of the present disclosure provides a chipset comprising instructions which, when executed by the chipset, cause the chipset to carry out the method according to any one of the fourth aspect or any implementation form thereof.

A fourteenth aspect of the present disclosure provides a chipset comprising instructions which, when executed by the chipset, cause the chipset to carry out the method according to any one of the fifth aspect or any implementation form thereof.

A fifteenth aspect of the present disclosure provides a chipset comprising instructions which, when executed by the chipset, cause the chipset to carry out the method according to any one of the sixth aspect or any implementation form thereof.

It has to be noted that all devices, elements, units, and means described in the present application could be implemented in software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity, which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a device, a compiler, and an interpreter, each according to an embodiment of the invention;

FIG. 2 shows a message flow diagram according to an embodiment of the invention;

FIG. 3 shows a device according to an embodiment of the invention; FIG. 4 shows a diagram of a method according to an embodiment of the invention;

FIG. 5 shows a diagram of another method according to an embodiment of the invention;

FIG. 6 shows a diagram of another method according to an embodiment of the invention; and

FIG. 7 shows an example of dynamically generating executable code.

DETAILED DESCRIPTION OF EMBODIMENTS

Terms used in the present disclosure have commonly accepted meanings in the field of computer science. For facilitating understanding of the embodiments of the invention, explanations are nevertheless given in the following.

“Source code” may be referred to as a high-level code comprising a set of computer instructions written using a human-readable programming language. In particular, the source code may be a code that is manually generated, i.e., by a programmer.

“Bytecode” may be referred to as a non-executable code, which may be generated by an interpreter from a source code. The bytecode may be an intermediate code or an IR code. Further, the bytecode is not a machine code for any particular hardware and is portable among different computer architectures, such as but not limited to, x86 and reduced instruction set computer (RISC) processors. Moreover, the bytecode may comprise a set of instructions that are designed for execution by the interpreter. The interpreter may also be referred to as a virtual machine, such as but not limited to a Java virtual machine or Python virtual machine.

“Native code” may be referred to as a machine code, which may comprise a set of executable machine language (i.e., binary) instructions. The native code may be a low-level code and may be directly executed by hardware, e.g., a processor or a CPU. In particular, each machine language instruction in the native code may cause the hardware to perform a specific task, such as but not limited to a load, store, jump, arithmetic logic unit operation. “Interpreter” may be referred to as a component that is configured to generate a bytecode based on a source code and execute the generated bytecode.

“Compiler” may be referred to as a component that is configured to generate a native code based on a bytecode.

An example of relationships between the source code, the bytecode, and the native code is given in FIG. 7, which also applies to the present disclosure. It is noted that the “parser”, “bytecode generator”, and “profiler” in FIG. 7 may be collaboratively referred to as the “interpreter” in the present disclosure.

It is noted that whether a code is “non-executable” or “executable” in the present disclosure may be determined (or defined) based on whether the code can be directly executed by hardware, i.e., without any further compilation, translation, or interpretation. That is, if a code can be directly executed by hardware, then this code shall be referred to as an executable code. Otherwise, the code is a non-executable code.

In FIG. 1-7, corresponding elements may share the same features and may function likewise.

FIG. 1 shows a system 100 according to an embodiment of the invention.

The system 100 is a compilation system, in particular, a JIT compilation system, and comprises an interpreter 105, a compiler 103, and a device 101 for protecting a native code generated by the compiler. The device 101 may be also referred to as a “protection device” in the present disclosure. Components of the system may be interconnected via a system bus. Moreover, a memory 107 may also be connected to the system bus. The memory 107 may be a shared memory.

Similar to the example given in FIG. 7, the interpreter 105 is configured to transform a source code into a bytecode. The compiler 103 is configured to transform the bytecode into a native code. The protection device 101 is configured to protect the native code.

Moreover, the interpreter 105 may generate the bytecode based on the source code in advance, i.e., before runtime. When a function is called in the runtime, the interpreter 105 may then provide a corresponding bytecode, or a corresponding bytecode segment, to the compiler 103 for compilation.

It is noted that in the field of art, a different naming convention may be used to name the interpreter 105 and the compiler 103. For example, in some programming languages, the interpreter 105 may be named as “compiler”, while the compiler 103 may be named as “JIT compiler”. Nevertheless, for the sake of clarity, the naming convention of “interpreter” and “compiler” is used in the present disclosure.

FIG. 2 shows a message flow diagram according to an embodiment of the invention. In FIG. 2, the protection device 101, the interpreter 105, and the compiler 103 corresponds to the same elements in FIG. 1 and shall share the same features and functions likewise.

As shown in FIG. 2, during program execution, when a function of the program is invoked (or called), the interpreter 105 may load a corresponding bytecode or a corresponding bytecode segment based on the function call 201. Then, the interpreter 105 may allocate a memory region in the memory 107. The memory region is marked as “writable and not executable”. It is noted that any right or permission that is not specifically mentioned for embodiments of the invention means that the right or permission can be either allowed or not allowed. For example, at the moment, the memory region can be either “readable” or “not readable”. This does not matter, because the compiler 103 only needs a write permission to write generated machine instructions during the compilation into the memory region. Marking the memory region as “not executable” is to ensure that the compiled native code is not executed before verification. Optionally, marking the memory region as “not readable” may further increase the security level to prevent any malicious access.

It is also noted that in some embodiments, the protection device 101 may have read access to the memory region regardless of the rights marked (or configured) for the memory region. This is, even the memory region is marked as “not readable”, the protection device 101 may still have read access to the memory region. This is because the protection device 101, as a device for protecting security, may have elevated privileges, such as an administrator (e.g., superuser, admin, or root) right. Then, the interpreter 105 sends a compilation request 202 to the compiler 103. The compilation request 202 comprises the corresponding bytecode. Optionally, the compilation request 202 may further comprise an address of the allocated memory region. Alternatively, the address of the allocated memory region may be pre-configured and may be commonly known among the interpreter 105, the compiler 103, and the protection device 101.

After receiving the compilation request 105 and before a compilation of the bytecode, the compiler 103 sends indication information 203 indicating a start of the compilation to the protection device 101. The protection device 101 initializes protection information after receiving the indication information 203.

In some embodiments, the indication information 203 may comprise an indication or a request indicating whether or not to generate the protection information. In this case, the protection device 101 may only generate the protection information when it is indicated in the indication information. Moreover, the protection device 101 may be configured to generate the protection information by default unless the protection device 101 is instructed not to do so through the indication information 203.

For initializing the protection information, the protection device 101 may simply assign a null value. Moreover, the protection device may allocate or assign a memory space for storing the protection information. Alternatively, in some algorithms, the protection device 101 may also initialize the protection information based on an initialization vector (IV). The IV may also be referred to as a starting variable and may be associated with a key that is to be used for updating the protection information during the compilation according to a particular algorithm. Once the initialization is done, the protection device 101 may optionally send a confirmation message to the compiler 103 indicating a completion of the initialization of the protection information.

Then, the compiler 103 compiles the bytecode into a native code. The compiled native code may be stored in the allocated memory region. In particular, the bytecode may comprise a set of IR instructions. The IR instructions may also be referred to as functions. The “IR instructions” may be referred to as a representation of a program between the source code and the native code. Therefore, the bytecode may be portable and does not depend upon one specific type of processor. Optionally, in some embodiments, the compilation request may further comprise profile data. The profile data may be used to enable profile-guided optimizations (PGO) when generating the native code. In this way, the speed of the compilation may be increased while the overhead of the compilation may be decreased.

It is noted that the interpreter 105 may notify an address of the bytecode to the compiler 103. In this case, the interpreter 105 does not need to send the bytecode itself to the compiler 103. The compiler 103 may directly obtain the bytecode according to the address and start to compile the bytecode.

During the compilation, the compiler 103 may keep compiling each IR instruction 205 into one or more native instructions 206 until the last IR instruction. Each compiled native instruction may be directly executable by a processor. Therefore, the native code may also be referred to as a machine code. During the compilation, the compiler 103 provides each compiled instruction 206, i.e., native instruction, to the protection device 101.

Optionally, for providing the compiled instruction 206, the compiler 103 may send each compiled instruction 206 directly to the protection device 101 via a secure channel.

Then, the protection device 101 updates the protection information based on each obtained instruction 206 by using one or more cryptographic algorithms. The cryptographic algorithm includes but is not limited to: a checksum algorithm, cryptographic hash function, message authentication code (MAC) algorithm, digital signature, and the like.

In particular, the protection device 101 may update the protection information accumulatively based on each obtained instruction that is generated and is to be comprised in the native code. That is, the protection information may be updated based on a previously updated protection information, which is updated based on a previously obtained instruction by using one or more cryptographic algorithms.

In some embodiments, the protection device 101 may generate (i.e., initialize and update) and lock one piece of protection information for each compiled native code. Alternatively, the protection device 101 may generate and lock one piece of protection information for a group of compiled native codes, in particular for native codes that belong to a same program or process. That is, each native code may be associated with separate protection information. Alternatively, if multiple bytecodes belong to a same program, a piece of common protection information may be shared for multiple native codes that are compiled based on the multiple bytecodes and may be accumulatively generated during the compilation of the multiple bytecodes. In this case, the protection information may further comprise indication information that indicates the multiple bytecodes that correspond to the protection information.

In some embodiments, the protection device 101 may determine one or more cryptographic algorithms based on a security level and/or speed requirement. The security level may be determined based on program owner or group. For example, if the native code relating to a system-level program may have a higher security level than a native code relating to a user- level program. Therefore, a more secure cryptographic algorithm, such as but not limited to the MAC algorithm and digital signature, may be used for the native code relating to a system-level program. On the other hand, if a program demands higher running speed, then a lightweight cryptographic algorithm, such as but not limited to the checksum algorithm, may be used.

After updating the protection information for each obtained native instruction, the protection device may optionally send a confirmation message indicating that the protection information has been updated. If no such confirmation message is received after a certain timeout period, the compiler 103 may provide the compiled instruction 206 to the protection device 101 again.

As labeled in FIG. 2, a message flow of messages 205, 206, 207 may be repeated until the compilation is completed. Then, the compiler 103 sends a notification message 208 indicating the completion of the compilation to the interpreter 105. After receiving the notification message 208, the protection device 101 locks the protection information, so that the protection information cannot be modified or updated further. Optionally, the protection device 101 may send a confirmation message 209 indicating that the protection information is locked. Then, the compiler 103 sends a further notification message 208’ to the interpreter 105. After receiving the further notification message 208’, the interpreter 105 marks the allocated memory region that is currently “writable, not executable” into “readable, not writable, not executable”. By marking the memory region as “not writable” after the compilation, the security level may be further increased. Because the native code stored in the memory region cannot be modified any further. The protection device 101 may store the locked protection information securely and associate the locked protection information with the native code. Optionally, the protection device 101 may determine an index to the locked protection information and associate the index to the locked protection information. The index may be generated based on one or more of the following: a process identity (PID), a program identity, a timestamp, a sequence number. Furthermore, the index may be in one-to-one correspondence to the native code.

Before the compiled native code is executed, (i.e., for a to-be executed native code), the interpreter 105 may send a request 211 for verifying the compiled native code to the protection device 101. In response to this request 211, the protection device 101 obtains the compiled native code from the allocated memory region. Then, the protection device 101 verifies the protection information of the obtained native code against the locked protection information.

In particular, for verifying the protection information of the native code obtained from the allocated memory region, the protection device 101 may employ the same cryptographic algorithm(s) used during the compilation to generate the locked protection information. The cryptographic algorithm may be fixed, or may be determined based on algorithm information comprised in the protection information. Then, the protection device 101 may generate to-be- verified protection information based on the native code retrieved from the memory region. Then, the protection device may compare the two pieces of protection information, in particular, to check whether the two pieces of protection information is a match. In case of a match, the protection device 101 may send a positive verification result to the interpreter 105 indicating the native code in the memory region can be trusted and executed. In case of a mismatch, the protection device 101 may send a negative verification result to the interpreter 105 indicating the native code in the memory region cannot be trusted and shall not be executed.

The interpreter 105 then marks the allocated memory region as “executable and not writable” in response to a positive verification result. Then, the interpreter 105 may start to execute the (native) instructions comprised in the native code from the memory region. It is noted that the reading permission is not always required when executing the native code. That is, the reading permission of the allocated memory region may be readable or not readable. When receiving a negative verification result, the interpreter 105 does not mark the allocated memory region as executable. Instead, the interpreter 105 may send a compilation request to the compiler 103 for the same function call again in order to re-compile the bytecode. In this case, the same steps for generating the protection information as mentioned above shall similarly apply.

It is noted that the (allocated) memory region used in the present disclosure may be a storage space of a random-access memory (RAM), which may be referenced by a memory address. The memory address may have a word size of 8, 16, 24, 32, 64, 128, etc. bits.

In some embodiments, the function call may repeat multiple times. Since the protection information has already been locked and stored by the protection device 101, the interpreter 105 may directly send the verification request 211 after receiving a subsequent function call 210, of which a corresponding bytecode has been previously compiled into a native code by the compiler 103. Therefore, the compiler 103 does not need to compile the bytecode again and the protection device 101 does not need to generate protection information again. In this case, in response to a subsequent functional call, the native code in the allocated memory region may be directly verified by the protection device 101 based on previously generated protection information. For the subsequence function call 210, the interpreter 105 does not need to change rights of the allocated memory region, since it has already been marked “executable and not writable” previously. In this case, the interpreter 105 may directly start to execute the native code after receiving a positive verification result from the protection device 101. Otherwise, the interpreter 105 may request a re-compilation.

FIG. 3 shows a protection device 300 according to an embodiment of the invention. The protection device 300 corresponds to the protection device 101 in FIGs. 1-2.

As shown in FIG. 3, the protection device 300 may comprise an input/output (I/O) unit 301, a processing unit 303, and an optional storage unit 305. The I/O unit 301 may also be referred to as a transceiver and may be separated into a receiving unit and a sending unit. The I/O unit 301 may be connected to the system bus and may be configured to perform the steps related to receiving and sending messages and information as mentioned in FIGs. 1-2. The processing unit 303 may be connected to the I/O unit 301 and may be configured to perform the steps of generating (initialization and update) and verifying the protection information. The optional memory unit 305 may be connected to the processing unit 303 and may be configured to store the protection information. Furthermore, the optional storage unit 305 may store keys related to algorithms that may be used for generating the protection information. The storage unit 305 may be a read-only memory (ROM), random-access memory (RAM), or a combination of ROM and RAM. The storage unit 305 is optional because in some embodiments, the protection information and the keys may be stored inside the processing unit 303, for example, an internal register inside the processing unit 303. In some other embodiments, the storage unit may also be located separately from the protection device.

In some embodiments, the protection device may be, or may be incorporated in a main processor, a coprocessor, a system-on-chip (SoC), or the like.

Optionally, the protection device 300 may be, or may be incorporated in one of the following modules: a trusted execution environment (TEE) module, secure element (SE), trusted platform module (TPM), trusted cryptographic module (TCM), secure enclave, hardware security module (HSM), and the like.

FIG. 4 shows a diagram of a method 400 according to an embodiment of the invention.

The method 400 is performed by a protection device and comprises the following steps: step 401: receiving, from the compiler, indication information indicating a start of the compilation of the bytecode; step 402: initializing protection information; step 403: obtaining, from the compiler, each instruction generated during the compilation of the bytecode; step 404: updating the protection information based on the obtained instruction; and step 405: locking the protection information when the compilation of the bytecode is finished.

In response to a verification request received from an interpreter, the method further comprises the following steps: step 406: obtaining the native code from a memory region; step 407: verifying the protection information related to the native code; and step 408: providing a verification result to the interpreter.

FIG. 5 shows a diagram of another method 500 according to an embodiment of the invention. The method 500 is performed by a compiler and comprises the following steps: step 501 : obtaining, from an interpreter, a bytecode; step 502: compiling the bytecode into a native code comprising a set of instructions; step 503: sending indication information to a protection device, wherein the indication information is indicative of a start of a compilation of the bytecode; step 504: providing each instruction generated during the compilation to the device; and step 505: informing the protection device and the interpreter of a completion of the compilation.

It is noted that steps 503-505 may be performed during step 502. In particular, step 502 may be referred to as a complete process of the compilation, which may include the following phases: the start of the compilation, generating the set of instructions, and the completion of the compilation. Steps 503-505 may be performed during the respective phase.

FIG. 6 shows a diagram of another method 600 according to an embodiment of the invention.

The method 600 is performed by an interpreter and comprises the following steps: step 601 : providing a bytecode to the compiler for a compilation; step 602: marking a memory region corresponding to a compiled native code as readable, not writable, and not executable when the compilation is finished; step 603 : sending a request for verifying the compiled native code to a protection device for protecting the compiled native code; step 604: marking the memory region as executable and not writable in response to a positive verification result from the protection device.

In particular, before step 601, the method 600 may optionally comprise marking the memory region as writable and not executable.

It is noted that the steps of the methods 400, 500, and 600 may share the same functions and details from the perspective of FIGs. 1-3 described above. Therefore, the corresponding method implementations are not described in detail again at this point.

The devices (i.e., the protection device, the interpreter, and the compiler) in the present disclosure may comprise processing circuitry configured to perform, conduct or initiate the various operations of the device described herein, respectively. The processing circuitry may comprise hardware and software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors. In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the device to perform, conduct or initiate the operations or methods described herein, respectively.

Optionally, the devices in the present disclosure may be a single electronic device capable of computing, or may comprise a set of connected electronic devices or modules capable of computing with shared system memory. It is well-known in the art that such computing capabilities may be incorporated into many different devices, and therefore the term “device” may comprise a chip, chipset, computer, server, virtual machine based on computer architectures, mobile terminal, tablet, wearable device, game console, graphic processing unit, graphic card, and the like.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed subject matter, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or another unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A device (101) for protecting a native code generated by a compiler (103), wherein the native code comprises a set of instructions generated by the compiler (103) based on a compilation of a bytecode, and wherein the device (101) is configured to: receive, from the compiler, indication information (203) indicating a start of the compilation of the bytecode, initialize protection information; obtain, from the compiler, each instruction (206) generated during the compilation of the bytecode; update the protection information based on the obtained instruction (206); lock the protection information when the compilation of the bytecode is finished; wherein the device (101) is further configured to, in response to a verification request (211) received from an interpreter (105): obtain the native code from a memory region; verify the protection information related to the native code; and provide a verification result (213) to the interpreter (105).

2. The device (101) according to claim 1, wherein the indication information (203) comprises a request to generate the protection information for the compilation of the bytecode.

3. The device (101) according to claim 1 or 2, wherein for initializing and updating the protection information, the device (101) is configured to employ one or more of the following: a checksum algorithm; a hashing algorithm; a message authentication code algorithm; and a digital signature.

4. The device (101) according to any one of claims 1 to 3, wherein the protection information comprises an identifier associated with the native code.

5. The device (101) according to any one of claims 1 to 4, wherein the protection information comprises algorithm information indicating one or more algorithms used to generate the protection information.

6. The device (101) according to any one of claims 1 to 5, further configured to: receive, from the interpreter (105), a further verification request to verify a previously compiled native code, obtain the previously compiled native code from the memory region; and verify previously generated protection information related to the previously compiled native code.

7. The device (101) according to any one of claims 1 to 6, wherein the device (101) is a secure cryptoprocessor.

8. The device (101) according to any one of claims 1 to 7, further configured to employ secure channels between the compiler (103) and the interpreter (105).

9. A compiler (103) configured to: obtain, from an interpreter (105), a bytecode; compile the bytecode into a native code comprising a set of instructions (206); send indication information (203) to a device (101) for protecting the native code, wherein the indication information (203) is indicative of a start of a compilation of the bytecode; provide each instruction (206) generated during the compilation to the device; and inform the device (101) and the interpreter (105) of a completion of the compilation (208, 208’).

10. An interpreter (105) configured to: provide a bytecode to a compiler (103) for compilation; when the compilation is finished, mark a memory region corresponding to a compiled native code as readable, not writable, and not executable; send a request (211) for verifying the compiled native code to a device (101) for protecting the compiled native code; and mark the memory region as executable in response to a positive verification result from the device.

11. A method (400) for protecting a native code generated by a compiler, wherein the native code comprises a set of instructions generated by the compiler based on a compilation of a bytecode, and wherein the method is performed by a device and comprises: receiving (401), from the compiler, indication information indicating a start of the compilation of the bytecode, initializing (402) protection information; obtaining (403), from the compiler, each instruction generated during the compilation of the bytecode; updating (404) the protection information based on the obtained instruction; locking (405) the protection information when the compilation of the bytecode is finished; wherein the method further comprises, in response to a verification request received from an interpreter (105): obtaining (406) the native code from a memory region; verifying (407) the protection information related to the native code; and providing (408) a verification result to the interpreter.

12. A method (500) for protecting a native code generated by a compiler, wherein the method is executed by the compiler and comprises: obtaining (501), from an interpreter, a bytecode; compiling (502) the bytecode into a native code comprising a set of instructions; sending (503) indication information to a device for protecting the native code, wherein the indication information is indicative of a start of a compilation of the bytecode; providing (504) each instruction generated during the compilation to the device; and informing (505) the device and the interpreter of a completion of the compilation.

13. A method (600) for protecting a native code generated by a compiler, wherein the method is executed by an interpreter and comprises: providing (601) a bytecode to the compiler for a compilation; when the compilation is finished, marking (602) a memory region corresponding to a compiled native code as readable, not writable, and not executable; sending (603) a request for verifying the compiled native code to a device for protecting the compiled native code; and marking (604) the memory region as executable and not writable in response to a positive verification result from the device.

14. A computer program product comprising a program code for performing the method according to any one of claims 11 to 13, when executed on a computer.

15. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of claims 11 to 13.