Secure access method and device, electronic equipment, storage medium and program product

Abstract

The invention discloses a secure access method and device, electronic equipment, a storage medium and a program product. The security access method executed by the virtual machine comprises the following steps: analyzing a target byte code, and determining an instruction type of the target byte code; obtaining a matched operand according to the instruction type, and executing security access legality check matched with the instruction type according to the operand; and after the security access validity check is passed, executing the target byte code. According to the technical scheme provided by the embodiment of the invention, a new mode for performing secure memory access on the basis of the application program of the virtual machine in a resource limited environment is creatively provided, and the operation reliability of the virtual machine is effectively improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a secure access method, apparatus, electronic device, storage medium, and program product. Background Technology

[0002] WebAssembly (WASM) is a virtual instruction set architecture. Based on WebAssembly bytecode technology, applications can be written in various programming languages, and the written applications are converted into WebAssembly bytecode, which is then interpreted and executed by the virtual machine, thus enabling the application to run normally.

[0003] In the process of developing this application, the inventors discovered that the above-mentioned technology has at least the following problems: When WebAssembly bytecode is applied to resource-constrained devices, its executable file and instruction set need to be optimized in conjunction with device resources; this also includes the segment and function representations of the executable file. Optimization can reduce file size and improve execution performance, but the application scenarios that the device is intended for require stronger security guarantees. Therefore, both file content and bytecode execution require security policy guarantees. The security policy should cover memory access, function calls, local variable and parameter access, and conditional branch statement execution during bytecode execution. Summary of the Invention

[0004] This invention provides a secure access method, apparatus, electronic device, storage medium, and program product to enable applications to perform secure memory access in resource-constrained environments.

[0005] According to one aspect of the present invention, a secure access method is provided, executed by a virtual machine, comprising:

[0006] Parse the target bytecode to determine the instruction type of the target bytecode; the target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module;

[0007] Based on the instruction type, obtain the matching operand, and based on the operand, perform a security access legality check that matches the instruction type;

[0008] After the security access legitimacy check passes, the target bytecode is executed.

[0009] According to another aspect of the present invention, a secure access device is also provided, configured in a virtual machine, comprising:

[0010] An instruction type determination module is used to parse the target bytecode and determine the instruction type of the target bytecode; the target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module;

[0011] The legitimacy check module is used to obtain matching operands based on the instruction type, and to perform a security access legitimacy check matching the instruction type based on the operands.

[0012] The bytecode execution module is used to execute the target bytecode after the security access legality check passes.

[0013] According to another aspect of the present invention, an electronic device is also provided, wherein an operating system is installed on the electronic device, and a virtual machine is executed in the operating system, the electronic device comprising:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the secure access method as described in any of the embodiments of the present invention.

[0017] According to another aspect of the present invention, a terminal is also provided, including an electronic device as described in any one of the embodiments of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the secure access method as described in any one of the embodiments of the present invention.

[0019] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program that, when executed by a processor, implements the secure access method as described in any one of the embodiments of the present invention.

[0020] The technical solution of this invention involves a virtual machine parsing the target bytecode to determine its instruction type. Then, based on the instruction type, matching operands are obtained, and a security access validity check matching the instruction type is performed based on the operands. After the security access validity check passes, the implementation of the target bytecode is executed. The virtual machine can perform a security access validity check on each bytecode before execution, ensuring that access to every piece of data and call to every function are secure during virtual machine operation. This invention creatively proposes a new method for secure memory access in resource-constrained environments, effectively improving the operational reliability of the virtual machine.

[0021] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is an architecture diagram of a runtime data area applicable to an embodiment of the present invention;

[0024] Figure 2 This is a flowchart of a secure access method provided according to an embodiment of the present invention;

[0025] Figure 3 This is a flowchart of another secure access method provided by an embodiment of the present invention;

[0026] Figure 4 This is a flowchart of another secure access method provided by an embodiment of the present invention;

[0027] Figure 5 This is a flowchart of another secure access method provided by an embodiment of the present invention;

[0028] Figure 6 This is a structural diagram of a secure access device provided in an embodiment of the present invention;

[0029] Figure 7 This is a structural diagram of an electronic device provided according to an embodiment of the present invention;

[0030] Figure 8This is a structural diagram of a terminal provided according to an embodiment of the present invention. Detailed Implementation

[0031] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0032] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0033] To facilitate understanding, the relevant technologies involved in the various embodiments of the present invention will first be briefly described. Specifically, in Figure 1 The diagram shows an architecture diagram of a runtime data area applicable to an embodiment of the present invention.

[0034] like Figure 1 As shown, a download tool can load a binary loadable file into the operating system of an electronic device. A binary loadable file refers to a binary file generated by an application converter that can be loaded into the operating system. Once loaded into the operating system, the binary loadable file becomes a binary executable file. A binary executable file contains code that can be processed by an executor in a virtual machine; it includes executable modules.

[0035] An executable module, also known as an application module, can be understood as a container of application executable code contained within a binary executable file, and can be directly executed by the operating system. Applications can be created within application modules, while library modules cannot. Both application modules and library modules run as bytecode within a virtual machine.

[0036] Application data is the data required for an application to run, and it is contained in the application dataset and module dataset. An application refers to the application's code, i.e., the executable binary file, and is contained in the module assembly. Application modules can create applications (or application instances).

[0037] During the execution of bytecode, the virtual machine needs to exchange data with the runtime data area in the operating system.

[0038] The runtime data area includes at least the following: virtual machine stack, indirect access variable stack, global variable memory, heap, and program code area.

[0039] The indirect access variable stack is a local structure type data area of ​​the currently running function, used to store elements of the function's local arrays, structures, and unions.

[0040] Global variable memory is used by running modules to store global data. It is allocated when the virtual machine first calls the module assembly of the application module to which the application belongs on any logical channel; on any logical channel, all global variable memory space matching the current logical channel is reclaimed when the application is deselected.

[0041] The virtual machine uses a stack-based structure. The virtual machine stack is used to store stack frames (also called virtual machine stack frames), including storing parameters, local variables, intermediate execution results, return values, and method call information.

[0042] The heap is used to store application data, and heap space data will not be lost when power is off. The heap should have garbage collection capabilities.

[0043] The program code area stores application module code functions and related information.

[0044] In various embodiments of the present invention, secure access to data and code is controlled during the execution of bytecode in the virtual machine. During the execution of functions in this module (application module or library module), during the execution of calls to functions or methods in other modules, and during access to runtime data areas such as the virtual machine stack or indirect access to the variable stack, appropriate security strategies are applied to ensure that access to data and application data in each module is secure, and that calls to code in each module are also secure. That is, during bytecode execution, the virtual machine ensures the security of access by performing runtime security checks.

[0045] Figure 2This is a flowchart illustrating a secure access method provided in an embodiment of the present invention. This embodiment is applicable to situations where a virtual machine performs a secure access legality check on the bytecode to be executed. The method can be executed by a secure access device, which can be implemented in hardware and / or software, and is generally configured in an electronic device with an operating system installed, executed by a virtual machine installed within the operating system. Typically, this operating system can be an embedded operating system, such as an Application Smart Card (AOS) operating system.

[0046] Correspondingly, such as Figure 2 As shown, the method includes:

[0047] S210. Parse the target bytecode to determine the instruction type of the target bytecode; the target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module.

[0048] In this embodiment, a runtime environment (RTE) can be adapted within the operating system. The runtime environment is a secure runtime environment for executing virtual machines on restricted resources such as smart cards or secure elements; it can be considered a type of ultra-lightweight container. Applications run within this runtime environment, thus achieving complete isolation from the native functions of the operating system.

[0049] In a runtime system, multiple logical channels can be opened to execute multiple applications simultaneously. During execution, each application may call functions from other applications or functions from execution library modules. The execution of these applications or function calls follows a logical order of obtaining bytecode, parsing bytecode, and executing bytecode.

[0050] In the technical solution of this embodiment, after parsing the bytecode and before executing the bytecode, the virtual machine performs a security access legality check on the bytecode.

