A system that validates a native code module. During operation, the system receives a native code module comprised of untrusted native program code. The system validates the native code module by: (1) determining that code in the native code module does not include any restricted instructions and/or does not access restricted features of a computing device; and (2) determining that the instructions in the native code module are aligned along byte boundaries such that a specified set of byte boundaries always contain a valid instruction and control flow instructions have valid targets. The system allows successfully-validated native code modules to execute, and rejects native code modules that fail validation. By validating the native code module, the system facilitates safely executing the native code module in the secure runtime environment on the computing device, thereby achieving native code performance for untrusted program binaries without significant risk of unwanted side effects.
Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A computer-implemented method, comprising: receiving, by a computing device, executable code for a native code module, wherein the executable code includes a set of instructions that match an instruction set architecture of the computing device, wherein the set of instructions specifies operations to perform on program data associated with the native code module; loading, by the computing device, (i) the program data into a first region of a memory segment of the computing device and (ii) the executable code into a second region of the memory segment that is different from the first region, wherein the computing device is configured to restrict the native code module from accessing data stored outside of the first region of the memory segment, wherein the computing device is configured to restrict the native code module from transferring control to instructions stored outside of the second region of the memory segment; in response to loading the executable code into the second region of the memory segment, determining, by the computing device, whether the native code module complies with a set of security constraints; and in response to determining that the native code module complies with the set of security constraints, executing the native code module with the computing device.
A computer system validates and executes untrusted native code. It receives executable code and program data for a native code module. The system loads the program data and executable code into separate memory regions, restricting the native code module from accessing data or transferring control outside these regions. It then checks if the native code module meets security rules. If compliant, the system executes the native code module. This allows safe execution of untrusted native code with near-native performance.
2. The computer-implemented method of claim 1 , wherein: the native code module is an untrusted web-based application that is configured to be run in a web browser on the computing device; and executing the native code module comprises running the untrusted web-based application in a secure runtime environment of the web browser on the computing device.
The method described in claim 1 is used for untrusted web applications within a web browser. Specifically, the native code module is a web-based application, and executing it means running it in a secure area within the browser. This secure area (runtime environment) provides an isolated space for the untrusted code to run without compromising the rest of the system.
3. The computer-implemented method of claim 1 , comprising allocating, in the first region of the memory segment of the computing device, (i) a first range of addresses for storing at least one of thread or heap data, and (ii) a second range of addresses for storing stack data, wherein loading the program data into the first region of the memory segment comprises loading the program data into memory corresponding to the first or second ranges of addresses.
The method described in claim 1 includes memory management. When allocating the memory region for program data, the system sets aside separate address ranges for thread/heap data and stack data. Loading program data involves putting the data into these designated address ranges. This organization helps to improve security and efficiency when running the native code.
4. The computer-implemented method of claim 1 , comprising allocating, in the second region of the memory segment of the computing device, (i) a first range of addresses for storing the executable code for the native code module and (ii) a second range of addresses for storing trampoline instructions that are configured, when executed, to interact with a limited set of runtime resources of the computing device outside of the memory segment, wherein the computing device is configured to restrict the native code module from interacting with the limited set of runtime resources except indirectly via the trampoline instructions in the second range of addresses.
In addition to the method of claim 1, when allocating the memory region for executable code, the system allocates separate address ranges for the native code's executable instructions and for "trampoline instructions". Trampoline instructions are special code snippets that allow the native code to access limited system resources indirectly. The system blocks the native code from directly accessing these resources, forcing it to use the trampoline instructions as intermediaries.
5. The computer-implemented method of claim 4 , wherein the trampoline instructions include instructions that would be deemed illegal if included in the executable code for the native code module, wherein the trampoline instructions are configured, when executed, to transfer control flow out of the native code module to particular runtime resources of the computing device or to communicate messages between the native code module and particular runtime resources of the computing device.
Building upon claim 4, the trampoline instructions contain code that would normally be considered illegal if it were directly within the native code module's executable code. These trampoline instructions are designed to transfer program execution out of the isolated native code module to specific system resources. They also enable communication (message passing) between the native code module and those system resources.
6. The computer-implemented method of claim 4 , comprising padding the second region of the memory segment of the computing device so that a size of the second region of the memory segment is an even power of two.
Extending claim 4, the memory region allocated for the executable code (including both the native code and trampoline instructions) is padded so that its total size is a power of two (e.g., 256KB, 512KB, 1MB). This padding can improve memory management and potentially simplify security checks.
7. The computer-implemented method of claim 4 , wherein the trampoline instructions include instructions that, when executed, cause the computing device to trigger a stack switch.
Expanding on claim 4, the trampoline instructions, when executed, can trigger a "stack switch". This means they can change the stack being used by the program, allowing the native code module to interact with different parts of the system without directly manipulating stack memory.
8. The computer-implemented method of claim 1 , wherein determining whether the native code module complies with the set of security constraints comprises determining whether the set of instructions of the executable code for the native code module includes instructions in a specified list of restricted instructions.
Regarding the security checks from claim 1, one specific check is to verify that the native code module's executable code does *not* contain any instructions from a predefined list of restricted or forbidden instructions. This is a basic form of code validation to prevent potentially harmful operations.
9. The computer-implemented method of claim 1 , wherein determining whether the native code module complies with the set of security constraints comprises determining whether instructions in the set of instructions of the executable code for the native code module are aligned in the memory segment along a specified set of byte boundaries.
As part of the security checks from claim 1, the system verifies that the instructions in the native code module's executable code are properly aligned in memory. This means that they must start at specific byte boundaries within the memory segment. Incorrect alignment can indicate malicious code or corrupted data.
10. The computer-implemented method of claim 1 , wherein determining whether the native code module complies with the set of security constraints comprises: determining a set of valid control-flow targets that occur in the executable code and a set of known control-flow targets that occur in the executable code; and verifying that each target address identified in the set of known control-flow targets is among the set of valid control-flow targets.
The security check from claim 1 involves validating control flow. The system identifies all valid places in the executable code that a program can jump to (valid control-flow targets). It also identifies all the actual jump instructions used in the code (known control-flow targets). The check ensures that every jump instruction targets a valid location, preventing jumps to unexpected or malicious code.
11. A non-transitory computer-readable storage medium having instructions stored thereon that, when executed by one or more processors of a computing device, cause the one or more processors to perform operations comprising: receiving, by a computing device, executable code for a native code module, wherein the executable code includes a set of instructions that match an instruction set architecture of the computing device, wherein the set of instructions specifies operations to perform on program data associated with the native code module; loading, by the computing device, (i) the program data into a first region of a memory segment of the computing device and (ii) the executable code into a second region of the memory segment that is different from the first region, wherein the computing device is configured to restrict the native code module from accessing data stored outside of the first region of the memory segment, wherein the computing device is configured to restrict the native code module from transferring control to instructions stored outside of the second region of the memory segment; in response to loading the executable code into the second region of the memory segment, determining, by the computing device, whether the native code module complies with a set of security constraints; and in response to determining that the native code module complies with the set of security constraints, executing the native code module with the computing device.
A computer-readable storage medium stores instructions that, when executed, cause a computer to validate and execute untrusted native code. The instructions cause the system to receive executable code and program data for a native code module. The system loads the program data and executable code into separate memory regions, restricting the native code module from accessing data or transferring control outside these regions. It then checks if the native code module meets security rules. If compliant, the system executes the native code module. This allows safe execution of untrusted native code with near-native performance.
12. The non-transitory computer-readable storage medium of claim 11 , wherein: the native code module is an untrusted web-based application that is configured to be run in a web browser on the computing device; and executing the native code module comprises running the untrusted web-based application in a secure runtime environment of the web browser on the computing device.
The storage medium from claim 11 is used for untrusted web applications within a web browser. Specifically, the native code module is a web-based application, and executing it means running it in a secure area within the browser. This secure area (runtime environment) provides an isolated space for the untrusted code to run without compromising the rest of the system.
13. The non-transitory computer-readable storage medium of claim 11 , wherein the operations comprise allocating, in the first region of the memory segment of the computing device, (i) a first range of addresses for storing at least one of thread or heap data, and (ii) a second range of addresses for storing stack data, wherein loading the program data into the first region of the memory segment comprises loading the program data into memory corresponding to the first or second ranges of addresses.
The storage medium from claim 11 includes instructions for memory management. When allocating the memory region for program data, the system sets aside separate address ranges for thread/heap data and stack data. Loading program data involves putting the data into these designated address ranges. This organization helps to improve security and efficiency when running the native code.
14. The non-transitory computer-readable storage medium of claim 11 , wherein the operations comprise allocating, in the second region of the memory segment of the computing device, (i) a first range of addresses for storing the executable code for the native code module and (ii) a second range of addresses for storing trampoline instructions that are configured, when executed, to interact with a limited set of runtime resources of the computing device outside of the memory segment, wherein the computing device is configured to restrict the native code module from interacting with the limited set of runtime resources except indirectly via the trampoline instructions in the second range of addresses.
In addition to the storage medium of claim 11, when allocating the memory region for executable code, the instructions allocate separate address ranges for the native code's executable instructions and for "trampoline instructions". Trampoline instructions are special code snippets that allow the native code to access limited system resources indirectly. The system blocks the native code from directly accessing these resources, forcing it to use the trampoline instructions as intermediaries.
15. The non-transitory computer-readable storage medium of claim 14 , wherein the trampoline instructions include instructions that would be deemed illegal if included in the executable code for the native code module, wherein the trampoline instructions are configured, when executed, to transfer control flow out of the native code module to particular runtime resources of the computing device or to communicate messages between the native code module and particular runtime resources of the computing device.
Building upon claim 14, the trampoline instructions contain code that would normally be considered illegal if it were directly within the native code module's executable code. These trampoline instructions are designed to transfer program execution out of the isolated native code module to specific system resources. They also enable communication (message passing) between the native code module and those system resources.
16. The non-transitory computer-readable storage medium of claim 14 , wherein the operations comprise padding the second region of the memory segment of the computing device so that a size of the second region of the memory segment is an even power of two.
Extending claim 14, the memory region allocated for the executable code (including both the native code and trampoline instructions) is padded so that its total size is a power of two (e.g., 256KB, 512KB, 1MB). This padding can improve memory management and potentially simplify security checks.
17. The non-transitory computer-readable storage medium of claim 14 , wherein the trampoline instructions include instructions that, when executed, cause the computing device to trigger a stack switch.
Expanding on claim 14, the trampoline instructions, when executed, can trigger a "stack switch". This means they can change the stack being used by the program, allowing the native code module to interact with different parts of the system without directly manipulating stack memory.
18. The non-transitory computer-readable storage medium of claim 11 , wherein determining whether the native code module complies with the set of security constraints comprises determining whether the set of instructions of the executable code for the native code module includes instructions in a specified list of restricted instructions.
Regarding the security checks from claim 11, one specific check is to verify that the native code module's executable code does *not* contain any instructions from a predefined list of restricted or forbidden instructions. This is a basic form of code validation to prevent potentially harmful operations.
19. The non-transitory computer-readable storage medium of claim 11 , wherein determining whether the native code module complies with the set of security constraints comprises determining whether instructions in the set of instructions of the executable code for the native code module are aligned in the memory segment along a specified set of byte boundaries.
As part of the security checks from claim 11, the system verifies that the instructions in the native code module's executable code are properly aligned in memory. This means that they must start at specific byte boundaries within the memory segment. Incorrect alignment can indicate malicious code or corrupted data.
20. A computing device, comprising: one or more processors; and a non-transitory computer-readable storage medium having instructions stored thereon that, when executed by the one or more processors, cause performance of operations comprising: receiving, by the computing device, executable code for a native code module, wherein the executable code includes a set of instructions that match an instruction set architecture of the computing device, wherein the set of instructions specifies operations to perform on program data associated with the native code module; loading, by the computing device, (i) the program data into a first region of a memory segment of the computing device and (ii) the executable code into a second region of the memory segment that is different from the first region, wherein the computing device is configured to restrict the native code module from accessing data stored outside of the first region of the memory segment, wherein the computing device is configured to restrict the native code module from transferring control to instructions stored outside of the second region of the memory segment; in response to loading the executable code into the second region of the memory segment, determining, by the computing device, whether the native code module complies with a set of security constraints; and in response to determining that the native code module complies with the set of security constraints, executing the native code module with the computing device.
A computing device is configured to validate and execute untrusted native code. It includes one or more processors and memory containing instructions. When executed, the instructions cause the system to receive executable code and program data for a native code module. The system loads the program data and executable code into separate memory regions, restricting the native code module from accessing data or transferring control outside these regions. It then checks if the native code module meets security rules. If compliant, the system executes the native code module. This allows safe execution of untrusted native code with near-native performance.
Cooperative Patent Classification codes for this invention. Click any code to explore related patents in that topic.
June 3, 2016
July 18, 2017
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.