A sandboxing, memory isolation method based on binary instrumentation and storage medium

Abstract

The application provides a sandbox and a memory isolation method based on binary insertion and a storage medium, which are applied to memory isolation when WASM bytecode coding is performed in an AOT compilation manner, the sandbox extracts code segment information and WASI function information from a WASM virtual machine through a dynamic insertion tool; each branch instruction received by an AOT compilation runtime is analyzed, it is confirmed that the memory accessed by each branch instruction is in the memory corresponding to the AOT compilation or the caller of each branch instruction is on a preset whitelist, and finally, WASM native code obtained after AOT compilation is performed is executed, so that hosting from untrusted AOT code is realized. The sandbox and the memory isolation method provided in the embodiment dynamically detect the AOT module during WASM running, extract the memory layout of the runtime and the save address and linear memory range of the AOT module, limit the control flow and data access, and thus provide the memory security attribute, so the application has high practicability.

Description

Technical Field

[0001] This invention relates to the field of serverless computing technology, and in particular to a sandbox, memory isolation method, and storage medium based on binary instrumentation. Background Technology

[0002] WebAssembly, or WASM for short, is a virtual instruction set architecture used to compile various high-level languages ​​that run in web browsers, providing a portable binary instruction format and robust memory safety.

[0003] WASM bytecode can be compiled into native code using Ahead-of-Time (AOT) compilation. The memory safety of WASM code comes from a runtime environment-enforced sandbox, which restricts WASM memory access, interpreter WASM memory access, or compiler-assisted Software Fault Isolation (SFI). In a Function as a Service (Casu) cloud environment, customers are allowed to use AOT code from untrusted parties in the cloud. However, currently, WASM AOT compilers lack unified rules for handling AOT files, and their loading methods differ, thus failing to ensure the safe operation of programs.

[0004] Therefore, the existing technology needs further improvement. Summary of the Invention

[0005] In view of the shortcomings of the prior art, the purpose of this invention is to provide a sandbox and memory isolation method and storage medium based on binary instrumentation, which overcomes the shortcomings of the prior art in that there is no unified management method for untrusted AOT binary files, resulting in low program execution security when WASM is executed.

[0006] The technical solution of the present invention is as follows:

[0007] In a first aspect, this embodiment discloses a sandbox based on binary instrumentation, which is used for memory isolation when WASM bytecode is encoded in an AOT compilation manner. The sandbox includes: an analysis instrument module, an inspection instruction module, and an execution module.

[0008] The analysis instrumentation module is used to extract code segment information and WASI function information from the WASM virtual machine using dynamic instrumentation tools;

[0009] The inspection instruction module is used to analyze each branch instruction received during AOT compilation runtime, and to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on a preset whitelist.

[0010] The execution module is used to execute the WASM native code obtained after AOT compilation.

[0011] Optionally, the analysis instrument module includes: a code segment information extraction unit and a function information extraction unit;

[0012] The code segment information extraction unit is used to extract code segment information from the WASM virtual machine using a dynamic instrumentation tool; wherein, the code segment information is: the memory space allocated and loaded by the WASM virtual machine for AOT compilation;

[0013] The function information extraction unit is used to extract WASI-related function information; wherein, the WASI-related function information is the function entry point of the WASI system call.

[0014] Optionally, the code segment information extraction unit further includes: an image leveling instrument subunit;

[0015] The image level instrument subunit is used to detect the input and output information of the AOT instance function in the image layer in order to obtain the code segment information and the linear memory boundary of the code segment information.

[0016] Optionally, the inspection instruction module includes: a single jump instruction inspection unit, a call instruction inspection unit, and a return instruction inspection unit;

[0017] The single jump instruction checking unit is used to determine whether the target address of the received single jump instruction is within the code segment. If not, it determines whether the target address of the single jump instruction is a function related to WASI. If not, it determines that the single jump instruction is an illegal instruction.

[0018] The call instruction checking unit is used to determine whether the received call instruction is in the preset whitelist. If it is not, it is an illegal call instruction.

[0019] The return instruction checking unit is used to control the return address to be within the memory boundary corresponding to the AOT compilation, and to determine whether the address of the return instruction is consistent with the address of the next return instruction.

[0020] Optionally, the inspection instruction module further includes: a memory access judgment unit;

[0021] The memory access judgment unit is used to judge whether the received memory access meets the legal conditions; the legal conditions include: the target of the memory access is stack memory, the target of the memory access is the linear memory segment corresponding to AOT compilation, and the target address of the memory access is within a preset list.

