Secure access method

Abstract

The invention discloses a secure access method. 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, and when the security validity check is not passed, forbidding execution of the target byte code, and carrying out exception prompt. 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] The present invention relates to the field of computer technology, and in particular to a secure access method. Background Art

[0002] WebAssembly (wasm for short) belongs to the virtual instruction set architecture. Based on WebAssembly bytecode technology, applications can be written in a variety of programming languages, and the written applications are converted to generate WebAssembly bytecode, which is interpreted and executed by the virtual machine, so that the application can run normally.

[0003] In the process of implementing this application, the inventors found that the above technology has at least the following problems: when WebAssembly bytecode is applied to resource-constrained devices, its executable files and instruction sets need to be optimized in combination with device resources; the segments and function representations of executable files are also included. Optimization can reduce the space occupied by files and improve execution performance, but the application scenarios facing the device require stronger security guarantees. Therefore, whether it is file content or bytecode execution, security policies are required. Security policies should cover memory access, function calls, local variables and parameter access, and conditional branch statement execution during bytecode execution. Summary of the invention

[0004] The embodiment of the present invention provides a secure access method to enable an application to perform secure memory access in a resource-constrained environment.

[0005] According to one aspect of an embodiment of the present invention, a secure access method is provided, which is executed by a virtual machine and includes:

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

[0007] According to the instruction type, obtaining a matching operand, and according to the operand, performing a security access legality check matching the instruction type;

[0008] After the security access legality check passes, the target bytecode is executed; when the security legality check fails, the execution of the target bytecode is prohibited, and an exception prompt is given.

[0009] According to another aspect of an embodiment of the present invention, there is also provided a secure access device, which is configured in a virtual machine and includes:

[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: the bytecode in the application module, the bytecode in the application program or the bytecode in the library module;

[0011] A legality check module, used to obtain a matching operand according to the instruction type, and perform a security access legality check matching the instruction type according to the operand;

[0012] The bytecode execution module is used to execute the target bytecode after the security access legality check passes, and to prohibit the execution of the target bytecode and issue an exception prompt when the security legality check fails.

[0013] According to another aspect of an embodiment of the present invention, there is further provided an electronic device, on which an operating system is installed, a virtual machine is executed in the operating system, and the electronic device includes:

[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 executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the security access method as described in any one of the embodiments of the present invention.

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

[0018] According to another aspect of an embodiment of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the secure access method as described in any one of the embodiments of the present invention when executed.

[0019] According to another aspect of an embodiment of the present invention, a computer program product is further provided. The computer program product includes a computer program. When the computer program is executed by a processor, the secure access method as described in any one of the embodiments of the present invention is implemented.

[0020] The technical solution of the embodiment of the present invention parses the target bytecode through a virtual machine to determine the instruction type of the target bytecode; then, according to the instruction type, a matching operand is obtained, and according to the operand, a security access legitimacy check matching the instruction type is performed; after the security access legitimacy check is passed, the implementation method of executing the target bytecode is that the virtual machine can perform a security access legitimacy check on each bytecode before executing the bytecode, and during the operation of the virtual machine, it is ensured that the access to each data and the call of each function are safe. The embodiment of the present invention creatively proposes a new way for an application to perform secure memory access in a resource-constrained environment, which effectively improves the operation reliability of the virtual machine.

[0021] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

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

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

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

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

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

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

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

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

[0031] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work 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 and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0033] For ease of understanding, the relevant technologies involved in each embodiment of the present invention are briefly described first. Figure 1 Detailed description of the invention is given in the figure.

[0034] like Figure 1 As shown, a binary loadable file can be loaded into the operating system of an electronic device through a download tool. Among them, a binary loadable file refers to a binary file generated by an application converter and can be loaded into the operating system. After the binary loadable file is loaded into the operating system, it becomes a binary executable file. The binary executable file contains code that can be processed by the executor in the virtual machine, and the binary executable file includes an executable module.

[0035] An executable module is an application module, which can be understood as an application executable code container contained in a binary executable file and can be directly executed by the operating system. Applications can be created in application modules, while library modules cannot. Application modules or library modules run in a virtual machine in the form of bytecode.

[0036] Application data is the data required for the application to run, which is included in the application data set and module data set. The application refers to the application code, that is, the executable binary file, which is included in the module assembly. The application module can create an application (or application instance).

[0037] When executing bytecodes, the virtual machine needs to exchange data with the runtime data area in the operating system.

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

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

[0040] The global variable memory stores the module global data for the running module. On any logical channel, 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, when the application is deselected, all global variable memory spaces matching the current logical channel are reclaimed.

[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 parameters, local variables, intermediate running results, return values, and calling method information.

[0042] The heap is used to store application data. The data in the heap space will not be lost when the 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 the embodiments of the present invention, the secure access to data and code is controlled during the execution of bytecodes by the virtual machine. During the execution of functions of the module (application module or library module), during the execution of functions or methods of other modules, during the access to the virtual machine stack or indirectly accessing the runtime data area such as the variable stack, the corresponding security policy is applied to ensure that the access to each module data and application data is secure, and the call to each module code is also secure. That is, during the execution of bytecodes, the virtual machine ensures the security of access by performing runtime security checks.

[0045] Figure 2A flowchart of a secure access method provided by an embodiment of the present invention, this embodiment can be applied to the case where a virtual machine performs a secure access legitimacy check on a bytecode to be executed, the method can be executed by a secure access device, the device can be implemented in the form of hardware and / or software, and can generally be configured in an electronic device with an operating system installed, and executed by a virtual machine installed in the operating system. Typically, the operating system can be an embedded operating system, for example, an AOS operating system.

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

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

[0048] In this embodiment, a runtime environment (RTE, Real-Time Environment) can be adapted in 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, which can be regarded as an ultra-lightweight container. The application runs in the runtime environment and can be completely isolated from the native functions of the operating system.

[0049] In the runtime system, multiple logical channels can be opened to execute multiple applications at the same time. During the execution of each application, it may involve calling functions of other applications or calling functions in the execution library module. The execution of the above applications or calling functions is implemented in the 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 may be a binary program code to be executed, typically a WebAssembly bytecode. The target bytecode may be a bytecode in a selected application in a specified logical channel, or a bytecode in another application directly or indirectly called by the selected application, or a bytecode in a setting library module or a corresponding application module directly or indirectly called by the selected application.

[0052] Logical channel can be understood as a concept used to establish a communication connection between the host and the restricted device. It allows multiple independent communication channels to be established between the host and the restricted device at the same time, each channel has its own command and response flow, and is isolated from each other.

[0053] In a specific example, if the selected application in the specified logical channel is application A, during the execution of application A, application B is called and executed, and during the process of being called and executed, application B further calls library module C. At this time, it means that library module C is indirectly called by the selected application A.

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

[0055] Parsing target bytecodes in a target application currently running in a target logical channel; wherein the target application is obtained by installing a target application module, or;

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

[0057] Among them, the library module is a module that does not contain an entry function and cannot create an application. Therefore, the library module cannot be selected for use in a specified logical channel. However, during the execution of the selected application in the specified logical channel, the library module can be selected to call the content in the library module. Then, when the library module is called, the target bytecode inside the library module can be executed.

[0058] Furthermore, the target application may be a selected application in the target logical channel, or may be an application selected and called by the selected application during its operation.

[0059] By parsing the target bytecode, the instruction type corresponding to the target bytecode can be obtained. The instruction type may include memory data access instructions, such as memory data load or read instructions, push or pop instructions for operands in a virtual machine stack, function call instructions, and data access or variable operation instructions during the function call process.

[0060] S220. Obtain a matching operand according to the instruction type, and perform a security access legality check that matches the instruction type according to the operand.

[0061] Generally speaking, bytecodes are composed of opcodes and operands. The opcodes represent certain characteristic types of operations, and the operands represent the parameters required for this operation.

[0062] Optionally, the opcode may be first obtained in the target bytecode in a regular matching manner, and the instruction type corresponding to the target bytecode may be determined based on the opcode. Then, the matching operand may be extracted according to the operand extraction rule corresponding to the instruction type.

[0063] In this embodiment, according to actual conditions, you can choose to directly obtain the matching operand 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, etc. This embodiment does not limit this.

[0064] It is understandable that different instruction types may cause different security threats. For example, if it is a memory access instruction, the security threat it may cause is access exceeding the limit, causing the leakage of sensitive information. If it is an instruction to push or pop operands in the virtual machine stack, it may cause the virtual machine stack to overflow. If it is a function call instruction, it may cause illegal access or abnormal access.

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

[0066] S230. After the security access legality check passes, the target bytecode is executed; when the security legality check fails, the execution of the target bytecode is prohibited, and an exception prompt is given.

[0067] Among them, when the security access legitimacy check passes, it can be determined that there will be no security risk after executing the target bytecode. At this time, 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 prompt will be thrown, such as a security exception, to ensure the security of data access to the greatest extent.

[0068] The technical solution of the embodiment of the present invention parses the target bytecode through a virtual machine to determine the instruction type of the target bytecode; then, according to the instruction type, a matching operand is obtained, and according to the operand, a security access legitimacy check matching the instruction type is performed; after the security access legitimacy check passes, the implementation method of executing the target bytecode is that the virtual machine can perform a security access legitimacy check on each bytecode before executing the bytecode, and during the operation of the virtual machine, it is ensured that the access to each data and the call of each function are safe. The embodiment of the present invention creatively proposes a new method for virtual machine-based applications to perform secure memory access in a resource-constrained environment, which effectively improves the operation reliability of the virtual machine.

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

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

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

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

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

[0074] Correspondingly, the target module may include: a target application module or a target library module. Specifically, when the target bytecode is the bytecode in the application program, the target application module is the application module to which the application program belongs.

[0075] Among them, memory data access instructions refer to instructions that require operations such as data loading, data storage, data copying or data filling on memory data, for example, instructions 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.

[0076] Alternatively, when the virtual machine executes the target bytecode of a function call such as call_u16, call_outer_u8, call_inner_u8 or call_indirect by executing an API call, the instruction type is determined to be a memory data access instruction. At this time, the function parameter is a pointer, array or structure type, etc., and the actual parameter is a memory address (also known as a memory offset). When the function is called, the parameters are parsed and the legality of the memory access is checked at the same time.

[0077] Among them, the memory access legitimacy check includes the legitimacy check of the virtual machine running domain where the memory data is located and the legitimacy check of the memory offset value.

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

[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 the memory, memory data to be copied, and data to be filled in the memory.

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

[0082] As mentioned above, the target bytecode can be the bytecode in the module where the application is set (executable module), which can be installed through the application module to create the application, and the target bytecode belongs to the set application module. In addition, the target bytecode can also be the bytecode in the set library module, and the target bytecode directly belongs to the set library module.

[0083] Generally speaking, the target bytecode runs inside a specified logical channel, and each logical channel corresponds to a virtual machine running domain adapted to it. In the virtual machine running domain, the target module to which the currently running target bytecode belongs will be recorded. The target module can be an application module or a library module. If the target module is an application module, the target application to which the currently running target bytecode belongs will also be synchronously recorded in the virtual machine running domain.

[0084] The virtual machine running domain refers to the virtual memory space built by RTE for the range of application running permission access data (also called accessible data). It records information such as application identification and logical channels. Corresponding to the logical channel, there is only one running application on each logical channel that is bound to the virtual machine running domain on the logical channel.

[0085] Optionally, the designated logical channel of the currently running target bytecode may be first obtained, and the virtual machine running domain corresponding to the selected application on the designated logical channel may be correspondingly obtained, and the virtual machine running domain corresponding to the currently running target bytecode may be simultaneously obtained.

[0086] S330. Determine the data type of the target memory data according to the attribute information.

[0087] In this embodiment, multiple virtual channels can be opened in the operating system to execute different application programs. The operating system will allocate different memory spaces to different application programs to store various application data generated in real time during the running of the application programs.

[0088] In a specific example, the data corresponding to each application module can be stored in a storage space specifically used to store module data sets and application data sets in the order of module 1, module 2, ..., module n or by dynamically allocating space for each module and application. When storing data corresponding to a certain application module, the stored data may include module assembly, module data set, application data set of application 1, application data set of application 2, ..., application data set of application n.

[0089] Correspondingly, in an application data set storing a certain application program, each type of application data is stored according to a set data sorting method or dynamically allocated space.

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

[0091] Accordingly, according to the attribute information, determining the data type of the target memory data may specifically include:

[0092] If the attribute information is a memory offset, the starting memory address is determined according to the target module (the application module or library module to which the target bytecode belongs); 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 above, data of various data types are arranged in the memory according to a preset data arrangement. Typically, different modules are stored in different memory spaces, and 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 the attribute information, the actual memory address of the target memory data can be located, and based on the actual memory address, the module (i.e., access module), application module or library module to which the target memory data belongs can be determined, and when it is determined that the module to which it belongs is an application module, the application module to which the target memory data belongs is further determined, and at the same time, the data type of the target memory data can also be determined.

[0094] The data types may include: module data set, application data set or module program set data.

[0095] The module data set contains global data. Global data refers to data defined in the application and visible to the entire module. Its scope is limited to a specific module, also known as global variables. This type of data is usually used to share information within the module, but is not visible or accessible in other modules. A module can be understood as an application executable code container contained in a binary file, including the application's instructions, data, and metadata, which can be run directly by the operating system. Modules generally include 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 usually used to store constants, configuration information, or other values ​​that do not change during the application's runtime, such as the application's constant data. 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 the application's global data or the application's global variable stack.

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

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

[0100] Among them, 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. When a specific event occurs, it will be cleared or reset to ensure security and protect sensitive data.

[0101] Temporary static variable data means that whenever the embedded operating system is reset, the resource state will be reset to 0. This resource state will not be shared between applications and is usually used to store data related to a specific session or transaction to ensure security and data isolation. Temporary dynamic variable data means that during the interaction with the application, the resource state will be retained until the application is deselected, and the resource state will be cleared and reset to 0. This resource is usually used to share temporary data between applications, such as temporary counters or caches.

[0102] Persistent data refers to a type of non-volatile storage data created by calling the storage space allocation interface provided by the operating system runtime environment during the installation or operation of the application module, and its initial value is 0. Persistent data belongs to the application itself, and the persistent data can be written and read through the interface or pointer variable provided by the operating system runtime environment. The virtual machine instruction can directly access the persistent data through the pointer variable.

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

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

[0105] In this embodiment, it is pre-specified that a boundary check is performed on the allocated memory range when accessing a module data set.

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

[0107] If it is determined that the attribute information exceeds the pre-divided module global data memory and the spatial range of the indirect access variable stack, it is directly determined that the memory access legality check fails.

[0108] In this embodiment, when the memory data of the operating system is accessed, the data stored in the module global data memory and the indirect access variable stack are mainly accessed. The above-mentioned module global data memory and the indirect access variable stack both have a pre-set storage space range. Furthermore, when the memory address matching the attribute information exceeds the pre-divided module global data memory and the indirect access variable stack space range, it means that the memory access exceeds the limit, and then, it can be directly determined that the memory access legality check fails. At this time, an error prompt can be thrown, for example, a security exception, to directly deny access to the target memory data.

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

[0110] In this embodiment, when the RTE runs to a different module assembly, it should switch to the running domain to which the module data set belongs. Among them, the library module should be able to access the module data set of the application module in the current running domain. The library module should be able to access the module data set of the library module.

[0111] Furthermore, when the target bytecode belongs to a target library module, the module data set in the application module or the library module can be accessed.

[0112] Accordingly, in an optional implementation of this embodiment, performing a memory access legality check according to 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 a module data set in the library module, determining that the memory access legality check passes;

[0114] If the target module is a target library module, and the target memory data belongs to a module data set in an application module, it is determined that the memory access legality check passes.

[0115] In this embodiment, a security access policy between applications created by the same application module is further specified, that is, module data sets and module program sets should be shared between different applications of the same module.

[0116] Accordingly, 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 when the target application module is the same as the application module to which the target memory data belongs, it is determined that the memory access legality check passes.

[0118] In this embodiment, it is further stipulated that an application module should not be able to access module data sets of other application modules across execution domains.

[0119] Correspondingly, if the target module is a target application module, and the target memory data belongs to a module data set, then when the target application module is the same as the application module to which the target memory data belongs, it is determined that the memory access legality check passes.

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

[0121] Among them, performing a memory access legality check according to the virtual machine running domain where the target bytecode and the target memory access data are located may specifically include:

[0122] If the target memory access data belongs to persistent variable data, temporary static variable data or cross-domain data in the application data set, the current virtual machine running domain in the target logical channel for executing the target bytecode is obtained;

[0123] Detect whether the virtual machine running domain where the module data set and the program data set to which the target memory data belongs are located is consistent with the current virtual machine running domain in the target logical channel;

[0124] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[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 allowed based on the current virtual machine running domain only when the virtual machine running domain where the module data set and the program data set to which the target memory data belongs are located is consistent with the current virtual machine running domain in the target logical channel.

[0126] That is, the application module to which the target memory data belongs may be the module to which the selected application belongs in the logical channel, or may be other library modules called by the selected application during execution, or application modules to which other applications belong. As long as the current virtual machine running 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 safely accessed.

[0127] In another optional implementation of this embodiment, if the target memory access data belongs to temporary dynamic variable data in the application data set, it is detected 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 executing the target bytecode, and the virtual machine running domain of the selected application in the target logical channel are all the same;

[0128] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[0129] In this embodiment, it is pre-specified that different applications cannot access each other's temporary dynamic variable data. Therefore, in a special case, the selected application in the logical channel is application A. During the execution of application A, application B is called and executed. During the execution of application B, if application B wants to access the temporary dynamic variable data belonging to application A, the access is prohibited. By comparing the virtual machine running domains, data access in the above situation can be avoided.

[0130] S350. After the security access legality check passes, the target bytecode is executed. When the security legality check fails, the execution of the target bytecode is prohibited, and an exception prompt is given.

[0131] The technical solution of the embodiment of the present invention can effectively verify the legality of access to the target memory data when using a memory data access instruction to access the target memory data by obtaining the data type of the target memory data, the module data set to which the target memory data belongs, and the virtual machine running domain where the module assembly is located. The access to each module data and application data is safe, 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, it is detected whether the virtual machine running domain where the module data set and the program data set to which the target memory data belongs are located is the same as the virtual machine running domain corresponding to the target module to which the target bytecode belongs;

[0133] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[0134] That is, in a specific example, if the data type is module read-only data in the global data, it is detected whether the access module to which the target memory data belongs is the same as the target module; if so, it is determined that the memory access legitimacy check passes; otherwise, it is determined that the memory access legitimacy check fails.

[0135] For module read-only data, different applications of the same application module can access it, but other applications of different application modules cannot access it. Accordingly, the application module to which the target memory data belongs, that is, the access module, can be obtained first. When the access module is consistent with the target module, it is determined that the memory access legality check has passed.

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

[0137] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[0138] That is, in a specific example, if the data type is module global data in global data, it is detected whether the application to which the target memory data belongs is the same as the application to which the target bytecode belongs; if so, it is determined that the memory access legitimacy check passes; otherwise, it is determined that the memory access legitimacy check fails.

[0139] In each embodiment of the present invention, module global data is independently allocated on different logical channels. Since different applications of the same application module can only be run successively on the same logical channel, in this case, module global data is allocated when the application module is running and the allocated module global data is recovered when the application module is canceled. Different applications cannot access this data from each other.

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

[0141] Figure 4 A flowchart of another secure access method provided for an embodiment of the present invention. This embodiment is refined based on the above embodiments. In this embodiment, the operation of "obtaining a matching operand according to the instruction type, and performing a security access legality check that matches the instruction type according to the operand" is concretized as follows: "When it is determined that the instruction type is an instruction to push or pop an operand on a virtual machine stack, obtain the operation type of the operand, and perform a virtual machine stack boundary legality check according to the operation type of the operand." The specific implementation form 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 an application module, bytecode in an application program or bytecode in a library module.

[0145] S420: When it is determined that the instruction type is an instruction for pushing or popping an operand on a virtual machine stack, obtain an operation type of the operand.

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

[0147] Specifically, during the operation of the virtual machine stack, the boundary information of the current virtual machine stack space and the current function virtual machine stack space will be recorded. The boundary information may be the stack start space as the lower boundary of the virtual machine stack of the current function, and the stack size.

[0148] When the target bytecode is executed, it generally reads (or pops) one or more operands from the virtual machine stack. Before executing the operation, it first checks whether the virtual machine stack overflows after the current virtual machine stack is subtracted from the stack unit space occupied by one or more operands; or, writes (or pushes) one or more operands into the virtual machine stack. Before executing the operation, it first checks whether the current virtual machine stack overflows after the stack unit space occupied by one or more operands is added.

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

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

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

[0152] S450: Determine that the virtual machine stack fails the virtual machine stack boundary validity check.

[0153] When the virtual machine stack boundary legality check fails, the execution of the target bytecode is prohibited and an exception prompt is given.

[0154] S460 , determine that the virtual machine stack passes the virtual machine stack boundary legitimacy check, and execute S470 .

[0155] Specifically, in the virtual machine stack, the space of the current function stack frame should be sufficient to ensure that after one or more operands are written (or pushed) into the current stack space, the stack frame space does not exceed the maximum stack frame of the function. The maximum stack frame is the number of units of the function start stack frame + the maximum stack frame. For example, in one implementation, each operand occupies one unit, and one unit is 4 bytes.

[0156] For example, when executing target bytecodes such as i32.and, i32.or, i32.xor, and i32.shl, two operands need to be obtained from the current virtual machine stack. Then, it is necessary to first check whether the virtual machine stack overflows after subtracting the stack unit space occupied by the two operands from the current virtual machine stack, that is, it is less than the starting boundary of the current function virtual machine stack space. If it is less, the access is illegal and an error prompt (such as a security exception) should be thrown; if it is not less, the two operands are popped from the virtual machine stack and the corresponding calculation is performed.

[0157] Similarly, when the calculation result of an operand needs to be stored in the current virtual machine stack after the calculation is completed, it is necessary to first check whether the virtual machine stack overflows after the stack unit space occupied by the current virtual machine stack plus 1 operand, that is, whether it is larger than the maximum stack frame boundary of the current function virtual machine stack space. If it is larger, the access is illegal and an error prompt (such as a security exception) should be thrown; if it is smaller, the calculation result is pushed into the virtual machine stack.

[0158] S470: Execute the target bytecode.

[0159] The technical solution of the embodiment of the present invention obtains the operation type of the operand when determining that the instruction type is an instruction for pushing or popping an operand on the virtual machine stack, and performs a virtual machine stack boundary legitimacy check based on the operation type of the operand, thereby ensuring that the access operation to the virtual machine stack is safe and legal, thereby effectively improving the operating reliability of the virtual machine.

[0160] Figure 5 A flowchart of another secure access method provided for an embodiment of the present invention. This embodiment is refined based on the above embodiments. In this embodiment, the operation of "obtaining a matching operand according to the instruction type, and performing a security access legality check that matches the instruction type according to the operand" is concretized as follows: "When it is determined that the instruction type is a function call instruction for a target function, obtain the function index of the target function and the number of parameters passed in by the target bytecode; perform a function call legality check according to the function index of the target function and the number of parameters passed in by the target bytecode." The specific implementation form of the above operation is described in detail.

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

[0162] S510: parse the target bytecode to determine the instruction type of the target bytecode.

[0163] The target bytecode includes: bytecode in an application module, bytecode in an application program or bytecode in a library module.

[0164] S520: When it is determined that the instruction type is a function call instruction for a target function, obtain a function index of the target function and the number of parameters passed in by the target bytecode.

[0165] In a specific example, if target bytecodes of the form of call_u16, call_outer_u8, call_inner_u8, and call_indirect are executed, it is necessary to call the target function contained in the target bytecode.

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

[0167] 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.

[0168] In various embodiments of the present invention, it is pre-defined that the bytecode in the application can access internal functions in the application module to which it belongs, or functions in the library module; alternatively, the bytecode in the application can also access functions in other applications that are pre-authorized to it, that is, external functions.

[0169] In an embodiment of the present 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, it is necessary to obtain the target logical channel for executing the target bytecode, and switch the current virtual machine running domain of the target logical channel to the virtual machine running domain where the target function is located.

[0170] That is, an application module can call interfaces authorized by other application modules, but it needs to switch the virtual machine running domain. The interface calling permissions can be divided into the following three situations:

[0171] The interface in the library module should allow all other library modules or application modules to call;

[0172] By default, the interfaces in the application module cannot be called by other application modules;

[0173] When compiling and generating an application module, one or more interface functions can be specified to be exported. The exported interface should be allowed to be authorized to be called by other applications; the interface that is not exported should not be authorized to be called by other applications.

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

[0175] 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, detecting whether the module to which the target function belongs is consistent with the target module to which the target bytecode belongs;

[0176] 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 execution domain of the target logical channel is switched to the virtual machine execution domain corresponding to the application to which the target function belongs.

[0177] 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, the target function is determined to be an internal function accessible to the target bytecode, thereby eliminating the need to switch the virtual machine running domain.

[0178] That is, if it is determined that the target function is an external function of the target module to which the target bytecode belongs, and the external function belongs to other application modules, then when the external function is not authorized to the target application, the target bytecode is directly denied access to the target function.

[0179] Specifically, it is possible to determine whether the application to which the target function belongs authorizes 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 above access request is completed by calling the authorization service interface API. Each application on the logical channel has an independent authorization status information record, and the authorization status information may include, for example, the identifier of the authorized application and the module information of the authorized application.

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

[0181] 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 module program set in the current virtual machine running domain of the target logical channel are directly switched to the module data set and module program set in the virtual machine running domain corresponding to the library module to which the target function belongs.

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

[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 an application module, directly switching the current virtual machine running domain of the target logical channel to the virtual machine running domain corresponding to the application program to which the target function belongs;

[0184] 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, and the module data set and module program set in the current virtual machine running domain of the target logical channel are directly switched to the module data set and module program set in the virtual machine running domain corresponding to the library module to which the target function belongs.

[0185] S530: Obtain a function index corresponding to the target function.

[0186] The function index can be understood as the index assigned to the imported function (ie, external function) and the internal function of the module (application module or library module), and the function is called by the function index. By parsing the target bytecode, the function index corresponding to the target function can be obtained accordingly.

[0187] 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 according to the import segment of the target module to which the target bytecode belongs and the export segment in the calling module to which the target function belongs. If it is determined that the function index is valid, execute S550; otherwise, execute S570.

[0188] Specifically, the import segment of the application module records the information of the imported functions in the module, and the export segment of the application module records the function index of the exported functions in the module. A module calling functions of other modules is called the imported functions of this module, and a module exporting functions called by other modules is called the exported functions of this module.

[0189] Furthermore, when the target function is determined to be an external function of the module to which the target application to which the target bytecode belongs through the module identifier to which the target function belongs, the target function base and its index information will be recorded in a specific form in the export segment of the module to which the target function belongs (that is, the calling module) and the import segment of the target module to which the target bytecode belongs. Based on the above two contents, the validity of the function index of the target function can be checked.

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

[0191] When it is determined that the function index does not exceed the number of functions imported by the import segment in the target module, and the function index appears in the import segment in the calling module, it is determined that the function index is valid.

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

[0193] The code segment of the module stores the local variable information and bytecode of the functions in the module. The target function is located inside the calling module. By checking whether the number of parameters passed by the target bytecode to the target function is consistent with the number of function parameters defined for the target function in the code segment of the calling module, the legality check of the function call can be further improved.

[0194] In a specific example, when checking the validity of a function index, if the function is called as a function of the current module (the module where the target bytecode is located), then when the function index is greater than the number of all functions in the current module (including the number of user-defined functions in this module and the number of functions imported by the import segment), the function index is determined to be illegal and an error prompt (such as a security exception) is thrown; if the function is called as a function of another module, then when the function index is greater than the number of functions imported by the import segment of the current module, the function index is determined to be illegal and an error prompt (such as a security exception) is thrown; if the function is called as a function of another module and the function index does not appear in the export segment where the function is defined in the other module, the function index is determined to be illegal and an error prompt (such as a security exception) is thrown; if the function index is a legal value, further check whether the function parameter type and the number of passed parameters in the import segment of the current module are consistent with the function located by the parsing, if not, throw an error prompt (such as a security exception); otherwise, enter the called function and continue execution.

[0195] S560, determine whether the function call has passed the legality check, and execute S580.

[0196] S570: Determine whether the function call fails the legality check.

[0197] S580: Execute the target bytecode.

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

[0199] In the target logical channel, start executing the bytecode corresponding to the target function;

[0200] After the execution of the bytecode corresponding to the target function is completed, it is possible to restore the current virtual machine execution domain of the target logical channel to the virtual machine execution domain corresponding to the target bytecode.

[0201] In this optional implementation, after the target function in other application modules is called, it is necessary to re-switch the current virtual machine running domain of the target logical channel to the virtual machine running domain where the target bytecode is located to ensure data isolation between different applications and ensure data security.

[0202] Alternatively, after the target function in the library module is called, the module data set and module program in the current virtual machine execution domain of the target logical channel need to be switched back to the module data set and module program set that match the target bytecode.

[0203] Based on the above embodiments, after starting to execute the bytecode corresponding to the target function in the target logical channel, the following method may also be included:

[0204] During the execution of the bytecode corresponding to the target function, if it is necessary to access data at a set storage location, detecting whether the set storage location is within the range of an indirect access variable stack space matching the target function;

[0205] If so, the target function is allowed to access the data at the set storage location; otherwise, the target function is prohibited from accessing the data at the set storage location.

[0206] In a specific example, when the target bytecode calls the target function of other application modules through a function call instruction, the target function is limited to accessing the indirect access variable stack space obtained by itself during runtime. That is, during the switching of the virtual machine running domain, the maximum address space of the indirect access variable stack accessible to the called function is recorded. When the access memory offset is resolved to the indirect access variable stack space, it should be checked whether it is greater than the maximum address allowed to access the space. If so, an error prompt (such as a security exception) should be thrown, otherwise, the access is allowed. Among them, the memory space of the local structure type data is the indirect access variable stack.

[0207] The technical solution of the embodiment of the present invention obtains the function index of the target function and the number of parameters passed in by the target bytecode when determining that the instruction type is a function call instruction for the target function; and performs a function call legality check according to the function index of the target function and the number of parameters passed in by the target bytecode. This can ensure that when the virtual machine calls a function in the module or calls a function or method in other modules, the entire call execution process is safe and legal, thereby effectively improving the operating reliability of the virtual machine.

[0208] On the basis of the above embodiments, obtaining a matching operand according to the instruction type, and performing a security access legality check matching the instruction type according to the operand may include:

[0209] When it is determined that the instruction type is a variable operation instruction in the process of setting the calling function execution, obtaining a local variable index in the variable operation instruction;

[0210] By querying the current function stack frame in the virtual machine stack, the local variable index is checked for legality.

[0211] In an example, when variable operation 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, local variable index validity check needs to be performed.

[0212] Among them, the number of parameters (paraNum) and the number of local variables (localNum) are used as the basis for checking the legitimacy of the local variable index in the current virtual machine function stack frame of the virtual stack. The local variable index should be smaller than the total size of the number of parameters (paraNum) and the number of local variables (localNum), otherwise an error prompt (such as a security exception) should be thrown.

[0213] On the basis of the above embodiments, obtaining an operand matching the instruction type and performing a security access legality check matching the instruction type according to the operand may include:

[0214] When it is determined that the instruction type is a conditional jump instruction in a control instruction, obtaining a jump offset in the conditional jump instruction;

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

[0216] The jump offset is checked for legitimacy according to the target bytecode address and the function range information.

[0217] In a specific example, when conditional jump instructions such as 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, try, catch, etc. are executed, the jump offset validity check needs to be performed.

[0218] When the virtual machine executes the target bytecode, it records the current bytecode address (for example, the bcPC variable); the module information records the range information of each function, for example, the function size, function start address, and function end address. By adding or subtracting the offset from the current bytecode address, the address obtained should also be within the current function range, otherwise an error message (such as a security exception) should be thrown.

[0219] The present invention provides a runtime data access method. When a virtual machine is running, the secure access to application data and code is controlled. During the execution of the application code, when executing the module function, calling other module functions, memory or stack and other memory and local variable access bytecode, a security policy is applied to ensure that the access to each module data and application data is secure, and the calling of each module code is also secure, thereby ensuring the security of the entire data access process.

[0220] Figure 6 A schematic diagram of the structure of a secure access device provided by an embodiment of the present invention. The device is configured in a virtual machine, such as Figure 6 As shown, the device comprises:

[0221] The 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: the bytecode in the application module, the bytecode in the application program or the bytecode in the library module;

[0222] A legality check module 620, configured to obtain a matching operand according to the instruction type, and perform a security access legality check matching the instruction type according to the operand;

[0223] The bytecode execution module 630 is used to execute the target bytecode after the security access legality check passes; when the security legality check fails, the execution of the target bytecode is prohibited and an exception prompt is given.

[0224] The technical solution of the embodiment of the present invention parses the target bytecode through a virtual machine to determine the instruction type of the target bytecode; then, according to the instruction type, a matching operand is obtained, and according to the operand, a security access legitimacy check matching the instruction type is performed; after the security access legitimacy check is passed, the implementation method of executing the target bytecode is that the virtual machine can perform a security access legitimacy check on each bytecode before executing the bytecode, and during the operation of the virtual machine, it is ensured that the access to each data and the call of each function are safe, and a new method for virtual machine-based applications to perform secure memory access in a resource-constrained environment is creatively proposed, which effectively improves the operation reliability of the virtual machine.

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

[0226] Parsing target bytecodes in a target application currently running in a target logical channel; wherein the target application is obtained by installing a target application module, or;

[0227] Parse the target bytecode in the target library module currently being executed in the target logical channel.

[0228] Based on the above embodiments, the legality checking module 620 specifically includes:

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

[0230] The memory legality check unit is used to perform memory access legality check according to attribute information and the target module to which the target bytecode belongs.

[0231] Based on the above embodiments, the memory legitimacy checking unit may specifically include:

[0232] A data type determination subunit, used to determine the data type of target memory data according to the attribute information;

[0233] The legitimacy check subunit is used to perform a memory access legitimacy check according to the data type, the access module to which the target memory data belongs, and the target module.

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

[0235] If the attribute information is a memory offset, determining a starting memory address according to the target module;

[0236] The data type of the target memory data is determined according to the memory offset, the starting memory address and a preset memory space management method.

[0237] In the above-mentioned embodiments, the legality checking subunit is specifically used to perform at least one of the following:

[0238] If the target module is a target library module, and the target memory data belongs to a module data set in the library module, determining that the memory access legality check passes;

[0239] If the target module is a target library module, and the target memory data belongs to a module data set in an application module, it is determined that the memory access legality check passes.

[0240] In the above-mentioned technical embodiments, the legality checking subunit is specifically used for:

[0241] If the target module is a target application module, and the target memory data belongs to an application data set in the application module, a memory access legality check is performed according to the target bytecode and the virtual machine running domain where the target memory access data is located.

[0242] In the above-mentioned embodiments, the legality checking subunit is further used for:

[0243] If the target memory access data belongs to persistent variable data, temporary static variable data or cross-domain data in the application data set, the current virtual machine running domain in the target logical channel for executing the target bytecode is obtained;

[0244] Detect whether the virtual machine running domain where the module data set and the program data set to which the target memory data belongs are located is consistent with the current virtual machine running domain in the target logical channel;

[0245] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[0246] In the above-mentioned embodiments, the legality checking subunit is further used for:

[0247] If the target memory access data belongs to temporary dynamic variable data in the application data set, then detect 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 executing the target bytecode, and the virtual machine running domain of the selected application in the target logical channel are all the same;

[0248] If so, it is determined that the memory access legality check passes; otherwise, it is determined that the memory access legality check fails.

[0249] Based on the above embodiments, the data type determination subunit may be further used to:

[0250] If it is determined that the attribute information exceeds the pre-divided module global data memory and the spatial range of the indirect access variable stack, it is directly determined that the memory access legality check fails.

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

[0252] When it is determined that the instruction type is an instruction for pushing or popping an operand on a 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.

[0253] Based on the above embodiments, the legality checking module 620 is further used to:

[0254] If the operation type of the operand is a pop operation of a set number of operands, before performing the pop operation, it is checked whether the virtual machine stack overflows downward after deducting the stack unit space occupied by the set number of operands from the occupied stack unit space of the current virtual machine stack;

[0255] If not, it is determined that the virtual machine stack passes the virtual machine stack boundary validity check.

[0256] Based on the above embodiments, the legality checking module 620 is further used to:

[0257] If the operation type of the operand is a push operation of a set number of operands, before executing the push operation, checking whether the virtual machine stack overflows upward after the occupied stack unit space of the current virtual machine stack is increased by the stack unit space occupied by the set number of operands;

[0258] If not, it is determined that the virtual machine stack passes the virtual machine stack boundary validity check.

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

[0260] An index and parameter number acquisition unit, used to acquire the function index of the target function and the number of parameters passed in by the target bytecode when determining that the instruction type is a function call instruction for the target function;

[0261] The function call legality checking unit is used to perform a function call legality check according to the function index of the target function and the number of parameters passed in by the target bytecode.

[0262] On the basis of the above embodiments, the present invention may further include: a first operation domain switching module, which is used to:

[0263] Before obtaining the function index of the target function and the number of parameters passed in by the target bytecode, 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, detecting whether the module to which the target function belongs is consistent with the target module to which the target bytecode belongs;

[0264] 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 execution domain of the target logical channel is switched to the virtual machine execution domain corresponding to the application to which the target function belongs.

[0265] On the basis of the above embodiments, the present invention may further include: a second operation domain switching module, which is used to:

[0266] 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 module program set in the current virtual machine running domain of the target logical channel are directly switched to the module data set and module program set in the virtual machine running domain corresponding to the library module to which the target function belongs.

[0267] On the basis of the above embodiments, the present invention may further include: a third operation domain switching module, which is used to:

[0268] Before obtaining the function index of the target function and the number of parameters passed in by the target bytecode, 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, directly switching the current virtual machine running domain of the target logical channel to the virtual machine running domain corresponding to the application to which the target function belongs;

[0269] 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.

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

[0271] Obtaining a function index corresponding to the objective function;

[0272] When the target function is an external function of the target application to which the target bytecode belongs, checking the validity of the function index according to the import segment of the target module to which the target bytecode belongs and the export segment in the calling module to which the target function belongs;

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

[0274] If so, the validity check of the function call is confirmed to have passed.

[0275] Based on the above embodiments, the function call legality checking unit can be further used to:

[0276] When it is determined that the function index does not exceed the number of functions imported by the import segment in the target module, and the function index appears in the import segment in the calling module, it is determined that the function index is valid.

[0277] On the basis of the above embodiments, the present invention may further include: a fourth operation domain switching module, which is used to:

[0278] After the function call legality check passes and the target bytecode is executed, the bytecode corresponding to the target function begins to be executed in the target logical channel;

[0279] After the execution of the bytecode corresponding to the target function is completed, the current virtual machine running domain of the target logical channel is restored to the virtual machine running domain corresponding to the target bytecode.

[0280] Based on the above embodiments, the present invention may further include: a variable stack space checking unit, which is used to:

[0281] In the target logic channel, after starting to execute the bytecode corresponding to the target function, during the execution of the bytecode corresponding to the target function, if it is necessary to access data at a set storage location, detecting whether the set storage location is located within a range of an indirect access variable stack space matching the target function;

[0282] If so, the target function is allowed to access the data at the set storage location; otherwise, the target function is prohibited from accessing the data at the set storage location.

[0283] Based on the above embodiments, the legality checking module 620 specifically includes:

[0284] When it is determined that the instruction type is a variable operation instruction in the process of setting the calling function execution, obtaining a local variable index in the variable operation instruction;

[0285] By querying the current function stack frame in the virtual machine stack, the local variable index is checked for legality.

[0286] Based on the above embodiments, the legality checking module 620 specifically includes:

[0287] When it is determined that the instruction type is a conditional jump instruction in a control instruction, obtaining a jump offset in the conditional jump instruction;

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

[0289] The jump offset is checked for legitimacy according to the target bytecode address and the function range information.

[0290] The secure access device provided in the embodiment 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 the execution method.

[0291] In the technical solution of the present disclosure, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

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

[0293] like Figure 7 As shown, the electronic device 10 includes at least one processor 11, and a memory connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 to the random access memory (RAM) 13. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12, and the RAM 13 are connected to each other through a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0294] The electronic device may be a resource-constrained device. A resource-constrained device may be understood as an electronic device with limited storage capacity, and its RAM resources are limited, generally a few KB to tens of KB, and its NVM (non-volatile memory) resources are limited. Figure 7 Taking ROM as an example) it is tens of KB to hundreds of KB, and the maximum is MB level.

[0295] The resource-constrained device may generally be: a smart card, a USBKEY, an ESAM (Embedded Secure Access Module), an IoT device or a SE (Secure Element), etc. The smart card may generally be a multi-application smart card.

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

[0297] The processor 11 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The processor 11 executes the various methods and processes described above, for example, executing a secure access method as described in various embodiments of the present invention, which is executed by a virtual machine, an operating system is installed on the electronic device, and a virtual machine is executed in the operating system, and the method includes:

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

[0299] According to the instruction type, obtaining a matching operand, and according to the operand, performing a security access legality check matching the instruction type;

[0300] After the security access legality check passes, the target bytecode is executed.

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

[0302] Various implementations 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 chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0303] Computer programs for implementing 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, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0304] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0305] Figure 8 is a structural diagram of a terminal provided according to an embodiment of the present invention. Figure 8 Said terminal comprises the electronic device 810 as described in any embodiment of the present invention.

