A Method for Enhancing WASM Linear Memory Security Based on Arm MTE

Abstract

This invention discloses a method for enhancing the linear memory security of WebAssembly (WASM) based on Arm hardware security features, specifically Memory Tagging Extension (MTE). This method enables MTE instruction invocation permissions in the system, adds and adapts dedicated MTE invocation instructions to the compiler toolchain and WASM system call interface WASI-libc used by developers, and modifies and replaces the memory access checking logic within the WASM runtime environment. This allows hardware supporting MTE to automatically check the legality of different WASM instances' access to linear memory, thereby improving the overall security of the WASM runtime environment and WASM programs, and increasing the difficulty for malicious programs to exploit memory defects to harm the host computer.

Description

Technical Field

[0001] This invention belongs to the field of sandbox software security, specifically involving the Memory Tagging Extension (MTE) feature, a dedicated hardware protection feature in the Arm instruction set architecture; the compilation toolchain; the WebAssembly Syscall Interface-libc (WASI-libc) standard library; the WASM runtime environment; and the linear memory of WASM instances. In particular, it relates to a method for enhancing the security of the WASM runtime environment and the linear memory security of WASM instances by utilizing Arm MTE security features. Background Technology

[0002] Sandboxing is a technique for isolating untrusted applications under the management, monitoring, and protection of a sandboxed runtime environment. Hypervisors and web browsers both require sandboxing to prevent malicious abuse. WASM, as an emerging sandboxing technology, has been widely deployed in cloud computing, edge computing, the Internet of Things (IoT), and blockchain smart contracts. While the WASM community has designed a formal semantics to ensure the security and reliability of the WASM virtual instruction set in control flow, the lack of strict and unified specifications for linear memory used by the WASM sandbox runtime environment has led to inconsistencies in the implementation of constraints on linear memory by WASM sandbox runtime environments written in different programming languages. This inconsistency centers on the protection strategies adopted by the WASM sandbox runtime environment for the linear memory of WASM programs. Most protection strategies are complex to implement and may employ potentially flawed checking logic to constrain the untrusted execution behavior of WASM instances.

[0003] Specifically, WASM linear memory has no type, is contiguous without gaps, and has no lifecycle concept. In terms of usage, WASM linear memory is used to store strings, arrays, structs, and dynamically allocated memory objects—data structures that the WASM runtime environment cannot strictly manage according to semantic specifications, but which are exposed to WASM instance manipulation. When a maliciously crafted WASM instance is able to bypass the boundary checks of the WASM runtime environment through out-of-bounds overwriting, hijacking the control flow maintained internally by the runtime environment to gain arbitrary execution capabilities within the sandbox, other WASM instances and even programs outside the WASM runtime environment face the threat of data theft and hijacked execution.

[0004] MTE (Memory Safety Tag) is an optional hardware security feature introduced in the Armv8.5-A architecture, designed to mitigate traditional memory safety issues such as stack overflows or heap overflows. MTE uses bits 56 to 59 (4 bits in total) of the physical memory address as a public tag for a 16-byte memory block starting from that address. Arm processor cores supporting MTE use dedicated CPU instructions to assign an MTE tag to the incoming memory address, provided by the True Random Number Register (RGSR_EL), to restrict abnormal behavior from other contexts on that memory block. When MTE is enabled, an MTE tag is inserted into a specified memory block, and a pointer accesses any location within that block, the pointer must hold the same tag value to have permission to access that memory block. Otherwise, the memory management unit in the Arm CPU will fail to verify the tag value because it does not match the tag value in the actual physical memory, resulting in a synchronous or asynchronous exception that causes the operating system to terminate the program. Furthermore, high-level programming languages ​​often use CPU instructions tailored for MTE features through inline assembly or by calling compiler-generated built-in functions. For example, the IRG command is used to randomly generate MTE tags for memory blocks, LDR retrieves the MTE tags inserted into the memory block, and STG sets the MTE tags to a region of 16 bytes following the corresponding physical address. Summary of the Invention