[0022] Optionally, the sandbox may further include: searching for AOT modules;

[0023] The AOT-finding module is used to detect the memory block storing the WASM native code after the AOT-compiled WASM native code has been loaded into the virtual machine, in order to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory.

[0024] Optionally, the execution module is also used to execute the engine and the instrumented code.

[0025] Secondly, this embodiment also discloses a sandbox memory isolation method, wherein the sandbox is used to implement memory isolation when encoding WASM bytecode using AOT compilation, the method comprising:

[0026] The code segment information and WASI function information are extracted from the WASM virtual machine using dynamic instrumentation tools;

[0027] Analyze each branch instruction received during the AOT compilation runtime to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on the preset whitelist;

[0028] The WASM native code obtained after AOT compilation is completed.

[0029] Optionally, the method further includes:

[0030] After the AOT-compiled WASM native code is loaded into the virtual machine, the memory block storing the WASM native code is checked to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory.

[0031] Thirdly, this embodiment also discloses a computer-readable storage medium, wherein the computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the memory isolation method.

[0032] Beneficial Effects: This invention proposes a sandbox, memory isolation method, and storage medium based on binary instrumentation, applied to memory isolation during WASM bytecode encoding using AOT compilation. The sandbox extracts code segment information and WASI function information from the WASM virtual machine through dynamic instrumentation tools; analyzes each branch instruction received during AOT compilation runtime, confirming that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on a preset whitelist; finally, it executes the WASM native code obtained after AOT compilation, thereby achieving management of untrusted AOT code. The sandbox and memory isolation method provided in this embodiment dynamically detect the AOT module during WASM runtime, extracting the runtime memory layout and the storage address and linear memory range of the AOT module, restricting control flow and data access, thus providing memory security attributes and therefore having high practicality. Attached Figure Description

[0033] Figure 1 This is a schematic diagram illustrating the structural principle of a sandbox based on binary instrumentation as described in this invention;

[0034] Figure 2 This is a schematic diagram of the structural principle of the analytical instrument module in an embodiment of the present invention;

[0035] Figure 3 This is a schematic diagram of the structural principle of the inspection instruction module in an embodiment of the present invention;

[0036] Figure 4 This is a flowchart of the steps of the memory isolation method described in this invention;

[0037] Figure 5 This is a schematic diagram illustrating the data storage principle in a sandbox based on binary instrumentation as described in this invention. Detailed Implementation

[0038] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0039] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0040] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0041] Serverless computing is characterized by a Function as a Service (FaaS) programming model. With the increasing popularity of serverless computing, more and more people are paying attention to building secure runtimes that can host potentially malicious code provided by serverless cloud customers. As an emerging programming language, WebAssembly offers robust security and high portability, thus becoming one of the most prominent candidates for FaaS clouds.

[0042] WebAssembly (or WASM) defines a portable assembly (or WASM) as a portable binary format. It was initially designed to compile various high-level languages ​​(such as Rust and C++) for execution in web browsers. Independent runtimes, such as Wasmtime and WebAssembly Micro Runtime (WAMR), have been developed to run WebAssembly bytecode as independent programs on various CPU architectures. Therefore, applications written in C++ or Rust can be compiled into a WebAssembly module, which can then be hosted on multiple platforms by the WASM runtime.

[0043] WebAssembly bytecode can be interpreted and executed by an interpreter, or compiled into native code via either Ahead-of-Time (AOT) compilation or Just-In-Time (JIT) compilation. The memory safety of WASM code comes from a runtime environment-enforced sandbox that restricts WASM memory access, interpreter WASM memory access, or compiler-assisted Software Fault Isolation (SFI). In a Functions as a Service (Casu) cloud environment, users are allowed to use AOT code originating from untrusted parties. In this case, the SFI enforced by compiler tools can be completely bypassed.

[0044] To achieve memory isolation of untrusted AOT code uploaded to the service cloud during WASM runtime, thereby restricting control flow and memory access of AOT modules, this embodiment provides a software framework, namely a binary instrumentation-based sandbox, to implement memory isolation during WASM bytecode encoding under AOT compilation mode, thereby improving program execution security.

[0045] It should be noted that the above application scenarios are shown only for the purpose of understanding the present invention, and the embodiments of the present invention are not limited in any way. On the contrary, the embodiments of the present invention can be applied to any applicable scenario.