[0051] In this embodiment, the target bytecode can be the binary program code to be executed, typically WebAssembly bytecode. This target bytecode can be bytecode from the selected application within a specified logical channel, or it can be bytecode from other applications directly or indirectly called by the selected application, or it can be bytecode from a designated library module or its associated application module directly or indirectly called by the selected application.

[0052] A logical channel can be understood as a concept used to establish a communication connection between a host and a restricted device. It allows multiple independent communication channels to be established simultaneously between the host and the restricted device, each with its own command and response stream, and all channels are isolated from each other.

[0053] In a specific example, if the selected application within the specified logical channel is application A, and application A calls and executes application B during its execution, and application B, during its execution, further calls library module C, then this indicates that the selected application A indirectly calls library module C.

[0054] In an optional implementation of this embodiment, parsing the target bytecode may include:

[0055] Parse the target bytecode of the target application currently running in the target logic channel; wherein, the target application is obtained by installing the target application module, or;

[0056] Parse the target bytecode in the target library module currently being executed in the target logic channel.

[0057] Library modules are modules that do not contain entry functions and cannot create applications. Therefore, library modules cannot be selected for use within a specified logical channel. However, during execution, the selected application within the specified logical channel can choose to call the contents of the library module. Consequently, when the library module is called, its internal target bytecode can be executed.

[0058] Furthermore, the target application can be the selected application within the target logical channel, or it can be the application that the selected application selects and calls during its operation.

[0059] By parsing the target bytecode, the instruction type corresponding to that bytecode can be obtained. This instruction type can include memory data access instructions, such as memory data loading or reading instructions, instructions for pushing or popping operands in the virtual machine stack, function call instructions, and data access or variable manipulation instructions during function calls.

[0060] S220. Based on the instruction type, obtain the matching operand, and based on the operand, perform a security access legality check that matches the instruction type.

[0061] Generally, bytecode consists of an opcode and operands. The opcode indicates an operation of a certain type, and the operands represent the parameters required for this operation.

[0062] Optionally, the opcode in the target bytecode can first be obtained by regular expression matching, and the instruction type corresponding to the target bytecode can be determined based on the opcode. Then, matching operands can be extracted according to the operand extraction rules corresponding to the instruction type.

[0063] In this embodiment, depending on the actual situation, one can choose to obtain the matching operand directly from the target bytecode, or obtain the matching operand from the virtual machine stack frame that matches the target bytecode, or obtain the matching operand from both the target bytecode and the virtual machine stack frame that matches the target bytecode. This embodiment does not impose any restrictions on this.

[0064] Understandably, different instruction types can pose different security threats. For example, memory access instructions may cause access violations, leading to the leakage of sensitive information; push or pop instructions on operands in the virtual machine stack may cause stack overflow; and function call instructions may result in illegal or abnormal access.

[0065] Accordingly, after obtaining the operands, a security access validity check matching the instruction type needs to be performed based on one or more operands.

[0066] S230. After the security access legality check passes, execute the target bytecode.

[0067] If the security access legitimacy check passes, it can be determined that there will be no security risk after executing the target bytecode, and the target bytecode can be executed directly. If the security access legitimacy check fails, the execution of the target bytecode will be directly blocked and an error message, such as a security exception, will be thrown to ensure the security of data access to the greatest extent.

[0068] The technical solution of this invention involves a virtual machine parsing the target bytecode to determine its instruction type. Then, based on the instruction type, matching operands are obtained, and a security access validity check matching the instruction type is performed based on the operands. After the security access validity check passes, the implementation of the target bytecode is executed. The virtual machine can perform a security access validity check on each bytecode before execution, ensuring that access to every piece of data and call to every function are secure during virtual machine operation. This invention creatively proposes a new method for secure memory access in resource-constrained environments for virtual machine-based applications, effectively improving the operational reliability of the virtual machine.

[0069] Figure 3This is a flowchart of another secure access method provided by an embodiment of the present invention. This embodiment is a refinement based on the above embodiments. In this embodiment, the operation of "obtaining matching operands according to the instruction type and performing a secure access legality check matching the instruction type according to the operands" is specified as follows: when it is determined that the instruction type is a memory data access instruction, the attribute information corresponding to the target memory data to be accessed and the target module to which the target bytecode belongs are obtained; a memory access legality check is performed according to the attribute information and the target module to which the target bytecode belongs. The specific implementation of the above operation is described in detail.

[0070] Correspondingly, such as Figure 3 As shown, the method includes:

[0071] S310. Parse the target bytecode to determine the instruction type of the target bytecode.

[0072] The target bytecode includes: bytecode in the application module, bytecode in the application, or bytecode in the library module.

[0073] S320. When it is determined that the instruction type is a memory data access instruction, obtain the attribute information corresponding to the target memory data to be accessed and the target module to which the target bytecode belongs.

[0074] Accordingly, the target module may include a target application module or a target library module. Specifically, when the target bytecode is bytecode within an application, the target application module is the application module to which that application belongs.

[0075] Among them, memory data access instructions refer to instructions that need to perform operations such as loading, storing, copying or filling data in memory, such as i32.load, i32.load8_s, i32.load8_u, i32.load16_s, i32.load16_u, i32.store, i32.store8, i32.store16, memory.copy or memory.fill instructions.

[0076] Alternatively, when the virtual machine executes the target bytecode of function calls such as `call_u16`, `call_outer_u8`, `call_inner_u8`, or `call_indirect` via API calls, it determines that the instruction type is a memory data access instruction. In this case, the function parameters are pointers, arrays, or structures, and the actual parameter passed is a memory address (also known as a memory offset). During the function call, the parameters are parsed, and the validity of the memory access is checked.

[0077] The memory access legality check includes checking the legality of the virtual machine running domain where the memory data resides and checking the legality of the memory offset value.

[0078] Optionally, it is possible to predetermine which bytecode belongs to memory data access instructions and identify the key fields contained in the operators of the bytecode. Then, when the target bytecode is identified to contain the key fields, it is determined that the target bytecode belongs to memory data access instructions.

[0079] After determining that the instruction type is a memory data access instruction, the attribute information corresponding to the target memory data to be accessed and the target module to which the target bytecode belongs can be further identified.

[0080] The target memory data to be accessed may include: memory data to be loaded, data to be stored in memory, memory data to be copied, and data to be filled into memory.

[0081] The attribute information corresponding to the target memory data can be understood as a description of the target memory data's storage location in memory space; for example, it can be an absolute physical address or an address offset. By synchronously parsing the target bytecode, the attribute information corresponding to the target memory data can be obtained accordingly.

[0082] As mentioned earlier, the target bytecode can be the bytecode (executable module) within the module where the application resides. This module can install and create the application through the application module, thus the target bytecode belongs to the specified application module. Alternatively, the target bytecode can also be the bytecode within a specified library module, thus the target bytecode directly belongs to the specified library module.

[0083] Generally, target bytecode runs within a specified logical channel, and each logical channel corresponds to a virtual machine runtime domain adapted to it. Within this virtual machine runtime domain, the target module to which the currently running target bytecode belongs is recorded. This target module can be an application module or a library module. If the target module is an application module, the virtual machine runtime domain will also synchronously record the target application to which the currently running target bytecode belongs.

[0084] A virtual machine runtime domain refers to the virtual memory space constructed by the Real-Time Execution Environment (RTE) for the scope of application runtime access data (also known as accessible data). It records information such as application identifiers and logical channels. Corresponding to each logical channel, there is one and only one running application bound to the virtual machine runtime domain on that logical channel.

[0085] Optionally, you can first obtain the specified logical channel of the currently running target bytecode, and then obtain the virtual machine runtime domain corresponding to the selected application on the specified logical channel, and at the same time obtain the virtual machine runtime domain corresponding to the currently running target bytecode.

[0086] S330. Determine the data type of the target memory data based on the attribute information.

[0087] In this embodiment, the operating system can open multiple virtual channels to execute different applications. The operating system will allocate different memory spaces to different applications to store various application data generated in real time during the application's operation.

[0088] In a specific example, space can be allocated within a dedicated storage area for storing module datasets and application datasets, either sequentially (Module 1, Module 2, ..., Module n) or dynamically, to store data corresponding to each application module. When storing data for a particular application module, the stored data may include module assemblies, module datasets, application datasets for application 1, application datasets for application 2, ..., application datasets for application n.