[0005] The purpose of this invention is to alleviate the potential memory corruption problem that still exists in the linear memory of existing WASM sandbox runtime environments and WASM instances under the Arm instruction set architecture that supports MTE.

[0006] To address this problem, the present invention utilizes Arm MTE hardware security features to protect WASM linear memory. This method includes an instruction set extension stage, an instruction set adaptation stage, and a stage that enables the user-mode WASM runtime environment to use relevant MTE instructions. Technical solution

[0007] The extended instruction set phase includes the following three steps:

[0008] The first step is to add a sub-instruction set associated with the actual hardware security feature (MTE) to the WASM bytecode representation specification, and bind the extended MTE bytecode used to identify this sub-instruction set to any opcode prefix not yet restricted by the WASM specification, such as the prefix 0xFD13 or 0xFF. The second step is to sequentially record all extended MTE bytecodes associated with specific MTE instructions and used by WASM, incrementing from zero in order of arrangement, under the sub-instruction set. Then, all extended MTE bytecodes should use a 16-byte aligned linear memory address of the WASM instance managed by the WASM runtime environment as operands. For some instructions, such as those with MTE tags, an MTE tag value can be optionally passed, and the address with the MTE tag is returned as the instruction execution result.

[0009] The second step involves modifying the front-end and back-end of the compiler toolchain that developers are accustomed to using. This involves generating built-in functions corresponding to the extended MTE bytecode for the front-end of the compiler toolchain and registering the specific definitions of the newly added sub-instruction set for the back-end of the compiler toolchain. This enables the compiler toolchain to correctly compile the extended bytecode according to the code and submit it to the subsequent WASM runtime environment for interpretation and execution.

[0010] The third step is to modify the specific WASM runtime environment, adjust the functions within the WASM runtime environment used to parse bytecode, and then match the extended MTE bytecode prefix within it to implement the specific functions represented by the bytecode in sequence, so that it can understand and execute the extended MTE bytecode accordingly.

[0011] The instruction set adaptation phase includes the following seven steps:

[0012] The first step is to add a stub function to the compilation toolchain that can automatically insert extended MTE bytecode before all memory access instructions to obtain the MTE tag, so as to ensure that normal memory access after the subinstruction set is extended will not cause MTE tag mismatch anomalies.

[0013] The second step requires explicitly aligning and verifying the size of the target memory block to be manipulated by 16 bytes before the memory operation functions provided by WASI, such as dlmalloc and free. Afterward, the compiler toolchain should be selectively invoked to generate built-in functions for the subinstruction set. If the alignment condition is not met, the WASM runtime environment should be notified to abandon the execution of the WASM instance.

[0014] The third step involves adjusting the functions related to memory allocation and access in the WASM runtime environment. This includes adding auxiliary functions that utilize machine instructions such as LDG, IRG, and STG to acquire, allocate, and insert MTE tags. Furthermore, unnecessary and complex boundary checks in the memory allocation functions for linear memory are removed and replaced with memory access using addresses with MTE tags specific to the WASM instance context. The WASM runtime environment then handles any MTE tag mismatch exceptions it catches. If an exception occurs, it is reported by the kernel signal handlers registered with the WASM runtime environment, and the running WASM instance in the execution flow context is immediately trapped, terminating its execution.

[0015] The fourth step involves modifying the WASM runtime environment's context for managing WASM instance memory access and all memory operation-related processing functions. Existing data structures should be modified to hold MTE tags, but the tag values ​​should be invisible to the WASM instance. In 64-bit WASM programs, and without violating existing WASM specification constraints, the high 16 bits of the 64-bit linear memory address managed by the WASM runtime environment should continue to be filled with the MTE tag according to bits 56 to 59 of the actual hardware. For 32-bit cases, the WASM-managed linear memory address still needs to be aligned to 64 bits, and the MTE tag should still be filled with bits 56 to 59, reserving the remaining redundant bits for subsequent permission verification and expansion. For 32-bit WASM memory addresses, the WASM-managed linear memory address is aligned to 64 bits. The remaining redundant bits are reserved without further processing.