[0046] Furthermore, in order to further explain the invention, the embodiments will be described in detail below with reference to the accompanying drawings.

[0047] Exemplary device

[0048] Firstly, this embodiment discloses a sandbox based on binary instrumentation, such as Figure 1 As shown, the sandbox is used for memory isolation when WASM bytecode is encoded in AOT compilation mode. The sandbox includes: analysis instrument module 110, inspection instruction module 120 and execution module 130.

[0049] The analysis instrumentation module 110 is used to extract code segment information and WASI function information from the WASM virtual machine using dynamic instrumentation tools.

[0050] The analysis instrumentation module is primarily used to extract necessary information from the current virtual machine and analyze its state based on this information. The virtual machine's state comprises two aspects: first, code segment information; and second, WASI-related functions. WASI-related functions are the entry points for WASI system calls. The code segment information represents the exact memory space allocated during the virtual machine's AOT compilation, specifically the memory space used to load and load the AOT-compiled WASM. WASI-related functions are valid targets other than the code segment.

[0051] Specifically, such as Figure 2 As shown, the analysis instrument module 110 includes: a code segment information extraction unit 1101 and a function information extraction unit 1102;

[0052] The code segment information extraction unit 1101 is used to extract code segment information from the WASM virtual machine through a dynamic instrumentation tool; wherein, the code segment information is: the memory space allocated and loaded by the WASM virtual machine for AOT compilation;

[0053] The function information extraction unit 1102 is used to extract WASI-related function information; wherein, the WASI-related function information is the function entry point of the WASI system call.

[0054] In detail, the code segment information extraction unit 1101 further includes: an image level instrument subunit 11011;

[0055] The image level instrument subunit 11011 is used to detect the input and output information of the AOT instance function in the image layer in order to obtain the code segment information and the linear memory boundary of the code segment information.

[0056] The analysis instrument is used to obtain necessary information, which is only generated during execution. The analysis instrument module mainly consists of two parts: (1) code segment information and (2) WASI-related function information. The code segment information is the accurate memory address range of the WebAssembly compiled by AOT. It is known that the WebAssembly compiled by AOT will be placed in memory at [0x00000000,0x80000000], but the exact address is unknown. The exact address can only be detected when loaded. The WASI-related function information is a pointer to some functions in the WebAssembly virtual machine. For the WAMR compiler, the git tag is WAMR-01-18-2022-38-gf8ee05d, and some allowed functions are aotinvokenative() and aotinlargememory() in WAMR, so the information here is a pointer to aotinvokenative() in WAMR.

[0057] In one implementation, since different compiler versions handle WASI differently, a function whitelist is set up in specific applications to achieve accurate instruction identification. This whitelist contains a list of all allowed functions in WAMR. When a JUMP or CALL instruction is detected outside the code segment, the detected code checks whether the target belongs to a function in the whitelist. To obtain this information, the code is inspected at the image layer. The image layer in Intel PIN is defined as a single ELF file, which can be an executable file, a dynamic link library, or a static link library. In the image layer, code segment information is obtained by searching for specific functions and monitoring parameter or return value information. Specifically, to obtain code segment information, the tool aotinstantiate() function can be used. One parameter of this function is AOTModule, which contains the code segment information of the AOT-compiled module. By performing instrumental detection and analysis on the entry and exit points of this function, the code segment information is obtained, because parameter information can only be obtained at the function's entry point, while code segment information can only be determined after the function completes. Before this instance function, the instrumented code receives a pointer to AOTMule, while the code after this function receives the exact code segment. The code segment information includes the starting address and the segment length. Specifically, the starting address offset is 0xf0, and the code segment length offset is also 0xf0.

[0058] Furthermore, in addition to the code segment information, it's necessary to obtain the instantiation functions for the linear memory and instruction memory that WebAssembly depends on. This function returns an AOTMemory Instance object, which includes an AOTPointer. This represents the boundaries of the linear memory addresses. The initial addresses of the linear memory can then be obtained. When WebAssembly runs, it dynamically announces memory boundaries through AOT amplification, so in practice, this function needs to be hooked to update the linear memory boundaries in real time.

[0059] The inspection instruction module 120 is used to analyze each branch instruction received during the AOT compilation runtime, and to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on a preset whitelist.

[0060] The inspection instruction module provided in the embodiment is used to check whether the target address of the branch instruction is valid, and to analyze whether each received branch instruction is invalid.