[0306] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

Claims

1. A secure access method, It is characterized in that Executed by the virtual machine, including: Parsing the target bytecode to determine the instruction type of the target bytecode; the target bytecode includes: the bytecode in the application module, the bytecode in the application program or the bytecode in the library module; According to the instruction type, obtaining a matching operand, and according to the operand, performing a security access legality check matching the instruction type; After the security and legality check is passed, the target bytecode is executed; when the security and legality check is not passed, the execution of the target bytecode is prohibited, and an exception prompt is given.

2. The method according to claim 1, It is characterized in that Parse the target bytecode, including: Parsing target bytecodes in a target application currently running in a target logical channel; wherein the target application is obtained by installing a target application module, or; Parse the target bytecode in the target library module currently being executed in the target logical channel.

3. The method according to claim 2, It is characterized in that According to the instruction type, a matching operand is obtained, and according to the operand, a security access legality check matching the instruction type is performed, including: 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; wherein the target module includes: a target application module or a target library module; Perform memory access legality check based on the attribute information and the target module to which the target bytecode belongs.

4. The method according to claim 3, It is characterized in that According to the attribute information and the target module to which the target bytecode belongs, perform memory access legitimacy checks, including: Determine the data type of the target memory data according to the attribute information; According to the data type, the access module to which the target memory data belongs, and the target module, a memory access legality check is performed.