[0016] The fifth step involves introducing fixed-size protection tag blocks at the boundaries of each memory block within the linear memory region. This is achieved through explicitly enabled hardware mechanisms and the WASM sandbox environment's tag management and retrieval mechanisms for accessed addresses. This ensures that stack overflows, variable-length read / write overflows due to type inconsistencies, or out-of-bounds read / write operations on linear memory can be detected by the WASM environment. The linear memory region comprises a static constant area, an auxiliary stack area, and a heap memory area. The fixed size of the protection tag block is set to 16 bytes, the minimum granularity of the MTE. The tag blocks are inserted at the beginning and end of the three regions, with adjacent regions sharing the same protection memory block. Therefore, each 64KB block of linear memory introduces an additional 64 bytes of protection overhead.

[0017] The sixth step automatically uses the address mask and the number of times memory.grow has been called by the WASM instance to constrain the farthest accessible memory index of the WASM instance, while protecting the MTE tag value in the context with a mask so that it is not visible to the WASM instance.

[0018] Step 7: Modify the memory access judgment logic. When the WASM runtime environment is a specific WASM instance accessing memory, obtain the MTE tag value from the context environment and write it to the address held by the pointer.

[0019] Enabling the user-mode WASM runtime environment to access relevant MTE commands involves the following two steps:

[0020] The first step is to call the system-provided user-space check function and determine whether the system supports MTE by verifying the return result of the check function. On systems that support Arm MTE, MTE is explicitly enabled for the WASM sandbox runtime environment.

[0021] The second step is to request MTE support for memory pages by using functions exposed to user space by the operating system before requesting memory pages from the operating system in the WASM runtime environment. Beneficial effects

[0022] The beneficial effects of this invention are: by introducing Arm MTE protection into the WASM runtime environment and WASM linear memory, it reduces the use of complex checking logic that may have logical defects on the software side, reduces the feasibility of launching hijacking attacks or stealing secret data across WASM instances, increases the difficulty of using return-oriented programming or heap overflow to hijack the control flow in the WASM sandbox runtime environment, and enhances the overall stability and security of the WASM instance and the WASM sandbox runtime environment. Attached Figure Description

[0023] To describe how other advantages and features of the present invention can be obtained, a more specific description of the principles corresponding to the above brief description will be presented with reference to the modified steps and specific embodiments shown in the accompanying drawings. It should be understood that these figures only depict the disclosed embodiments and are therefore not intended to limit the scope thereof; the principles herein are described and explained in more specific and detailed manner using the accompanying drawings, wherein:

[0024] Figure 1 This illustrates the general outline of the objects to be adapted and modified in this invention.

[0025] Figure 2 This illustrates the additional functionality that the present invention requires to be added to the compiler toolchains commonly used by developers.

[0026] Figure 3 The modified logic of the WASI heap memory allocation and deallocation functions in this invention is shown.

[0027] Figure 4 The WASM execution flow after enabling this invention is shown. Detailed Implementation

[0028] To facilitate a quick understanding of the specific implementation logic of this invention by those skilled in the art, the following will be combined with... Figures 1 to 4 The embodiments of the present invention are described below.

[0029] It should be understood that the embodiments of the present invention utilize optional security features under the Arm hardware instruction set to simplify the runtime environment memory access boundary checking logic and enhance WASM linear memory safety, and are clearly for illustrative purposes only and not for limitation. Moreover, the described embodiments are only a part of the embodiments of the present invention, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention. Unless otherwise defined, the technical terms used in the present invention should have the ordinary meaning that can be understood by those skilled in the art.