[0089] Correspondingly, in the application dataset of a certain application, various types of application data are stored according to the set data sorting method or dynamically allocated space.

[0090] Correspondingly, when the attribute information is a memory offset, the memory offset can be resolved to a memory offset based on the storage location of the target module.

[0091] Accordingly, based on the attribute information, the data type of the target memory data can specifically include:

[0092] If the attribute information is a memory offset, then the starting memory address is determined according to the target module (the application module or library module to which the target bytecode belongs); and the data type of the target memory data is determined according to the memory offset, the starting memory address, and the preset memory space management method.

[0093] As mentioned earlier, data of various data types are arranged in memory according to a preset data arrangement. Typically, different modules are stored in different memory spaces, different applications within the same application module are stored in different memory spaces when selected on different logical channels, and application data of different data types within the same application are also stored in different memory spaces. Furthermore, based on this attribute information, the actual memory address of the target memory data can be located. Based on this actual memory address, the module (i.e., access module), application module, or library module to which the target memory data belongs can be determined. If the module to which it belongs is determined to be an application module, the application module to which the target memory data belongs can be further determined. Simultaneously, the data type of the target memory data can also be determined.

[0094] The data types may include: module datasets, application datasets, or module assembly data.

[0095] Module datasets contain global data, which refers to data defined within the application that is visible to the entire module but whose scope is limited to that specific module; it is also known as global variables. This type of data is typically used to share information within a module but is not visible or accessible in other modules. A module can be understood as a container of executable application code contained in a binary file, including the application's instructions, data, and metadata, which can be directly run by the operating system. Modules generally contain application modules and library modules.

[0096] The global data includes: module read-only data or module global data.

[0097] Module read-only data refers to global data that is visible to the entire module but can only be read and not modified. It is typically used to store constants, configuration information, or other values ​​that do not change during application runtime, such as application constants. Module global data refers to global data that is visible to the entire module and can be modified by applications within the module, such as application global data or the application global variable heap.

[0098] The data in the application dataset can be understood as data information within a specific application, that is, the application data of the application.

[0099] The application dataset includes at least one of the following: persistent data, temporary dynamic variable data, temporary static variable data, and cross-domain data.

[0100] Temporary static variable data and temporary dynamic variable data are both temporary data. Temporary data is a type of data used during the operation of an application. It is cleared or reset when a specific event occurs to ensure security and protect sensitive data.

[0101] Temporary static variable data refers to resource data whose state is reset to 0 whenever the embedded operating system is reset. This resource state is not shared between applications and is typically used to store data related to a specific session or transaction, ensuring security and data isolation. Temporary dynamic variable data refers to resource data whose state is retained during interaction with the application until the application is deselected, at which point the resource state is cleared and reset to 0. This resource is typically used to share temporary data between applications, such as temporary counters or caches.

[0102] Persistent data refers to non-volatile storage data created during application module installation or operation by calling the storage space allocation interface provided by the operating system runtime environment. Its initial value is 0. Persistent data belongs to the application itself. This persistent data can be written to and read from through the interfaces or pointer variables provided by the operating system runtime environment. Virtual machine instructions can directly access this persistent data through pointer variables.

[0103] Cross-domain data is a special type of temporary static variable data that is not restricted by the virtual machine runtime domain access control policy. That is, all applications within the application module can access this data across virtual machine runtime domains.

[0104] A module assembly is a collection of all program code information or module program data stored within a specific module.

[0105] In this embodiment, it is pre-defined that boundary checks are performed on the allocated memory range when accessing the module dataset.

[0106] Accordingly, based on the above embodiments, determining the data type corresponding to the target memory data according to the attribute information may further include:

[0107] If it is determined that the attribute information exceeds the pre-defined space range of the module's global data memory and the indirect access variable stack, then the memory access legality check is directly determined to fail.

[0108] In this embodiment, when accessing the operating system's memory data, the primary focus is on accessing the data stored in the module's global data memory and the indirect access variable stack. Both the module's global data memory and the indirect access variable stack have pre-defined storage space ranges. Therefore, if a memory address matching the attribute information exceeds the pre-defined space range of the module's global data memory and the indirect access variable stack, it indicates that the memory access has exceeded the limit. Consequently, the memory access validity check can be directly determined to have failed, and an error message, such as a security exception, can be thrown to directly deny access to the target memory data.

[0109] S340. Based on the data type, the access module to which the target memory data belongs, and the target module, perform a memory access legality check.

[0110] In this embodiment, when the RTE runs to different module assemblies, it should switch to the runtime domain to which the module dataset belongs. Specifically, library modules should be able to access the module datasets of application modules within the current runtime domain. Library modules should also be able to access their own module datasets.

[0111] Furthermore, when the target bytecode belongs to the target library module, it can access the module dataset in the application module or the time library module.

[0112] Accordingly, in an optional implementation of this embodiment, performing a memory access legality check based on the module to which the target memory data belongs, the data type of the target memory data, and the target module may include at least one of the following:

[0113] If the target module is a target library module and the target memory data belongs to the module dataset in the library module, then the memory access legality check is passed.

[0114] If the target module is a target library module and the target memory data belongs to the module dataset in the application module, then the memory access legality check is passed.

[0115] In this embodiment, a secure access policy is further specified between applications created by the same application module. That is, the module dataset and module program assembly should be shared between different applications of the same module.

[0116] Correspondingly, in another optional implementation of this embodiment,

[0117] If the target module is a target application module and the target memory data belongs to a module assembly, then the memory access legality check is passed when the target application module and the application module to which the target memory data belong are the same.

[0118] In this embodiment, it is further specified that application modules should not be able to access the module datasets of other application modules across runtime domains.

[0119] Accordingly, if the target module is a target application module and the target memory data belongs to a module dataset, then the memory access legality check is passed when the target application module and the application module to which the target memory data belong are the same.

[0120] In an optional implementation of this embodiment, if the target module is a target application module and the target memory data belongs to the application dataset in the application module, then a memory access legality check is performed based on the virtual machine runtime domain where the target bytecode and the target memory access data are located.

[0121] Specifically, the memory access legality check, based on the virtual machine runtime domain where the target bytecode and target memory access data reside, can include:

[0122] If the target memory access data belongs to persistent variable data, temporary static variable data, or cross-domain data in the application dataset, then obtain the current virtual machine runtime domain within the target logical channel for executing the target bytecode;

[0123] Detect whether the virtual machine runtime domain of the module dataset and program dataset to which the target memory data belongs is consistent with the current virtual machine runtime domain within the target logical channel;

[0124] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0125] In this embodiment, if the target bytecode needs to access persistent data, temporary static variable data, or cross-domain data in the application data, access to the target memory data is only allowed based on the current virtual machine runtime domain if the virtual machine runtime domain of the module dataset and program dataset to which the target memory data belongs is consistent with the current virtual machine runtime domain within the target logical channel.

[0126] In other words, the application module to which the target memory data belongs may be the module of the selected application within the logical channel, or it may be another library module or an application module of another application called by the selected application during execution. As long as the current virtual machine runtime domain of the logical channel is consistent with the virtual machine corresponding to the application module to which the target memory data belongs, the target memory data can be accessed securely.

[0127] In another optional implementation of this embodiment, if the target memory access data belongs to temporary dynamic variable data in the application dataset, then it is detected whether the virtual machine runtime domain where the module dataset and program dataset to which the target memory data belongs, the current virtual machine runtime domain in the target logical channel executing the target bytecode, and the virtual machine runtime domain of the selected application in the target logical channel are all the same.

[0128] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0129] In this embodiment, it is pre-defined that different applications cannot access each other's temporary dynamic variable data. Therefore, in a specific case, if application A is selected in the logical channel, and application B is called during the execution of application A, then access to the temporary dynamic variable data belonging to application A during application B's execution is prohibited. By comparing the virtual machine runtime domain, this data access situation can be avoided.

[0130] S350. After the security access legitimacy check passes, execute the target bytecode.