5. The method according to claim 4, It is characterized in that Determine the data type of the target memory data based on the attribute information, including: If the attribute information is a memory offset, determining a starting memory address according to the target module; The data type of the target memory data is determined according to the memory offset, the starting memory address and a preset memory space management method.

6. The method according to claim 1 or 2, It is characterized in that According to the instruction type, a matching operand is obtained, and according to the operand, a security access legality check matching the instruction type is performed, including: When it is determined that the instruction type is an instruction for pushing or popping an operand on a 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.

7. The method according to claim 2, It is characterized in that According to the instruction type, a matching operand is obtained, and according to the operand, a security access legality check matching the instruction type is performed, including: When it is determined that the instruction type is a function call instruction for a target function, obtaining a function index of the target function and the number of parameters passed in by the target bytecode; A function call legality check is performed according to the function index of the target function and the number of parameters passed in by the target bytecode.

8. The method according to claim 7, It is characterized in that According to the function index of the target function and the number of parameters passed in by the target bytecode, a legality check of the function call is performed, including: Obtaining a function index corresponding to the objective function; When the target function is an external function of the target application to which the target bytecode belongs, checking the validity of the function index according to the import segment of the target module to which the target bytecode belongs and the export segment in the calling module to which the target function belongs; If it is determined that the function index is valid, then continue to check whether the number of parameters passed in by the target bytecode is consistent with the number of function parameters defined by the code segment in the calling module; If so, the validity check of the function call is confirmed to have passed.

9. The method according to claim 1 or 2, It is characterized in that According to the instruction type, a matching operand is obtained, and according to the operand, a security access legality check matching the instruction type is performed, including: When it is determined that the instruction type is a variable operation instruction in the process of setting the calling function execution, obtaining a local variable index in the variable operation instruction; By querying the current function stack frame in the virtual machine stack, the local variable index is checked for legality.

10. The method according to claim 1 or 2, It is characterized in that According to the instruction type, a matching operand is obtained, and according to the operand, a security access legality check matching the instruction type is performed, including: When it is determined that the instruction type is a conditional jump instruction in a control instruction, obtaining a jump offset in the conditional jump instruction; In the target module to which the target bytecode belongs, obtaining function range information corresponding to the function to which the target bytecode belongs; The jump offset is checked for legitimacy according to the target bytecode address and the function range information.

Images