[0030] The embodiments of this invention use Linux as the operating system for deploying the WASM runtime environment, C / C++ as the high-level programming language for generating WASM, LLVM as the compilation toolchain for compiling C / C++ into WASM, WASI-libc as the link library for external system call functions, and wasmtime as the WASM runtime environment. Provided that the Linux operating system version and the selected hardware environment support MTE, this invention can be implemented with minimal modifications to the LLVM compilation toolchain and wasmtime according to the design proposed in this invention.

[0031] Regarding the details disclosed in this embodiment, the embodiment should add built-in functions to the LLVM frontend and add extended instruction definitions to the LLVM backend, so that high-level language code that externally calls built-in functions can be compiled by the LLVM toolchain into MTE instructions that request the WASM runtime environment to execute. Some built-in functions, such as those requesting MTE tags, will have their input and return parameters converted into the source linear memory address required by the new sub-instruction set, the optional input MTE tag value, and the optional return destination linear memory address, thereby generating the extended WASM bytecode. Secondly, based on the hardware instruction set architecture of the computer used, WASI-libc differentiates the built-in functions provided to WASM for using MTEs. Optionally, the MTE built-in functions can be selectively left empty or provide corresponding query, request, or insert MTE tag logic. Furthermore, to adapt the extended MTE instruction set for the WASM runtime environment, it is necessary to interpret the extended MTE bytecode to actually request and insert MTE tags into the linear memory of the corresponding WASM instance. Finally, the data structure used to manage the WASM instance context in the WASM runtime environment was modified to hold the tagged address assigned to the WASM instance and to ensure that it is not visible to the WASM instance through masking operations. Finally, unnecessary boundary check logic in the WASM runtime environment was removed.

[0032] like Figure 1 As shown in the first row of the left column, modifying the compilation toolchain in this embodiment extends the LLVM front-end and back-end. The specific steps are as follows:

[0033] The first step is to extend the functionality provided by the compiler toolchain frontend to assist high-level programming languages ​​in generating MTE bytecode. For example... Figure 1 As shown in the second row of the left column, this embodiment requires extending the LLVM frontend Clang to add built-in functions for manipulating MTE tags to the target architecture WASM. Specifically, this embodiment adds two types of interfaces to the built-in function definition file in the Clang source code responsible for handling the WASM target:

[0034] (1) MTE tag request interface. This interface is designed to declare to the compiler that when this function is called in the source code of a high-level programming language, a new MTE tag needs to be requested from the operating system for the memory area pointed to by the pointer ptr in the WASM runtime environment. In this embodiment, the return value of this function is the address containing the MTE tag information. (2) MTE tag insertion interface. This interface is used to notify the WASM runtime environment to request the operating system to apply the MTE tag to the actual memory region.

[0035] In this embodiment, by adding the aforementioned declaration to the Clang frontend, LLVM can recognize the `__builtin_wasm_` prefix function calls it scans as LLVM Intrinsic when parsing high-level language source code. This processing method allows these function calls to be preserved in the LLVM Intermediate Representation (IR) stage, enabling subsequent binding to the WASM backend and thus generating code segments with explicit execution semantics containing extended MTE bytecode. This corresponds to... Figure 2 The modifications are shown in the left column.

[0036] The second step, to ensure all memory access operations are protected by MTE, is to add automatic stub functions to the middle of the compiler toolchain. For example... Figure 1 As shown in the third row of the left column, in this embodiment, the stub function is the automated instruction insertion mechanism introduced into the LLVM middleware. This mechanism is specifically implemented as a pass-by-pass tuning and optimization module (Pass) that takes LLVM IR as input. Its core function is to scan all memory access instructions within the function during the conversion of LLVM IR to WASM bytecode and allocate and insert MTE tags beforehand, thereby ensuring that the memory access behavior of the WASM instance is correct after adapting to the MTE. Specifically, the workflow of this module is as follows:

[0037] (1) Instruction Scan. Traverse the instruction references (IRs) of all functions in the current compilation unit to identify all memory access operations. (2) MTE tag acquisition. For each memory access instruction identified by LLVM, before the memory access instruction and based on the memory address it accesses, an attempt is made to obtain the MTE tag held by the WASM runtime environment by extending the MTE instruction.

[0038] Through this MTE instruction insertion mechanism provided by the automated stub function, under Arm instruction sets that support MTE features, this embodiment can automatically include MTE tag operation requests in the compiled WASM bytecode. This corresponds to Figure 2 The modifications are shown in the second column from the left.

[0039] The third step involves binding the auxiliary functions of the compiler toolchain frontend to the compiler toolchain backend, creating MTE bytecode definitions, and establishing pattern matching rules for the instruction selection layer within the backend. In this embodiment, to ensure that the LLVMIR generated in the preceding steps can ultimately be transformed into a WASM object file containing extended MTE bytecode, this step requires extending the instruction descriptions for the WASM target to the LLVM compiler backend and further extending the code generation (CodeGen) module within the Clang backend. This facilitates the subsequent compilation optimization of LLVM machine instruction nodes and the identification and handling of operations involving MTE tags during the target code generation stage. Specifically, this step can be divided into three sub-steps, corresponding to... Figure 2 The following is an example shown on the right:

[0040] (1) For binding auxiliary function functions, this step requires adding two new instruction definitions corresponding to the aforementioned built-in functions: 1) MTE tag request function. This function takes a memory pointer as input and requests an MTE tag from wasmtime for a given memory region. 2) MTE tag insertion function. This function takes a memory pointer and an integer tag value as input, and its semantics are to request a tag value from wasmtime for a given memory region.

[0041] (2) For creating MTE bytecode definitions, in this embodiment, this sub-step first needs to extend TableGen under the LLVM WASM target instruction set. TableGen is a declarative language provided by LLVM used to describe the instruction set, register file, and calling convention of the target platform. The definitions in TableGen describe the input / output characteristics of the instructions and their assembly representation. TableGen also specifies the format and specific value of each opcode. Optionally, 0xFD13 or 0xFF is used as the prefix of the operand table formed by the sub-instruction set, and then the instructions are distributed to specific MTE instructions that can be requested from the operating system by wasmtime for execution through routing matching. In this embodiment, the MTE tag request instruction and MTE tag insertion instruction are newly added by LLVM, namely mte.new_tag and mte.set_tag. In addition, the definitions provided for TableGen must ensure that the address passed to it is aligned to 16 bytes, so as to strictly meet the requirements of MTE hardware characteristics. At the same time, it is also necessary to further extend the code generation (CodeGen) module in the Clang backend to map the calling semantics of the aforementioned built-in functions to LLVM machine instruction nodes for subsequent compilation optimization. Specifically, this step defines a processing method for the newly added built-in function in the compiler's WASM instruction set, specifically for the built-in function emission function added in the first step. The process involves:

[0042] 1) Parameter Acquisition and Validation. Parse and extract the actual parameters passed to the built-in functions from the source code, and check whether their quantity and type conform to the predefined semantic specifications. 2) IR Instruction Node Generation. The aforementioned built-in functions are converted into corresponding internal function call instructions using the IR representation generation interface, such as IRBuilder::createCall or getIntrinsic function calls. These internal function call instructions, as high-level intermediate representation nodes, preserve the complete semantics of the original operation while allowing subsequent compilation optimization processes such as instruction scheduling and register allocation to perform valid analysis and transformation.

[0043] (3) Regarding the pattern matching rules for establishing the instruction selection layer, in this embodiment, to ensure that the Intrinsic code in the preceding stage can be correctly translated into specific WASM bytecode, functions involving MTE tag operations need to bind corresponding pattern matching rules in the instruction selection description layer of the LLVM backend. Specifically, the following methods are used to achieve this:

[0044] 1) Node identification and conversion. If the above-mentioned internal function node is identified, it is converted into the corresponding extended instruction opcode under the WASM target architecture according to the preset matching rules. 2) Operand constraints. The rules strictly limit the type and format of operands to ensure that the generated extended instructions are type-safe and conform to the WASM binary encoding standard in terms of format.

[0045] As for WASI-libc, which is required for compatibility with WASM programs, it is as follows: Figure 1 As shown in the first row of the second column from the left, MTE instructions need to be selectively enabled based on the parameters selected before compilation and the instruction set architecture on the host machine. If the actual hardware instruction set is Arm architecture and supports MTE, then a wrapper function is added according to the extended MTE bytecode, and the function generated in the compilation toolchain corresponding to the sub-instruction set is called normally inside the wrapper function. Otherwise, the built-in function is not called and the wrapper function is set to null. Optionally, the wrapper function in the current embodiment can be implemented through conditional compilation and macro definition, which corresponds to... Figure 1 The second row of the second column from the left. Next, as... Figure 1 From the left, the second column, third row, fourth row, and... Figure 3 As shown, in this embodiment, the `dlmalloc` function is forced to align the beginning of the memory block to be allocated with 16 bytes. After obtaining the memory block from a memory block chain in the heap memory manager, the built-in MTE tag value acquisition and setting functions provided by LLVM are immediately called, and the execution of the subsequent original functions continues. For the `free` function, in this embodiment, after obtaining the starting address of the memory block to be freed, it is necessary to check whether the passed address is aligned with 16 bytes. If the check fails, an exception is thrown and the WASM runtime environment is notified to terminate the execution of the WASM program. Otherwise, the memory block can be freed and the built-in functions provided by the compiler toolchain are called to forcibly reset all MTE tags on the memory block, and the execution of the subsequent original functions continues.

[0046] For modifying the specific WASM runtime environment, such as Figure 1 As shown in the first row on the right, this embodiment requires adding the operation of enabling MTE instructions to wasmtime and adapting to the new instruction set added to the compilation toolchain.

[0047] The first step is to enable the MTE feature. Before starting and loading the WASM instance, the `getauxval` function is used to check if the underlying hardware supports MTE. Specifically, in the wasmtime initialization function for the AArch64 architecture, the hardware characteristic representation of the current CPU is obtained, and it is checked whether the MTE support flag `HWCAP2_MTE` is included. If the hardware does not support MTE, the initialization process is terminated to avoid executing WASM programs that depend on MTE. Otherwise, the system function `prctl` can be called to allow the current wasmtime to call MTE instructions, and the MTE exception mode is explicitly configured to synchronous mode. If the enabling operation fails, the execution of wasmtime is immediately terminated and an error is thrown into the error log.

[0048] The second step is to adapt the MTE extended bytecode. For example... Figure 1 As shown in the second row of the right column, this embodiment adds the adaptation logic for MTE extended bytecode to wasmtime. First, matching and format processing of the MTE subinstruction set prefix are added to the bytecode parsing function. Second, the interpretation and execution of the newly added mte.new_tag and mte.set_tag instructions in LLVM are implemented. The interpreter automatically obtains the virtual address to be accessed from the current memory access context, then requests the MTE tag value that the virtual address should hold through the IRG instruction, or inserts the MTE tag into the corresponding virtual address through the STG instruction, while consuming parameters in the execution stack. Specifically, for the mte.set_tag instruction, wasmtime retrieves the parameter from the operand stack and verifies its type. After the type check passes, it matches and executes the corresponding MTE instruction and returns the address result with the MTE tag.