[0061] It detects jump instructions, call instructions, and return instructions, and prohibits direct calls to system instructions to prevent AOT-compiled WebAssembly from directly executing system calls.

[0062] Specifically, such as Figure 3 As shown, the inspection instruction module 120 includes: a single jump instruction inspection unit 1201, a call instruction inspection unit 1202, and a return instruction inspection unit 1203;

[0063] The single jump instruction checking unit 1201 is used to determine whether the target address of the received single jump instruction is within the code segment. If it is not, it determines whether the target address of the single jump instruction is a function related to WASI. If it is not, it determines that the single jump instruction is an illegal instruction.

[0064] The call instruction checking unit 1202 is used to determine whether the received call instruction is in the preset whitelist. If it is not, it is an illegal call instruction.

[0065] The return instruction checking unit 1203 is used to control the return address to be within the memory boundary corresponding to the AOT compilation, and to determine whether the address of the return instruction is consistent with the address of the next return instruction.

[0066] For a single jump instruction, the instrumented code checks whether the target address of the branch is within the code segment; this information is obtained based on image-level tools. If this information has already been obtained from image-level tools and the branch target address is not within the code segment, further checks are performed on the instrumented code to determine whether the branch target address is a WASI-related function. If both checks are negative, the jump instruction is determined to be an illegal jump instruction. The sandbox in this embodiment will terminate its execution and record information related to this single jump instruction.

[0067] Protecting the `Call` instruction ensures the legitimacy of the branch target address, similar to `JUMP`. In x86-64, the difference between `Call` and `JUMP` instructions is that `Call` instructions are used for function calls, meaning they invoke normal functions such as AOT memory amplification or AOT calling the local machine. A whitelist policy is used to match these functions; if a function doesn't match, the sandbox provided in this embodiment will terminate its execution and log relevant information.

[0068] The return address pops the value from the top of the stack into the PC register. Based on this characteristic, many attackers modify the stack value and use it to change the program's control flow. Therefore, in the solution provided in this embodiment, the control return address is within the module's memory boundary. If the control return address is outside the memory boundary, it is determined that the return address has been modified. The sandbox in this embodiment will terminate execution and record relevant information.

[0069] Furthermore, in practical applications, another Return instruction needs to be set in WAMR. This is because CPU control should be passed to the AOT-compiled WebAssembly via the Call instruction in the virtual machine. Therefore, it is necessary to verify that the address of the Return instruction in the function of the AOT-compiled WebAssembly is consistent with the address of the next instruction.

[0070] Another possible attack involving system calls (syscalls) is to use them to redirect the virtual machine's control flow. Theoretically, AOT-compiled WebAssembly should not contain system call instructions, as all system calls should be invoked through the WebAssembly system interface. Therefore, in this embodiment, all system call instructions are disabled. When a syscall instruction is detected within the sandbox, program execution will be terminated, and related information will be recorded.

[0071] To more accurately identify access commands, combined with Figure 3 As shown, the inspection instruction module 120 further includes: a memory access judgment unit 1204;

[0072] The memory access judgment unit 1204 is used to judge whether the received memory access meets the legal conditions; the legal conditions include: the target of the memory access is stack memory, the target of the memory access is the linear memory segment corresponding to AOT compilation, and the target address of the memory access is within a preset list.

[0073] Before each memory access instruction, if the following conditions are met: (1) the target of the memory access is the stack memory; (2) the target of the memory access is a linear memory segment of the module; (3) the target of the memory access is a valid whitelisted memory address, then the memory access instruction is valid. Otherwise, it is an invalid memory access.

[0074] The execution module is used to execute the WASM native code obtained after AOT compilation.

[0075] The execution module is used to execute the engine and then execute the AOT-compiled WebAssembly, as well as the instrumented code.

[0076] Furthermore, the sandbox also includes: searching for AOT modules;

[0077] The AOT-finding module is used to detect the memory block storing the WASM native code after the AOT-compiled WASM native code has been loaded into the virtual machine, in order to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory.

[0078] It's conceivable that before using the instrument, it's necessary to confirm the location of the AOT-compiled WebAssembly in memory, as it doesn't belong to the WebAssembly virtual machine's text segment. When Intel PIN tests a program, it first analyzes the entire program to obtain execution information, such as the location of texture segments. However, since the AOT-compiled WebAssembly is not in the virtual machine's text segment, PIN cannot directly test this part. This makes testing AOTWebAssembly also difficult because its format is not the standard Extensible Linking Format (ELF).