[0131] The technical solution of this invention, when accessing target memory data using memory data access instructions, can effectively verify the legality of accessing the target memory data by obtaining the data type of the target memory data, the module dataset to which the target memory data belongs, and the virtual machine runtime domain where the module program assembly is located. This ensures that access to each module data and application data is secure, thereby improving the security and stability of the operating system.

[0132] In an optional implementation of this embodiment, if the data type is module read-only data in global data, then it is detected whether the virtual machine runtime domain of the module dataset and program dataset to which the target memory data belongs is the same as the virtual machine runtime domain corresponding to the target module to which the target bytecode belongs.

[0133] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0134] In other words, in a specific example, if the data type is read-only data in the global data module, then it checks whether the access module to which the target memory data belongs is the same as the target module; if so, the memory access legality check is passed; otherwise, the memory access legality check is failed.

[0135] For read-only data within a module, different applications within the same module can access it, while applications outside the same module cannot. Therefore, we can first determine the application module to which the target memory data belongs, i.e., the accessing module. If the accessing module matches the target module, the memory access validity check is considered successful.

[0136] In another optional implementation of this embodiment, if the data type is module global data in global data, then it is detected whether the virtual machine runtime domain where the module dataset and program dataset to which the target memory data belongs is the same as the virtual machine runtime domain where the application to which the target bytecode belongs is located.

[0137] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0138] In other words, in a specific example, if the data type is module global data in global data, then it is checked whether the application to which the target memory data belongs is the same as the application to which the target bytecode belongs; if so, the memory access legality check is determined to pass; otherwise, the memory access legality check is determined to fail.

[0139] In various embodiments of the present invention, module global data is independently allocated on different logical channels. Since different applications of the same application module can only run sequentially on the same logical channel, in this case, the application module allocates module global data when it runs and reclaims the allocated module global data when it cancels the running process. Different applications cannot access this data from each other.

[0140] Furthermore, if the target memory data belongs to the module's global data, the module dataset and program dataset in the access module to which the target memory data belongs can be obtained accordingly. If the module dataset and program dataset in the access module are consistent with the module dataset and program dataset in the target module, the application module to which the target memory data belongs will continue to be detected. Only if the virtual machine runtime domain corresponding to the application module to which the data belongs is the same as the virtual machine runtime domain to which the target bytecode belongs will the target bytecode be executed to access the target memory data.

[0141] Figure 4 This is a flowchart of another secure access method provided by an embodiment of the present invention. This embodiment is a refinement based on the above embodiments. In this embodiment, the operation of "obtaining a matching operand according to the instruction type and performing a secure access legality check matching the instruction type according to the operand" is specified as follows: "When it is determined that the instruction type is an instruction to push or pop an operand from the virtual machine stack, the operation type of the operand is obtained, and a virtual machine stack boundary legality check is performed according to the operation type of the operand." The specific implementation of the above operation is described in detail.

[0142] Correspondingly, such as Figure 4 As shown, the method includes:

[0143] S410. Parse the target bytecode to determine the instruction type of the target bytecode.

[0144] The target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module.

[0145] S420. When it is determined that the instruction type is an instruction to push or pop operands on the virtual machine stack, the operation type of the operand is obtained.

[0146] In this embodiment, when the virtual machine parses and executes the target bytecode, if it needs to operate on operands in the virtual machine stack, it needs to perform a virtual machine stack boundary validity check, including: when pushing operands into the virtual machine stack, checking whether the virtual machine stack overflows; and when popping operands from the virtual machine stack, checking whether the virtual machine stack underflows.

[0147] Specifically, during the manipulation of the virtual machine stack, the boundary information of the current virtual machine stack space and the virtual machine stack space of the current function is recorded. Among them, the boundary information can be the stack start space as the lower boundary of the virtual machine stack of the current function, and the stack size, etc.

[0148] When the target bytecode is executed, it typically reads (or pops) one or more operands from the virtual machine stack. Before executing the operation, it checks whether the virtual machine stack overflows downwards after subtracting the stack space occupied by one or more operands from the current virtual machine stack. Alternatively, it writes (or pushes) one or more operands into the virtual machine stack. Before executing the operation, it checks whether the virtual machine stack overflows upwards after adding the stack space occupied by one or more operands to the current virtual machine stack.

[0149] Specifically, if the operand operation type is a pop operation of a set number of operands, S430 is executed; if the operand operation type is a push operation of a set number of operands, S440 is executed.

[0150] S430. Before performing the pop operation, check whether the virtual machine stack overflows downwards after subtracting the stack space occupied by the set number of operands from the current occupied stack space of the virtual machine stack: if yes, execute S450; otherwise, execute S460.

[0151] S440. Before performing the push operation, check whether the virtual machine stack overflows after the stack space occupied by the set number of operands is increased from the current occupied stack space of the virtual machine stack.

[0152] S450. It is determined that the virtual machine stack has failed the virtual machine stack boundary validity check.

[0153] S460. Determine that the virtual machine stack has passed the virtual machine stack boundary validity check, and then execute S470.

[0154] Specifically, in the virtual machine stack, the space of the current function's stack frame should ensure that after writing (or pushing) one or more operands into (or onto) the current stack space, the stack frame space does not exceed the function's maximum stack frame size. The maximum stack frame size is the function's initial stack frame plus the number of units in the maximum stack frame. For example, in one implementation, each operand occupies one unit, and one unit is 4 bytes.

[0155] For example, when target bytecode such as i32.and, i32.or, i32.xor, and i32.shl is executed, it needs to retrieve two operands from the current virtual machine stack. Therefore, it first checks whether the virtual machine stack, after subtracting the stack space occupied by the two operands, overflows downwards—that is, whether it is less than the starting boundary of the current function's virtual machine stack space. If it is less, the access is illegal, and an error message (e.g., a security exception) should be thrown; if it is not less, the two operands are popped from the virtual machine stack, and then the corresponding calculation is performed.

[0156] Similarly, when the result of an operand needs to be stored in the current virtual machine stack after a calculation is completed, it is necessary to first check whether the virtual machine stack, after adding the stack unit space occupied by the operand, overflows upwards, that is, whether it exceeds the maximum stack frame boundary of the current function's virtual machine stack space. If it exceeds, the access is illegal, and an error message (such as a security exception) should be thrown; if it is less than, the calculation result is pushed onto the virtual machine stack.

[0157] S470, Execute the target bytecode.

[0158] The technical solution of this invention, when determining that the instruction type is an instruction to push or pop operands on the virtual machine stack, obtains the operation type of the operand, and performs a virtual machine stack boundary legality check based on the operation type of the operand. This can ensure that access operations to the virtual machine stack are safe and legal, thereby effectively improving the operational reliability of the virtual machine.

[0159] Figure 5 This is a flowchart of another secure access method provided by an embodiment of the present invention. This embodiment is a refinement based on the above embodiments. In this embodiment, the operation of "obtaining a matching operand according to the instruction type and performing a secure access legality check matching the instruction type according to the operand" is specified as follows: "When it is determined that the instruction type is a function call instruction to a target function, the function index of the target function and the number of parameters passed to the target bytecode are obtained; a function call legality check is performed according to the function index of the target function and the number of parameters passed to the target bytecode." The specific implementation of the above operation is described in detail.

[0160] Correspondingly, such as Figure 5As shown, the method includes:

[0161] S510. Parse the target bytecode and determine the instruction type of the target bytecode.

[0162] The target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module.

[0163] S520. When it is determined that the instruction type is a function call instruction to the target function, the function index of the target function and the number of parameters passed in the target bytecode are obtained.

[0164] In a specific example, if target bytecode of the form call_u16, call_outer_u8, call_inner_u8, and call_indirect is executed, the target function contained in that target bytecode needs to be called.

[0165] The target function may be an internal function of the application module or library module to which the target bytecode belongs, or it may be an external function of the application module or library module to which the target bytecode belongs. Specifically, the target function may belong to an application module or a library module.

[0166] By parsing the target bytecode, the module identifier of the module to which the target function belongs can be obtained. If the target function belongs to an application module, the application identifier of the application to which the target function belongs can also be obtained.