[0049] The third step is to modify the memory management data structures and organization logic. For example... Figure 1 As shown in the third row of the right column, the memory management of the WASM instance in the WASM runtime environment is modified. Under the premise of this embodiment, and ensuring that the 64-bit WASM program does not violate the existing WASM specification, specific bits in the high 16 bits of the linear memory address, corresponding to hardware bits 56 to 59, are used to set the MTE tag obtained through wasmtime. For 32-bit WASM program addresses, they still need to be aligned to 64 bits and processed in the same way, with the remaining 12 redundant bits reserved for future expansion. When pointers are needed internally within the WASM program, wasmtime needs to be calculated to mask the MTE tag bits. Simultaneously, a call counter for the memory.grow instruction is maintained for each instance, combined with a mask to limit the furthest accessible area, thereby ensuring that any MTE tag mismatch anomalies only occur within the WASM instance. Additionally, as... Figure 3As shown, fixed-size protection tag blocks are introduced at the boundaries of each region of linear memory, namely the static constant area, the WASM instance auxiliary stack area, and the head and tail of the heap memory. This allows adjacent regions to reuse the same protection block. Therefore, each 64KB block of linear memory adds only 96 bytes of overhead.

[0050] Ultimately, the effect achieved in this embodiment is as follows: Figure 4 As shown: The high-level programming language, along with the modified WASI-libc, is compiled into a WASM binary file that supports MTE extended bytecode. When this WASM binary file needs to be run, wasmtime, adapted for MTE extended bytecode, can be used to parse and instantiate it. Thanks to the modified compilation toolchain, in the instantiated WASM, every memory access instruction in its internal code segment contains an instruction requesting wasmtime to obtain MTE tags. This allows wasmtime's internal memory and MTE tag manager to insert and automatically maintain MTE tags in its linear memory whenever it needs to request heap memory or perform a specific memory access operation. The effect is as follows: Figure 4 The interaction steps 4, 5, 6, and 7 are shown in the diagram. The wasmtime instruction dispatch and execution unit can recognize this type of extended MTE bytecode embedded in the regular instruction stream and can initiate a memory request with an MTE tag to the operating system through its internal linear memory and MTE tag manager. This achieves hardware memory safety protection for the linear memory of the WASM instance.

[0051] The embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention, and can be used in various other combinations, modifications, and environments. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A technique for enhancing the linear memory security of the WASM sandbox runtime environment and WASM instances by combining Arm MTE hardware security features, characterized in that, Includes the following steps: Step 1: Extend the WASM instruction set for the compiler toolchain commonly used by developers; Step 2: Adapt the extended WASM instructions to WASI-libc; Step 3: Enable MTE for the WASM runtime environment; Step 4: Adapt the extended WASM instruction set to the WASM runtime environment.

2. The WASM instruction set extension for compiler toolchains commonly used by developers as described in claim 1, characterized in that, In step 1, to adapt to MTE by extending the WASM instruction set, a new WASM sub-instruction set (hereinafter referred to as the sub-instruction set) needs to be added. Within the sub-instruction set, a series of extended bytecode (hereinafter referred to as extended MTE bytecode) are defined to instruct the WASM runtime environment to perform corresponding MTE feature operations. Step 1 can be divided into two sub-steps: Sub-step 1: Modify the compiler toolchain front end: In the file used to define built-in functions within the compiler toolchain front end that developers are accustomed to, add corresponding built-in function definitions and bind them to the sub-instruction set newly added to the compiler toolchain back end; at the same time, the compiler toolchain back end should be able to automatically insert extended instructions to obtain MTE tag values ​​before memory access instructions, so as to ensure the correct functionality of memory access logic after the introduction of the MTE mechanism. Sub-step 2: Modify the compiler toolchain backend: In the compiler toolchain backend commonly used by developers to assist in the generation description file of the target instruction set architecture, define a sub-instruction set adapted to the characteristics of MTE hardware, and register the extended MTE bytecode under the sub-instruction set. The WASM runtime environment interprets the extended MTE bytecode to perform operations such as getting or inserting MTE tags.