[0079] This embodiment addresses the aforementioned problem by detecting the code after the WebAssembly virtual machine loads. During loading, the accurately AOT-compiled WebAssembly is loaded into memory and can be considered self-modified code. Intel PIN codes can detect self-modified code. However, the exact memory address of this self-modified code needs to be known. In one embodiment, this is combined with... Figure 1 As shown, taking the WAMR virtual machine as an example, the AOT-compiled WebAssembly is loaded into a memory block allocated by mmap() with a 32-bit flag. The 32-bit flag of mmap() requires mmap() to map a memory block within the first two gigabytes of memory space. Therefore, the AOT-compiled WebAssembly will be placed at address [0x00000000, 0x80000000]. SWAM uses the PIN's SetSmcSupport() function to enable support for self-modifying code, and it only checks the code stored in the memory block at address [0x00000000, 0x80000000].

[0080] The sandbox provided in this embodiment is named SWAM (Sandboxing WebAssembly Ahead-of-time Modules), a dynamic tool based on Intel PIN. In practical applications, SWAM extracts the memory layout and registered AOT modules during WASM runtime, including the module addresses and linear memory ranges. Then, SWAM performs dynamic inspection on the AOT modules, requiring all control flow transfers and data accesses to undergo boundary checks. In this way, the memory safety of WebAssembly modules can be enforced.

[0081] Exemplary methods

[0082] This embodiment also discloses a sandbox memory isolation method, such as Figure 4 As shown, the storage isolation method includes the following steps:

[0083] Step S1: Extract code segment information and WASI function information from the WASM virtual machine using dynamic instrumentation tools; this step is performed by the analysis instrumentation module.

[0084] Step S2: Analyze each branch instruction received during the AOT compilation runtime to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on the preset whitelist; this step is performed by the instruction checking module.

[0085] Step S3: Execute the WASM native code obtained after AOT compilation. This step is performed by the execution module.

[0086] Furthermore, the method also includes:

[0087] After the AOT-compiled WASM native code is loaded into the virtual machine, the memory block storing the WASM native code is checked to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory. This step is implemented by the AOT module search.

[0088] Thirdly, this embodiment also discloses a computer-readable storage medium, wherein the computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the steps of the memory isolation method.

[0089] As a computer-readable storage medium, the memory can be configured to store software programs, computer-executable programs, such as program instructions or modules corresponding to the methods in the embodiments of this disclosure. The processor executes functional applications and data processing by running the software programs, instructions, or modules stored in the memory, thereby implementing the methods in the above embodiments.

[0090] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and application programs required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory may include high-speed random access memory (RAM) and non-volatile memory. Examples include various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks; these can also be transient storage media.

[0091] To evaluate SWAM's effectiveness in defending against these attacks, a specific verification example was conducted by constructing five malicious WASMAOT modules. These modules either attempted to break control flow restrictions using one of four instructions or made illegal memory accesses outside the linear memory range. The results showed that SWAM was able to detect all attacks launched by the malicious WASMAOT modules.

[0092] In the verification experiment of this embodiment, the threat model uses a WASM virtual machine as the FaaS platform for execution backend. In the execution backend, users upload AOT-compiled WASM code for rapid execution and wait for the results. One WASMVM can host multiple WASM AOT modules uploaded by different users. The VM is responsible for isolating different modules. It is assumed that a malicious user (i.e., an attacker) might upload arbitrarily modified AOT code to launch an attack. When an attacker uses a WASM module to escape the sandbox at runtime, firstly, AOT achieves the fastest execution among the three detection modes; secondly, placing AOT compilation on the user end reduces the burden on the FaaS platform, meaning they do not need to include an AOT compiler, which significantly increases the codebase and has a higher probability of introducing errors. Therefore, the method provided in this embodiment can achieve excellent execution results.

[0093] Control flow hijacking attacks involve exploiting software vulnerabilities to control indirect branch instructions (Ret, Jmp, and Call) and hijack the control flow. In x86-64 assembly language, the Jmp instruction executes an unconditional jump. This transfer structure alters the execution flow by changing the program counter. WASM does not allow arbitrary jumps. Before executing a jump instruction, WASMVM calculates the target address by adding the base address of the jump table and the jump offset. However, in AOT-compiled code, the method provided in this embodiment can inject arbitrary jmp instructions to jump to invalid addresses and modify the control flow.