[0167] In various embodiments of the present invention, bytecode in a predefined application can access internal functions in its application module or functions in a library module; or, bytecode in an application can also access functions in other applications that have been pre-authorized to it, i.e., external functions.

[0168] In this embodiment of the invention, if it is determined that the target bytecode can access an external target function, and the module to which the external function belongs is an application module, then it is necessary to obtain the target logical channel for executing the target bytecode, and switch the current virtual machine runtime domain of the target logical channel to the virtual machine runtime domain where the target function is located.

[0169] In other words, an application module can call interfaces authorized by other application modules, but a switch of the virtual machine runtime domain is required. Interface call permissions can be divided into the following three cases:

[0170] The interfaces in a library module should be callable by all other library modules or application modules;

[0171] By default, interfaces in an application module should not be called by other application modules.

[0172] When compiling and generating application modules, one or more interface functions can be specified for export. Exported interfaces should be allowed to be called by other applications; interfaces that are not exported should not be allowed to be called by other applications.

[0173] Accordingly, in an optional implementation of this embodiment, before obtaining the function index of the target function and the number of parameters passed to the target bytecode, the following may be included:

[0174] When the target module to which the target bytecode belongs is the target application module, and the module to which the target function belongs is the application module, it is detected whether the module to which the target function belongs is consistent with the target module to which the target bytecode belongs;

[0175] If not, after determining that the application to which the target function belongs authorizes the target application to call the target function, the current virtual machine runtime domain of the target logical channel is switched to the virtual machine runtime domain corresponding to the application to which the target function belongs.

[0176] In an optional implementation, if the application to which the target function belongs and the target application to which the target bytecode belongs belong to the same application module, then the target function is determined to be an internal function that the target bytecode can access, and thus, there is no need to switch the virtual machine runtime domain.

[0177] In other words, if the target function is determined to be an external function of the target module to which the target bytecode belongs, and the external function belongs to another application module, then if the external function does not have the necessary permissions for the target application, the target bytecode will be directly denied access to the target function.

[0178] Specifically, it can be determined whether the application to which the target function belongs has authorized the target application to call the target function by checking whether the application to which the target function belongs has authorized the target application's access request. The access request is made by calling the authorization service interface API. Each application on a logical channel has an independent authorization status information record, which may include, for example, the identifier of the authorized application and the module information of the authorized application.

[0179] In another optional implementation of this embodiment, before obtaining the function index of the target function and the number of parameters passed to the target bytecode, the following may be included:

[0180] When the target module to which the target bytecode belongs is the target application module, and the module to which the target function belongs is the library module, the module dataset and module assembly in the current virtual machine runtime domain of the target logical channel are directly switched to the module dataset and module assembly in the virtual machine runtime domain corresponding to the library module to which the target function belongs.

[0181] In another optional implementation of this embodiment, before obtaining the function index of the target function and the number of parameters passed to the target bytecode, the following may be included:

[0182] When the target module to which the target bytecode belongs is the target library module, and the module to which the target function belongs is the application module, the current virtual machine runtime domain of the target logical channel is directly switched to the virtual machine runtime domain corresponding to the application to which the target function belongs;

[0183] When the target module to which the target bytecode belongs is a target library module, and the module to which the target function belongs is a library module, the virtual machine runtime domain is not switched. Instead, the module dataset and module program set in the current virtual machine runtime domain of the target logical channel are directly switched to the module dataset and module program set in the virtual machine runtime domain corresponding to the library module to which the target function belongs.

[0184] S530. Obtain the function index corresponding to the target function.

[0185] In this context, a function index can be understood as an index assigned within a module (application module or library module) to imported functions (i.e., external functions) and internal functions. Functions are called using these function indexes. By parsing the target bytecode, the corresponding function index for the target function can be obtained.

[0186] S540: When the target function is an external function of the target application to which the target bytecode belongs, check the validity of the function index based on the import section of the target module to which the target bytecode belongs and the export section of the calling module to which the target function belongs. If the function index is determined to be valid, proceed to S550; otherwise, proceed to S570.

[0187] Specifically, the import section of an application module records information about the imported functions within that module, while the export section records the function indices of the exported functions. Functions called by one module from other modules are called imported functions of that module, while functions exported by one module for use by other modules are called exported functions of that module.

[0188] Furthermore, when the target function is determined to be an external function of the module to which the target application belongs, based on the module identifier to which the target function belongs, the specification will record the base of the target function and its index information in a specific form in both the export segment of the module to which the target function belongs (i.e., the calling module) and the import segment of the target module to which the target bytecode belongs. Based on the above two items, the validity of the function index of the target function can be checked.

[0189] Accordingly, in this embodiment, checking the validity of the function index based on the import segment of the target module to which the target bytecode belongs and the export segment of the calling module to which the target function belongs may include:

[0190] The function index is determined to be valid when it is determined that the number of functions imported by the import section in the target module does not exceed the number of functions imported by the import section in the calling module, and the function index appears in the import section in the calling module.

[0191] S550. Continue to check whether the number of parameters passed in the target bytecode is consistent with the number of function parameters defined in the code segment of the calling module: if so, execute S560 and S570.

[0192] The module's code segment stores local variable information and bytecode of functions within the module. The target function is located inside the calling module. By checking whether the number of parameters passed from the target bytecode to the target function matches the number of function parameters defined for that target function in the calling module's code segment, the validity of the function call can be further improved.

[0193] In a specific example, when checking the validity of a function index, if the function is called from the current module (the module containing the target bytecode), and the function index is greater than the total number of functions in the current module (including the number of user-defined functions and functions imported by the import section), the function index is determined to be invalid, and an error message (e.g., a security exception) is thrown. If the function is called from another module, and the function index is greater than the number of functions imported by the current module, the function index is determined to be invalid, and an error message (e.g., a security exception) is thrown. If the function is called from another module, and the function index does not appear in the export section where the function is defined in that other module, the function index is determined to be invalid, and an error message (e.g., a security exception) is thrown. If the function index is valid, the function parameter types and the number of parameters passed in the current module's import section are further checked to see if they match the function located by the parser. If they do not match, an error message (e.g., a security exception) is thrown. Otherwise, the called function can be entered, and execution can continue.

[0194] S560. Confirm that the function call validity check has been passed, and proceed to S580.

[0195] S570. Determine if the function call validity check fails.

[0196] S580, Execute the target bytecode.

[0197] In an optional implementation of this embodiment, after the function call validity check passes and the target bytecode is executed, the following may also be included:

[0198] In the target logic channel, the bytecode corresponding to the target function is executed.

[0199] After the bytecode corresponding to the target function has been executed, if possible, the current virtual machine runtime domain of the target logical channel can be restored to the virtual machine runtime domain corresponding to the target bytecode.

[0200] In this optional implementation, after the target function call in other application modules is completed, it is necessary to switch the current virtual machine runtime domain of the target logical channel back to the virtual machine runtime domain where the target bytecode is located, so as to ensure data isolation between different applications and ensure data security.

[0201] Alternatively, after the target function call in the library module is completed, it is necessary to switch the module dataset and module program in the current virtual machine runtime domain of the target logical channel back to the module dataset and module program set that match the target bytecode.

[0202] Based on the above embodiments, after the execution of the bytecode corresponding to the target function begins in the target logic channel, it may further include:

[0203] During the execution of the bytecode corresponding to the target function, if it is necessary to access data at a set storage location, it is checked whether the set storage location is within the indirect access variable stack space range that matches the target function.

[0204] If so, the objective function is allowed to access the data at the designated storage location; otherwise, the objective function is prohibited from accessing the data at the designated storage location.

[0205] In a specific example, when the target bytecode calls a target function of another application module via a function call instruction, that target function, during runtime, is limited to accessing its own allocated indirect access variable stack space. That is, during virtual machine runtime domain switching, the maximum address space of the indirect access variable stack accessible to the called function is recorded. When the memory offset is resolved to the indirect access variable stack space, it should be checked whether it exceeds the maximum allowed address space. If it does, an error message (e.g., a security exception) should be thrown; otherwise, the access is allowed. The memory space for local structure type data is the indirect access variable stack.