3. The method as described in claim 2, characterized in that, All MTE bytecode added to the sub-instruction set in sub-step 2 includes, but is not limited to: IRG instruction, which inserts a true random MTE tag value into the provided address and returns the address where the MTE tag value was inserted; STG instruction, which actually writes the address with the MTE tag along with the following 16 bytes of physical memory to the address with the MTE tag attached. The LDG instruction retrieves the MTE tag at a given memory address.

4. The method as described in claim 1, characterized in that, Step 2, adapting the WASI-libc instruction set, involves the following two steps: Step 1: In WASI-libc, the built-in functions provided by the compilation toolchain are extended and corresponding to the hardware instruction set architecture and actual compilation parameters. The built-in functions of the compilation toolchain are selectively filled in or left empty, so that the extended MTE bytecode can be called when the instruction set architecture and parameters allow it, and no processing is done when it does not allow it. Step 2: Before the actual memory allocation or release functions in WASI-libc, perform 16-byte alignment on the requested memory or 16-byte alignment or alignment verification on the released memory; after successful alignment or verification, call the built-in functions for requesting MTE tags and inserting MTE tags under the sub-instruction set in sequence to request new MTE tags for the memory block to be operated on, and make the WASM runtime environment request the operating system to deploy the tag value to the corresponding address.

5. The method as described in claim 1, characterized in that, It must be deployed on an operating system that allows or supports user-mode MTE instruction call permissions, and step 3 includes the following three sub-steps: Sub-step 1: Check if the system supports the use of allocation and insertion commands in the MTE hardware security features in user mode; Sub-step 2: After passing the check in sub-step 1, call a specific system function or indirectly enable MTE for the WASM runtime environment using specific assembly instructions; Sub-step 3: When the WASM runtime environment needs to request a memory page from the operating system and the request is successful, the starting address of the memory page, the size of the requested memory page, and the newly expanded page flags are provided as input parameters to the memory page protection function; among them, the newly expanded flags, compared with the original page flags provided to the operating system, include an additional MTE protection enable flag.

6. The method as described in claim 1, characterized in that, Step 4, adapting the extended MTE instruction set for the WASM runtime environment, includes the following five sub-steps: Sub-step 1: Define the newly added sub-instruction set in the compilation toolchain in the WASM runtime environment so that all extended MTE bytecode under the sub-instruction set can be parsed by the WASM runtime environment into the MTE instructions that actually need to be requested from the operating system for execution; Sub-step 2: First, in the WASM runtime environment's functions used for matching and interpreting bytecode, the specific prefix corresponding to the sub-instruction set is registered. The interpretation function enters the scope for processing the sub-instruction set by matching the prefix, and then uses branch conditional statements to process the extended MTE bytecode and potentially undefined bytecode in sequence; thus, the WASM runtime environment can call the actual MTE hardware instructions in the same corresponding way by interpreting the extended MTE bytecode defined under the sub-instruction set. Sub-step 3: Modify the structure for managing WASM instance memory access in the WASM runtime environment so that each WASM instance carries the actual MTE tag value used in its context. Sub-step 4: By using the fixed address mask and the number of times memory.grow has been called by the WASM instance, the furthest accessible memory index of the WASM instance is constrained and the MTE tag value in the context is protected. Sub-step 5: Modify the WASM runtime environment's judgment logic after initiating a memory access for the WASM instance, so that it is constrained when calling access instructions of different word lengths to access the tagged memory boundary, and when finally accessing memory, it obtains the MTE tag value from the context maintained by the WASM runtime environment and writes it to the address held by the pointer.

7. The method as described in claim 5, characterized in that, The specific function in step 2 varies depending on the operating system; preferably, it is the prctl function under Linux.

8. An electronic device comprising a memory, a processor, and a program stored in the memory and executable by the processor, characterized in that, The processor supports Arm MTE hardware security features and, when executing the program, satisfies and implements the method as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program, characterized in that, The program can be executed on a processor with Arm MTE hardware security features and an operating system that supports Arm MTE configuration, and when executed, it satisfies and implements any one of the methods described in claims 1 to 7.

Images