[0094] The call instruction is similar to the Jmp instruction, except that it pushes the current IP register and CS register onto the stack so that it can return to the address of the next instruction after the call is completed. Similarly, the method provided in this embodiment can insert a Call instruction into AOT-compiled code to modify the control flow. The Ret instruction locates the return address on the stack and jumps to it. This embodiment can use Push or Pop instructions to modify the stack values. Furthermore, this embodiment can also overwrite protected registers (such as rsp, rbp) to change the stack boundaries. Therefore, the Ret instruction can transfer control flow to the target address.

[0095] Programs make system calls (syscalls) to request operating system services, such as network communication and file access. In the WASM sandbox, direct system call invocation is prohibited; a module should always resort to WASI to obtain system services. However, AOT-compiled code may maliciously contain unaudited syscall instructions. Therefore, this embodiment bypasses WASI by prohibiting direct system call invocations to avoid security issues.

[0096] In WebAssembly, there are additional local and global variables used to store the data being used. These variables can be accessed using four instructions related to "global" and "local". Local variables are initialized to zero by default and stored in the global operand. The instruction `local.set$vali32` creates a local variable named `$var`, and `local.get$val` pushes the value of `$val` onto the operand stack. Local variables do not have a stable address and will quickly disappear if not stored on the operand stack using `local.get`. The instruction `global.set$val` creates a global variable named `$var` and stores it in the global operand. `global.get$var` pushes the value of `$val` onto the operand stack. The WASM virtual machine stores local and global data in different locations. Lucet uses its own stack (the VM's stack) for storage, while WAMR stores data in its heap (the VM's heap). Regardless of where the data is stored, instructions related to memory operations (Mov, Lea, Add, Sub, And, Or, Xor) can be inserted into the AOT-compiled code, and then the value at any memory address can be modified.