[0206] The technical solution of this invention, when determining that the instruction type is a function call instruction to a target function, obtains the function index of the target function and the number of parameters passed to the target bytecode; based on the function index of the target function and the number of parameters passed to the target bytecode, it performs a function call legality check. This ensures that when the virtual machine calls functions in this module or functions or methods in other modules, the entire call execution process is safe and legal, thereby effectively improving the operational reliability of the virtual machine.

[0207] Based on the above embodiments, obtaining matching operands according to the instruction type and performing a security access legitimacy check matching the instruction type according to the operands may include:

[0208] When it is determined that the instruction type is a variable manipulation instruction in the execution process of a function call, the local variable index in the variable manipulation instruction is obtained;

[0209] The validity of the local variable index is checked by querying the current function stack frame in the virtual machine stack.

[0210] In one example, when the variable manipulation instructions such as local.get, local.set, local.tee, global.stack_pop, global.set_local, global.tee_local, local.get0, local.get1, local.get2, local.get3, local.get4, local.get5, local.set0, local.set1, local.set2, local.set3, local.set4, local.set5, local.tee0, and local.tee1 are executed, a local variable index validity check needs to be performed.

[0211] The number of parameters (paraNum) and the number of local variables (localNum) serve as the basis for validating the local variable indices in the current virtual machine function stack frame. The local variable indices should be less than the total size of the number of parameters (paraNum) and the number of local variables (localNum); otherwise, an error message (e.g., a security exception) should be thrown.

[0212] Based on the above embodiments, obtaining operands that match the instruction type and performing a security access legitimacy check matching the instruction type based on the operands may include:

[0213] When the instruction type is determined to be a conditional jump instruction in the control instructions, the jump offset in the conditional jump instruction is obtained;

[0214] In the target module to which the target bytecode belongs, obtain the function range information corresponding to the function to which the target bytecode belongs;

[0215] Based on the target bytecode address and the function range information, a jump offset validity check is performed on the jump offset.

[0216] In a specific example, when br_u16, br_if_u16, br_tb_u16, return_void, call_u16, call_indirect, br_fw_u8, br_bw_u8, br_table_u8, br_if_fw_u8, br_if_bw_u8, return_i32, and conditional jump instructions such as try and catch are executed, a jump offset validity check needs to be performed.

[0217] When the virtual machine executes the target bytecode, it records the current bytecode address (e.g., the bcPC variable). The module information records the scope of each function, such as function size, function start address, and function end address. The address obtained by incrementing or decrementing the offset from the current bytecode address should also be within the current function's scope; otherwise, an error message (e.g., a security exception) should be thrown.

[0218] This invention provides a runtime data access method. During virtual machine runtime, it controls secure access to application data and code. During application code execution, when executing bytecode related to the execution of functions in this module, calling functions in other modules, or accessing memory or local variables such as memory or the stack, a security policy is applied to ensure that access to data in each module and application is secure, and that calls to code in each module are also secure, thus ensuring the security of the entire data access process.

[0219] Figure 6 This is a schematic diagram of a secure access device provided in an embodiment of the present invention. The device is configured in a virtual machine, such as... Figure 6 As shown, the device includes:

[0220] Instruction type determination module 610 is used to parse the target bytecode and determine the instruction type of the target bytecode; the target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module;

[0221] The legality check module 620 is used to obtain a matching operand based on the instruction type, and to perform a security access legality check matching the instruction type based on the operand.

[0222] The bytecode execution module 630 is used to execute the target bytecode after the security access legality check passes.

[0223] The technical solution of this invention involves a virtual machine parsing the target bytecode to determine its instruction type. Then, based on the instruction type, matching operands are obtained, and a security access validity check matching the instruction type is performed based on the operands. After the security access validity check passes, the implementation of the target bytecode is executed. The virtual machine can perform a security access validity check on each bytecode before execution, ensuring that every data access and every function call is secure during virtual machine operation. This innovatively proposes a new method for secure memory access in resource-constrained environments for virtual machine-based applications, effectively improving the operational reliability of the virtual machine.

[0224] Based on the above embodiments, the instruction type determination module 610 can be specifically used for:

[0225] Parse the target bytecode of the target application currently running in the target logic channel; wherein, the target application is obtained by installing the target application module, or;

[0226] Parse the target bytecode in the target library module currently being executed in the target logic channel.

[0227] Based on the above embodiments, the legality check module 620 specifically includes:

[0228] The attribute information acquisition unit is used to acquire, when determining that the instruction type is a memory data access instruction, the attribute information corresponding to the target memory data to be accessed and the target module to which the target bytecode belongs; wherein, the target module includes: a target application module or a target library module;

[0229] The memory access validity check unit is used to perform memory access validity checks based on attribute information and the target module to which the target bytecode belongs.

[0230] Based on the above embodiments, the memory validity check unit may specifically include:

[0231] The data type determination subunit is used to determine the data type of the target memory data based on the attribute information.

[0232] The legality check subunit is used to perform a memory access legality check based on the data type, the access module to which the target memory data belongs, and the target module.

[0233] Based on the above embodiments, the data type determination subunit can be specifically used for:

[0234] If the attribute information is a memory offset, then the starting memory address is determined according to the target module;

[0235] The data type of the target memory data is determined based on the memory offset, the starting memory address, and the preset memory space management method.

[0236] In terms of the technology of the above embodiments, the legality checking subunit is specifically used to perform at least one of the following:

[0237] If the target module is a target library module and the target memory data belongs to the module dataset in the library module, then the memory access legality check is passed.

[0238] If the target module is a target library module and the target memory data belongs to the module dataset in the application module, then the memory access legality check is passed.

[0239] In terms of the technology of the above embodiments, the legality checking subunit is specifically used for:

[0240] If the target module is a target application module and the target memory data belongs to the application dataset in the application module, then a memory access legality check is performed based on the virtual machine runtime domain where the target bytecode and the target memory access data are located.

[0241] In terms of the technology of the above embodiments, the legality checking subunit is further used for:

[0242] If the target memory access data belongs to persistent variable data, temporary static variable data, or cross-domain data in the application dataset, then obtain the current virtual machine runtime domain within the target logical channel for executing the target bytecode;

[0243] Detect whether the virtual machine runtime domain of the module dataset and program dataset to which the target memory data belongs is consistent with the current virtual machine runtime domain within the target logical channel;

[0244] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0245] In terms of the technology of the above embodiments, the legality checking subunit is further used for:

[0246] If the target memory access data belongs to temporary dynamic variable data in the application dataset, then check whether the virtual machine runtime domain of the module dataset and program dataset to which the target memory data belongs, the current virtual machine runtime domain in the target logical channel executing the target bytecode, and the virtual machine runtime domain of the selected application in the target logical channel are all the same.

[0247] If yes, the memory access legality check is considered passed; otherwise, the memory access legality check is considered failed.

[0248] Based on the above embodiments, the data type determination subunit can be further used for:

[0249] If it is determined that the attribute information exceeds the pre-defined space range of the module's global data memory and the indirect access variable stack, then the memory access legality check is directly determined to fail.

[0250] Based on the above embodiments, the legality check module 620 is specifically used for:

[0251] When it is determined that the instruction type is an instruction to push or pop operands on the virtual machine stack, the operation type of the operand is obtained, and a virtual machine stack boundary validity check is performed based on the operation type of the operand.

[0252] Based on the above embodiments, the legality check module 620 is further used for:

[0253] If the operation type of the operand is a pop operation of a set number of operands, then before performing the pop operation, check whether the virtual machine stack overflows downward after subtracting the stack space occupied by the set number of operands from the current occupied stack space of the virtual machine stack.

[0254] If not, then the virtual machine stack is confirmed to have passed the virtual machine stack boundary validity check.

[0255] Based on the above embodiments, the legality check module 620 is further used for:

[0256] If the operand operation type is a push operation of a set number of operands, then before performing the push operation, check whether the virtual machine stack overflows after the stack space occupied by the set number of operands is added to the currently occupied stack space of the virtual machine stack.

[0257] If not, then the virtual machine stack is confirmed to have passed the virtual machine stack boundary validity check.

[0258] Based on the above embodiments, the legality check module 620 is specifically used for:

[0259] The index and parameter count acquisition unit is used to acquire the function index of the target function and the number of parameters passed in the target bytecode when it is determined that the instruction type is a function call instruction to the target function;

[0260] The function call validity checking unit is used to perform function call validity checks based on the function index of the target function and the number of parameters passed in the target bytecode.

[0261] Based on the above embodiments, it may further include: a first operating domain switching module, used for:

[0262] Before obtaining the function index of the target function and the number of parameters passed to the target bytecode, when the target module to which the target bytecode belongs is the target application module and the module to which the target function belongs is the application module, it is checked whether the module to which the target function belongs is consistent with the target module to which the target bytecode belongs.

[0263] If not, after determining that the application to which the target function belongs authorizes the target application to call the target function, the current virtual machine runtime domain of the target logical channel is switched to the virtual machine runtime domain corresponding to the application to which the target function belongs.

[0264] Based on the above embodiments, it may further include: a second operating domain switching module, used for:

[0265] When the target module to which the target bytecode belongs is the target application module, and the module to which the target function belongs is the library module, the module dataset and module assembly in the current virtual machine runtime domain of the target logical channel are directly switched to the module dataset and module assembly in the virtual machine runtime domain corresponding to the library module to which the target function belongs.

[0266] Based on the above embodiments, it may further include: a third operating domain switching module, used for:

[0267] Before obtaining the function index of the target function and the number of parameters passed to the target bytecode, if the target module to which the target bytecode belongs is the target library module and the module to which the target function belongs is the application module, the current virtual machine runtime domain of the target logical channel is directly switched to the virtual machine runtime domain corresponding to the application to which the target function belongs;

[0268] When the target module to which the target bytecode belongs is a target library module, and the module to which the target function belongs is a library module, the virtual machine runtime domain is not switched.

[0269] Based on the above embodiments, the function call validity checking unit can be specifically used for:

[0270] Obtain the function index corresponding to the target function;

[0271] When the target function is an external function of the target application to which the target bytecode belongs, the validity of the function index is checked based on the import section of the target module to which the target bytecode belongs and the export section of the calling module to which the target function belongs.

[0272] If the function index is determined to be valid, then continue to check whether the number of parameters passed to the target bytecode is consistent with the number of function parameters defined in the code segment of the calling module;

[0273] If so, then the validity check of the function call is passed.

[0274] Based on the above embodiments, the function call validity checking unit can be further used for:

[0275] The function index is determined to be valid when it is determined that the number of functions imported by the import section in the target module does not exceed the number of functions imported by the import section in the calling module, and the function index appears in the import section in the calling module.

[0276] Based on the above embodiments, it may further include: a fourth operating domain switching module, used for:

[0277] After the function call validity check passes and the target bytecode is executed, the bytecode corresponding to the target function begins to be executed in the target logic channel;

[0278] After the bytecode corresponding to the target function is executed, the current virtual machine runtime domain of the target logical channel is restored to the virtual machine runtime domain corresponding to the target bytecode.

[0279] Based on the above embodiments, it may further include: a variable stack space checking unit, used for:

[0280] In the target logic channel, after the execution of the bytecode corresponding to the target function begins, if it is necessary to access data at a set storage location during the execution of the bytecode corresponding to the target function, it is checked whether the set storage location is within the indirect access variable stack space range that matches the target function.

[0281] If so, the objective function is allowed to access the data at the designated storage location; otherwise, the objective function is prohibited from accessing the data at the designated storage location.

[0282] Based on the above embodiments, the legality check module 620 specifically includes:

[0283] When it is determined that the instruction type is a variable manipulation instruction in the execution process of a function call, the local variable index in the variable manipulation instruction is obtained;

[0284] The validity of the local variable index is checked by querying the current function stack frame in the virtual machine stack.

[0285] Based on the above embodiments, the legality check module 620 specifically includes:

[0286] When the instruction type is determined to be a conditional jump instruction in the control instructions, the jump offset in the conditional jump instruction is obtained;

[0287] In the target module to which the target bytecode belongs, obtain the function range information corresponding to the function to which the target bytecode belongs;

[0288] Based on the target bytecode address and the function range information, a jump offset validity check is performed on the jump offset.

[0289] The secure access device provided in the embodiments of the present invention can execute the secure access method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0290] The collection, storage, use, processing, transmission, provision, and disclosure of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0291] Figure 7 A schematic diagram of the structure of an electronic device 10 that can be used to implement an embodiment of the present invention is shown.

[0292] like Figure 7 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0293] This electronic device can be a resource-constrained device. A resource-constrained device can be understood as an electronic device with limited storage capacity, typically a few KB to tens of KB of RAM resources, and limited NVM (non-volatile memory) resources. Figure 7 (Taking ROM as an example) The size ranges from tens of KB to hundreds of KB, with a maximum size of MB.

[0294] The resource-constrained device can typically be: a smart card, USB key, ESAM (Embedded Secure Access Module), IoT device, or SE (Secure Element). Among these, the smart card is usually a multi-application smart card.

[0295] The I / O interface 15 in the electronic device 10 may include eSPI (Enhanced Serial Peripheral Interface) and SPI (Serial Peripheral Interface), etc.

[0296] Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, for example, performing a secure access method as described in various embodiments of the present invention, executed by a virtual machine, wherein an operating system is installed on the electronic device, and the virtual machine is executed in the operating system, the method comprising:

[0297] Parse the target bytecode to determine the instruction type of the target bytecode; the target bytecode includes: bytecode in the application module, bytecode in the application program, or bytecode in the library module;

[0298] Based on the instruction type, obtain the matching operand, and based on the operand, perform a security access legality check that matches the instruction type;

[0299] After the security access legitimacy check passes, the target bytecode is executed.

[0300] In some embodiments, a secure access method as described in the various embodiments of the present invention may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 16. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the secure access method described above as described in the various embodiments of the present invention may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a secure access method as described in the various embodiments of the present invention by any other suitable means (e.g., by means of firmware).

[0301] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0302] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0303] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0304] Figure 8 This is a structural diagram of a terminal provided according to an embodiment of the present invention. Figure 8 The terminal includes the electronic device 810 as described in any embodiment of the present invention.

[0305] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

Claims

1. A method of secure access, characterized by, Being executed by a virtual machine, comprising: parsing target bytecode, determining instruction type of the target bytecode; the target bytecode comprises: bytecode in an application module, bytecode in an application program or bytecode in a library module; according to the instruction type, obtaining matching operands, and according to the operands, performing security access legality check matched with the instruction type; after the security legality check passes, executing the target bytecode.

2. The method of claim 1, wherein, parsing target bytecode, comprising: parsing target bytecode in a target application currently running in a target logical channel; wherein the target application is obtained by installing a target application module, or; parsing target bytecode in a target library module currently invoked and executed in a target logical channel.

3. The method of claim 2, wherein, According to the instruction type, obtaining matching operands, and according to the operands, performing security access legality check matched with the instruction type, comprising: when it is determined that the instruction type is a memory data access instruction, obtaining attribute information corresponding to target memory data required to be accessed and a target module to which the target bytecode belongs; wherein the target module comprises: a target application module or a target library module; According to attribute information and the target module to which the target bytecode belongs, performing memory access legality check.

4. The method of claim 3, wherein, According to attribute information and the target module to which the target bytecode belongs, performing memory access legality check, comprising: According to attribute information, determining the data type of the target memory data; According to the data type, the access module to which the target memory data belongs and the target module, performing memory access legality check.

5. The method of claim 4, wherein, According to attribute information, determining the data type of the target memory data, comprising: if the attribute information is a memory offset, then according to the target module, determining a starting memory address; According to the memory offset, the starting memory address and a preset memory space management mode, determining the data type of the target memory data.

6. The method of claim 4, wherein, According to the data type, the access module to which the target memory data belongs and the target module, performing memory access legality check, comprising at least one of the following: if the target module is a target library module, and the target memory data belongs to a module data set in the library module, then it is determined that the memory access legality check passes; if the target module is a target library module, and the target memory data belongs to a module data set in the application module, then it is determined that the memory access legality check passes.