[0097] Different WASM virtual machines support different AOT binary data. For example, WAMR defines its own AOT format and loader (a unique format with the '.aot' suffix). WasmEdge and Wasmtime support converting compiled code into static libraries, conforming to the ELF format. Although different WASM virtual machines use different AOT binary formats, all AOT code is native code, which can be directly loaded and executed. Therefore, the suggested attack can be launched by rewriting native code. Native code is the code compiled from AOT. Taking WAMR as an example, first, the AOT binary file in WAMR begins with a '.aot' identifier (8B), followed by partial type declarations (8B) and partial lengths (4B), for a total of eight partial types, including the target part (containing platform information), the text part (containing executable instructions), and so on. For example, the platform information represents the target part, the program constant data in the initial part, the executable instructions in the text part, the information about each function offset in the function part, and so on. Figure 5This demonstrates how a piece of C++ code (storing an integer in memory) is compiled into AOT code. The C++ code is first compiled into WASM bytecode using wasi-sdk-14 (LLVM), then compiled into AOT using wamrc (WAMR), and finally compiled into AOT code using wamrc (WAMR's AOT compiler). The compiled AOT code is then stored in... Figure 5 This is represented as "native code," where "xor%eax,%eax" is modified to "callq*(%rdx)" to launch the attack. Therefore, this attack redirects program control flow to the ".text" segment of the WASM virtual machine. Similarly, control flow can be altered by inserting malicious Jmp, Call, Ret, or Syscall instructions.

[0098] Experiments verified that SWAM did not issue false alerts for normal applications. This embodiment also evaluated the performance of SWAM on Polybench, SPEC2017, and PARSEC benchmarks. The overall excess gain of the SWAM system ranged from 1.44x to 8.34x, with a geometric mean of 4.76x for overall overhead. The overhead of SWAM's tooling code was only 1.28x to 3.92x, with a geometric mean of 2.53x. These performance overheads are acceptable compared to the performance of interpreting WebAssembly code. The performance of interpreting WebAssembly code—SWAM is 56.69x faster than interpreted code.

[0099] This embodiment proposes a binary instrumentation-based sandboxing scheme, called SWAM, to restrict untrusted AOT modules through dynamic binary tools. A prototype of SWAM was implemented using Intel PIN, and its effectiveness and compilation efficiency were evaluated. This embodiment also presents general methods to address control flow and data attacks, as well as methods to strengthen module boundary checks, verify control flow, and provide secure access to system calls. This addresses the deficiency of low runtime security performance caused by the lack of unified rules for handling AOT files among all WebAssembly AOT compilers.

[0100] This invention proposes a sandbox, memory isolation method, and storage medium based on binary instrumentation, applied to memory isolation during WASM bytecode encoding using AOT compilation. The sandbox extracts code segment information and WASI function information from the WASM virtual machine using dynamic instrumentation tools; analyzes each branch instruction received during AOT compilation runtime, confirming that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on a preset whitelist; finally, it executes the WASM native code obtained after AOT compilation, thereby achieving managed access to untrusted AOT code. The sandbox and memory isolation method provided in this embodiment dynamically detect the AOT module during WASM runtime, extracting the runtime memory layout and the storage address and linear memory range of the AOT module, restricting control flow and data access, thus providing memory security attributes and exhibiting high practicality.

[0101] It is understood that those skilled in the art can make equivalent substitutions or modifications to the technical solution and inventive concept of the present invention, and all such substitutions or modifications should fall within the protection scope of the appended claims.

Claims

1. A sandbox based on binary instrumentation, characterized in that, The sandbox is used for memory isolation when encoding WASM bytecode using AOT compilation. The sandbox includes: an analysis instrument module, an inspection instruction module, and an execution module. The analysis instrumentation module is used to extract code segment information and WASI function information from the WASM virtual machine using dynamic instrumentation tools; The inspection instruction module is used to analyze each branch instruction received during AOT compilation runtime, and to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on a preset whitelist. The execution module is used to execute the WASM native code obtained after AOT compilation; The analytical instrument module includes: a code segment information extraction unit; The code segment information extraction unit is used to extract code segment information from the WASM virtual machine using a dynamic instrumentation tool; wherein, the code segment information is: the memory space allocated and loaded by the WASM virtual machine for AOT compilation; The code segment information extraction unit further includes: an image leveling instrument subunit; The image level instrument subunit is used to detect the input and output information of the AOT instance function in the image layer in order to obtain the code segment information and the linear memory boundary of the code segment information.

2. The sandbox according to claim 1, characterized in that, The analytical instrument module also includes: a function information extraction unit; The function information extraction unit is used to extract WASI-related function information; wherein, the WASI-related function information is the function entry point of the WASI system call.

3. The sandbox according to claim 2, characterized in that, The inspection instruction module includes: a single jump instruction inspection unit, a call instruction inspection unit, and a return instruction inspection unit; The single jump instruction checking unit is used to determine whether the target address of the received single jump instruction is within the code segment. If not, it determines whether the target address of the single jump instruction is a function related to WASI. If not, it determines that the single jump instruction is an illegal instruction. The call instruction checking unit is used to determine whether the received call instruction is in the preset whitelist. If it is not, it is an illegal call instruction. The return instruction checking unit is used to control the return address to be within the memory boundary corresponding to the AOT compilation, and to determine whether the address of the return instruction is consistent with the address of the next return instruction.

4. The sandbox according to claim 3, characterized in that, The inspection instruction module further includes: a memory access judgment unit; The memory access judgment unit is used to judge whether the received memory access meets the legal conditions; the legal conditions include: the target of the memory access is stack memory, the target of the memory access is the linear memory segment corresponding to AOT compilation, and the target address of the memory access is within a preset list.

5. The sandbox according to any one of claims 1-4, characterized in that, The sandbox also includes: finding AOT modules; The AOT-finding module is used to detect the memory block storing the WASM native code after the AOT-compiled WASM native code has been loaded into the virtual machine, in order to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory.

6. The sandbox according to claim 1, characterized in that, The execution module is also used to execute the engine and the instrumented code.

7. A sandbox memory isolation method, characterized in that, The method of implementing memory isolation during WASM bytecode encoding using AOT compilation with the sandbox described in any one of claims 1-6 includes: The code segment information and WASI function information are extracted from the WASM virtual machine using dynamic instrumentation tools; Analyze each branch instruction received during the AOT compilation runtime to confirm that the memory accessed by each branch instruction is within the memory corresponding to the AOT compilation or that the caller of each branch instruction is on the preset whitelist; The WASM native code obtained after AOT compilation is completed.

8. The memory isolation method according to claim 7, characterized in that, The method further includes: After the AOT-compiled WASM native code is loaded into the virtual machine, the memory block storing the WASM native code is checked to obtain the address information of the AOT-compiled WASM native code in the virtual machine memory.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that can be executed by one or more processors to implement the steps of the memory isolation method as described in claim 7 or 8.

Images