7. The method of claim 4, wherein, According to the data type, the access module to which the target memory data belongs and the target module, performing memory access legality check, comprising: if the target module is a target application module, and the target memory data belongs to an application data set in the application module, then according to the target bytecode and the virtual machine running domain where the target memory access data is located, performing memory access legality check.

8. The method of claim 7, wherein, According to the target bytecode and the virtual machine running domain where the target memory access data is located, performing memory access legality check, comprising: if the target memory access data belongs to persistent variable data, temporary static variable data or cross-domain data in the application data set, then obtaining the current virtual machine running domain in the target logical channel where the target bytecode is executed; determining whether the virtual machine running domain where the module data set and the program data set to which the target memory data belongs is consistent with the current virtual machine running domain in the target logical channel; if yes, determining that the memory access legality check passes; otherwise, determining that the memory access legality check fails.

9. The method of claim 7, wherein, According to the virtual machine running domain where the target bytecode and the target memory access data are located, performing the memory access legality check, comprising: if the target memory access data belongs to the temporary dynamic variable data in the application data set, detecting whether the virtual machine running domain where the module data set and the program data set to which the target memory data belongs, the current virtual machine running domain in the target logical channel where the target bytecode is executed, and the virtual machine running domain selected to be applied in the target logical channel are all the same; if yes, determining that the memory access legality check passes; otherwise, determining that the memory access legality check fails.

10. The method of claim 4, wherein, According to the attribute information, determining the data type of the target memory data, further comprising: if it is determined that the attribute information exceeds the space range of the module global data memory and the indirect access variable stack pre-divided, directly determining that the memory access legality check fails.

11. The method of claim 1 or 2, wherein, According to the instruction type, obtaining the matching operand, and performing the security access legality check matched with the instruction type according to the operand, comprising: when it is determined that the instruction type is the instruction of pushing or popping the operand of the virtual machine stack, obtaining the operation type of the operand, and performing the virtual machine stack boundary legality check according to the operation type of the operand.

12. The method of claim 11, wherein, According to the operation type of the operand, performing the virtual machine stack boundary legality check, comprising: if the operation type of the operand is the popping operation of the set number of operands, before performing the popping operation, checking whether the virtual machine stack overflows downward after the occupied stack cell space of the current virtual machine stack is reduced by the stack cell space occupied by the set number of operands; if no, determining that the virtual machine stack passes the virtual machine stack boundary legality check.

13. The method of claim 11, wherein, According to the operation type of the operand, performing the virtual machine stack boundary legality check, comprising: if the operation type of the operand is the pushing operation of the set number of operands, before performing the pushing operation, checking whether the virtual machine stack overflows upward after the occupied stack cell space of the current virtual machine stack is increased by the stack cell space occupied by the set number of operands; if no, determining that the virtual machine stack passes the virtual machine stack boundary legality check.

14. The method of claim 2, wherein, According to the instruction type, obtaining the matching operand, and performing the security access legality check matched with the instruction type according to the operand, comprising: when it is determined that the instruction type is the function call instruction of the target function, obtaining the function index of the target function and the number of parameters passed in by the target bytecode; performing the function call legality check according to the function index of the target function and the number of parameters passed in by the target bytecode.

15. The method of claim 14, wherein, Before obtaining the function index of the target function and the number of parameters passed in by the target bytecode, further comprising: When the target module to which the target bytecode belongs is a target application module and the module to which the target function belongs is an application module, it is detected whether the module to which the target function belongs is consistent with the target module to which the target bytecode belongs; If not, after it is determined that the target application program is authorized by the application program to which the target function belongs to call the target function, the current virtual machine running domain of the target logic channel is switched to the virtual machine running domain corresponding to the application program to which the target function belongs.

16. The method of claim 14, wherein, Before the function index of the target function and the number of parameters passed in by the target bytecode are acquired, the method further comprises: When the target module to which the target bytecode belongs is a target application module and the module to which the target function belongs is a library module, the module data set and the module program set in the current virtual machine running domain of the target logic channel are directly switched to the module data set and the module program set in the virtual machine running domain corresponding to the library module to which the target function belongs.

17. The method of claim 14, wherein, Before the function index of the target function and the number of parameters passed in by the target bytecode are acquired, the method further comprises: When the target module to which the target bytecode belongs is a target library module and the module to which the target function belongs is an application module, the current virtual machine running domain of the target logic channel is directly switched to the virtual machine running domain corresponding to the application program to which the target function belongs; When the target module to which the target bytecode belongs is a target library module and the module to which the target function belongs is a library module, the virtual machine running domain is not switched.

18. The method of claim 14, wherein, According to the function index of the target function and the number of parameters passed in by the target bytecode, the legality of the function call is checked, comprising: Acquiring the function index corresponding to the target function; When the target function is an external function of the target application program to which the target bytecode belongs, the validity of the function index is checked according to the import section of the target module to which the target bytecode belongs and the export section in the calling module to which the target function belongs; If it is determined that the function index is valid, it is further checked whether the number of parameters passed in by the target bytecode is consistent with the number of function parameters defined by the code section in the calling module; If yes, it is determined that the legality of the function call is passed.

19. The method of claim 18, wherein, According to the import section of the target module to which the target bytecode belongs and the export section in the calling module to which the target function belongs, the validity of the function index is checked, comprising: When it is determined that the function index does not exceed the number of functions imported by the import section in the target module and the function index appears in the import section in the calling module, it is determined that the function index is valid.

20. The method according to any one of claims 16-19, characterized by, After the legality of the function call is passed and the target bytecode is executed, the method further comprises: In the target logic channel, the bytecode corresponding to the target function is started to be executed; After the execution of the bytecode corresponding to the target function is completed, the current virtual machine running domain of the target logic channel is restored to the virtual machine running domain corresponding to the target bytecode.

21. The method of claim 20, wherein, After the bytecode corresponding to the target function is started to be executed in the target logic channel, the method further comprises: In the execution process of the bytecode corresponding to the target function, if it is necessary to access data of a set storage location, it is detected whether the set storage location is located within the range of the indirect access variable stack space matched with the target function; If yes, the target function is allowed to access the data of the set storage location; otherwise, the target function is prohibited from accessing the data of the set storage location.

22. The method of claim 1 or 2, wherein, According to the instruction type, a matched operand is acquired, and a security access legality check matched with the instruction type is performed according to the operand, including: When it is determined that the instruction type is a variable operation instruction in the execution process of a set calling function, a local variable index in the variable operation instruction is acquired; A local variable index legality check is performed on the local variable index by querying a current function stack frame in a virtual machine stack.

23. The method of claim 1 or 2, wherein, According to the instruction type, a matched operand is acquired, and a security access legality check matched with the instruction type is performed according to the operand, including: When it is determined that the instruction type is a conditional jump instruction in a control instruction, a jump offset in the conditional jump instruction is acquired; In a target module to which the target bytecode belongs, function range information corresponding to a function to which the target bytecode belongs is acquired; According to a target bytecode address and the function range information, a jump offset legality check is performed on the jump offset.

24. A secure access device, comprising: Configured in a virtual machine, including: An instruction type determination module configured to parse target bytecode and determine an instruction type of the target bytecode; the target bytecode includes bytecode in an application module, bytecode in an application program, or bytecode in a library module; A legality check module configured to acquire a matched operand according to the instruction type, and perform a security access legality check matched with the instruction type according to the operand; A bytecode execution module configured to execute the target bytecode after the security access legality check passes.

25. An electronic device, comprising: The electronic device is installed with an operating system, and a virtual machine is executed in the operating system; the electronic device includes: At least one processor; and A memory in communication connection with the at least one processor; wherein The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor to enable the at least one processor to execute the security access method in any one of claims 1-23.

26. The electronic device of claim 25, wherein, The electronic device is a resource-constrained device.

27. The electronic device of claim 26, wherein, The resource-constrained device includes a smart card, a USBKEY, an embedded security control module, and a secure element.

28. A terminal, characterized by The electronic device includes any one of claims 25-27.

29. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for enabling the processor to execute the security access method in any one of claims 1-23 when executed.

30. A computer program product, characterised in that, The computer program product includes a computer program, and the computer program implements the security access method in any one of claims 1-23 when executed by the processor.

Images