Authorization table maintenance and interface calling method and device, equipment, terminal and medium

Abstract

The invention discloses an interface authorization table maintenance method and device, an application interface authorization calling method and device, equipment, a terminal, a medium and a product. The interface authorization table maintenance method comprises the steps that if it is determined that an applicant code successfully applies for interface calling authorization for an applicant in the execution process, first authorization information between the applicant and the applicant is constructed; and writing the first authorization information in a target interface authorization table in the target logic channel. According to the technical scheme provided by the embodiment of the invention, most functions of processing interface authorization calling are handed over to a runtime environment to be quickly completed, so that an application layer processes calling and authorization related logic as less as possible. According to the method, the operation performance of the application program is considered, meanwhile, an application developer completes authorized calling of the application interface in a non-inductive mode, the development convenience of the application program is improved, the programming workload of the application developer is reduced to the maximum extent, and meanwhile authorized calling of the application interface is completed in a high-performance mode.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to an interface authorization table maintenance method, an application interface authorization calling method and device, equipment, terminal, medium and product. BACKGROUND

[0002] In the field of application program management technology in embedded operating system, in addition to providing runtime environment and data access capability for application program, the operating system can also provide legal program code sharing calling mechanism for application program running, so as to fully utilize the public code resources of application program and the sharable data resources between application programs.

[0003] The mechanism of calling interface code and accessing data of other application programs by the running application program is usually called shared interface calling. For different programming languages, the shared interface is different. For object-oriented programming method, safe shared object can be realized, and for process-oriented or function-oriented programming method, interface calling authorization management can be realized, so that the running application program can safely access the data and interface code of other application programs.

[0004] The inventor found that in the process of implementing the present application, the existing implementation methods of various shared interfaces need to consume certain application data storage space to record authorization information, or cannot authorize calling when the application is not installed, or need to establish authorization record information in advance, or the shared interface needs to define interface parameter table by using a specific model. These restrictions bring a certain degree of programming trouble to application developers and affect the running performance of the application program. In addition, the running of the application program is supported by the runtime environment of the embedded operating system, and the running of the application program is completed by the virtual machine interpreting bytecode and cooperating with the runtime environment function. Since the bytecode interpretation performance is not high, it is undoubtedly that the application program running performance will be poor if the authorization interface calling is realized by using a too complex method in the application program. SUMMARY

[0005] The present application provides an interface authorization table maintenance method, an application interface authorization calling method and device, equipment, terminal, medium and product, which can reduce the programming workload of application developers and complete the authorization calling of application interface with high performance.

[0006] According to an aspect of an embodiment of the present application, an interface authorization table maintenance method is provided, which is executed by a runtime environment in an embedded operating system installed in a restricted device, and the method comprises:

[0007] If it is determined that the applicant code successfully applies for the interface calling authorization of the applicant during the execution process, the first authorization information between the applicant and the applicant is constructed.

[0008] write the first authorization information into a target interface authorization table in the target logical channel, wherein the applicant code executes in the target logical channel.

[0009] According to another aspect of the embodiments of the present application, there is also provided an application interface authorization calling method, executed by a runtime environment in an embedded operating system installed in a restricted device, comprising:

[0010] If it is determined that the caller code invokes the target interface code of the callee in the execution process, the target interface authorization table in the target logical channel is queried, wherein the target interface authorization table is maintained by the method according to any one of the embodiments of the present application;

[0011] If it is determined that the second authorization information corresponding to the caller and the callee is stored in the target interface authorization table, the target interface code of the callee is executed in the target logical channel to obtain the interface calling result, wherein the caller code executes in the target logical channel.

[0012] According to another aspect of the embodiments of the present application, there is also provided an interface authorization table maintenance device, configured in a runtime environment in an embedded operating system installed in a restricted device, comprising:

[0013] The authorization information construction module is configured to, if it is determined that the applicant code successfully applies for the interface calling authorization of the applicant in the execution process, construct the first authorization information between the applicant and the applicant.

[0014] The authorization information writing module is configured to write the first authorization information into a target interface authorization table in the target logical channel, wherein the applicant code executes in the target logical channel.

[0015] According to another aspect of the embodiments of the present application, there is also provided an application interface authorization calling device, configured in a runtime environment in an embedded operating system installed in a restricted device, comprising:

[0016] The interface authorization table querying module is configured to, if it is determined that the caller code invokes the target interface code of the callee in the execution process, query the target interface authorization table in the target logical channel, wherein the target interface authorization table is maintained by the method according to any one of the embodiments of the present application.

[0017] The interface code calling module is configured to, if it is determined that the second authorization information corresponding to the caller and the callee is stored in the target interface authorization table, execute the target interface code of the callee in the target logical channel to obtain the interface calling result, wherein the caller code executes in the target logical channel.

[0018] According to another aspect of the present invention, a restricted device is also provided, wherein an embedded operating system is installed on the restricted device, and a runtime environment is executed in the embedded operating system, and the restricted device includes:

[0019] At least one processor; and

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

[0021] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the interface authorization table maintenance method as described in any one of the embodiments of the present invention, or to perform the application interface authorization call method as described in any one of the embodiments of the present invention.

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

[0023] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing computer instructions, the computer instructions being configured to cause a processor to execute and implement, as described in any one embodiment of the present invention, a method for maintaining an interface authorization table, or a method for authorizing the invocation of an application interface, as described in any one embodiment of the present invention.

[0024] According to another aspect of the present invention, a computer program product is also provided, the computer program product including a computer program, which, when executed by a processor, implements the method for maintaining an interface authorization table according to any one of the embodiments of the present invention, or implements the method for authorizing the invocation of an application interface according to any one of the embodiments of the present invention.

[0025] The technical solution of this invention provides an application interface authorization management method that establishes an authorization table in the runtime environment. By writing authorization information between the applicant and the applicant into the interface authorization table within the target logic channel executing the applicant's code, and implementing application interface authorization calls based on this authorization information, the method delegates most of the functionality for handling interface authorization calls to the runtime environment for rapid completion, minimizing the application layer's handling of call and authorization-related logic. While maintaining application performance, it allows application developers to seamlessly complete application interface authorization calls, improving application development convenience and achieving high-performance application interface authorization calls while minimizing the programming workload for application developers.

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

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

[0028] Figure 1 This is a flowchart of a method for maintaining an interface authorization table according to an embodiment of the present invention;

[0029] Figure 2 This is a flowchart of another method for maintaining an interface authorization table according to an embodiment of the present invention;

[0030] Figure 3 This is a flowchart of another method for maintaining an interface authorization table according to an embodiment of the present invention;

[0031] Figure 4 This is a flowchart of an authorized invocation method for an application interface provided according to an embodiment of the present invention;

[0032] Figure 5 This is a flowchart of another authorized invocation method for an application interface provided according to an embodiment of the present invention;

[0033] Figure 6 This is a three-party interaction diagram that integrates the complete process of application for authorization and invocation method applicable to embodiments of the present invention;

[0034] Figure 7 This is a structural diagram of an interface authorization table maintenance device provided according to an embodiment of the present invention;

[0035] Figure 8 This is a structural diagram of an application interface authorization invocation device provided according to an embodiment of the present invention;

[0036] Figure 9 This is a structural diagram of a restricted device provided according to an embodiment of the present invention;

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

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

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

[0040] Figure 1 This is a flowchart of an interface authorization table maintenance method provided by an embodiment of the present invention. This embodiment is applicable to situations where an interface authorization table for application interface authorization management is established by the runtime environment in an embedded operating system. The method can be executed by an interface authorization table maintenance device, which can be implemented in hardware and / or software and is generally configured in a restricted device (e.g., various security elements or smart cards) with an embedded operating system installed.

[0041] The method in this embodiment is executed by a runtime environment within the embedded operating system. A runtime environment (RTE, Real-Time Enterprise) is a secure runtime environment that executes virtual machines on constrained resources such as smart cards or secure elements; it can be considered a lightweight container. Applications run within this runtime environment, thus achieving complete isolation from the native functions of the embedded operating system.

[0042] Correspondingly, such as Figure 1 As shown, the method includes:

[0043] S110. If it is determined that the applicant's code successfully obtained authorization to call the interface of the applicant during the execution process, then construct the first authorization information between the applicant and the applicant.

[0044] As mentioned earlier, in constrained devices, each application runs within a runtime environment. Specifically, each triggered and activated application runs independently within a logical channel. Each logical channel provides a secure and independent runtime environment and data access capabilities for the running application. The runtime environment uniformly manages these one or more logical channels.

[0045] The runtime environment can choose to activate and run application A within a logical channel. If an activated application B already exists within that logical channel, application B must first be deactivated before application A can be activated and run within the logical channel. In other words, only one application can be running within the same logical channel at any given time.

[0046] In this embodiment, the applicant's code can be understood as program code belonging to the applicant that executes in the designated logical channel (i.e., the target logical channel). The applicant can be understood as an application requesting to call the designated application interface belonging to the respondent.

[0047] The applicant includes an application that is running within the target logical channel. In a specific example, the applicant can be an application that is running after being activated within the target logical channel.

[0048] In another specific example, after application A is activated and running within the target logical channel, if it successfully calls the application interface code of application B during its execution, application B will be in a running state within the target logical channel, while application A will be in a suspended state. Furthermore, when the application interface code of application B executing in the target logical channel needs to request a call to the application interface code of application C, application B's role at this time is that of the requester, and its application interface code is the requester code.

[0049] It is important to emphasize here that when application A selects to authorize the call of application B, which is in a running state within the target logical channel, application A does not directly switch to a non-running state. This is because application A is the application that is activated within the logical channel, and it is not deactivated by calling other applications. Therefore, application A will be set to an application suspended state. When application B completes the call, application A will switch back from the application suspended state to the running state.

[0050] In this embodiment, the applicant includes an instantiated application or an uninstantiated application module. An instantiated application can be understood as an application that is downloaded to a restricted device and installed within that runtime environment, while an uninstantiated application module can be understood as an application installation package downloaded to a restricted device but not yet installed.

[0051] In this embodiment, the applicant code can request to call interface code in installed applications, and also to call interface code in downloaded but not yet installed application modules. Furthermore, it should be emphasized again that the applicant code can be code from the currently active application in the target logical channel, or code from instantiated applications or uninstantiated application modules that are directly or indirectly authorized for calling by the currently active application.

[0052] Furthermore, the application that is running within the target logical channel can be called a client application, while the application that provides the shared interface code can be called a server application. The server application can be in a running or non-running state before it is authorized to be called.

[0053] In this embodiment, when the applicant code successfully obtains authorization for the application interface code in the applicant's code for the first time, it is determined that the applicant code has successfully obtained authorization to call the interface of the applicant during execution. The reason for emphasizing "first time" is that authorization requests that are not the first time can be directly approved without requesting authorization from the same applicant again.

[0054] Authorization information can be understood as descriptive information granted by the applicant to the respondent for an interface. This authorization information can be a two-dimensional structured data, which explicitly contains the applicant and the respondent. For example, it may contain information about the running application (typically an application identifier) ​​and the information about the invoked application. The first authorization information can be understood as descriptive information granted by a specific applicant to a specific respondent for an interface.

[0055] S120. Write the first authorization information into the target interface authorization table within the target logical channel.

[0056] In this embodiment, an interface authorization table is maintained for each logical channel, and the authorization table is used to store one or more authorization information.

[0057] After the first authorization information is created in the runtime environment, it can be written into the target interface authorization table in the target logical channel.

[0058] Furthermore, when the application currently running in the target logical channel needs to call the application interface of other applications, it can directly query the target interface authorization table to determine whether the application interface code of other applications can be run in the target logical channel.

[0059] In this embodiment, the runtime environment avoids consuming application data storage space by using an interface authorization table to manage the authorization information of the interface.

[0060] The technical solution of this invention provides an application interface authorization management method that establishes an authorization table in the runtime environment. By writing authorization information between the applicant and the applicant into the interface authorization table within the target logic channel executing the applicant's code, and implementing application interface authorization calls based on this authorization information, most of the functionality for handling interface authorization calls can be quickly completed by the runtime environment, minimizing the application layer's handling of call and authorization-related logic. While maintaining application performance, this method allows application developers to seamlessly complete application interface authorization calls, improving application development convenience and achieving high-performance application interface authorization calls while minimizing the programming workload for application developers.

[0061] Figure 2 This is a flowchart illustrating another method for maintaining an interface authorization table according to an embodiment of the present invention. This embodiment is a refinement based on the above embodiments. In this embodiment, the authorization revoke process of the interface authorization table is further defined. Accordingly, as... Figure 2 As shown, the method includes:

[0062] S210. If it is determined that the applicant's code successfully obtained authorization to call the interface of the applicant during the execution process, then construct the first authorization information between the applicant and the applicant.

[0063] S220. Write the first authorization information into the target interface authorization table within the target logical channel.

[0064] S230. When the target application selected and activated within the target logical channel switches from running state to non-running state, the authorization information of the target application as the applicant is cleared from the target interface authorization table.

[0065] In this embodiment, when the target application activated within the target logical channel is changed from a running state to a non-running state by the runtime environment, it indicates that the target application has been deselected within the target logical channel, meaning that a new application may need to be activated within the target logical channel. Since the target interface authorization table corresponds one-to-one with the target logical channel (or can be understood as mutually bound), and the target application is applying to call other application interfaces as a client application, it is necessary to delete the authorization information with the target application as the applicant from the target interface authorization table.

[0066] Specifically, the runtime environment needs to query the target interface authorization table corresponding to the target logical channel to see if there is any authorization information with the target application as the applicant. If so, all the authorization information found is cleared.

[0067] S240. When the embedded operating system restarts after a power failure, or the runtime environment is reset after a power failure, clear all authorization information in the interface authorization table of each logical channel managed by the runtime environment.

[0068] When the embedded operating system loses power and then restarts, all applications are not running. At this time, the authorization information in the interface authorization tables corresponding to all logical channels must be cleared. Similarly, when the runtime environment loses power and is reset, all logical channels also need to be reset, and the authorization information in the interface authorization tables corresponding to all logical channels must be cleared.

[0069] S250. When determining that a failed application has been deleted from the embedded operating system, the authorization information for the failed application as the applicant is cleared from the interface authorization table in each logical channel managed by the runtime environment.

[0070] Understandably, besides installing applications in the embedded operating system, applications can also be deleted. Within the same logical channel, the application of the requester role is running, while the application of the requestee role is not running. On other logical channels managed by the runtime environment, the application of the requestee role may be deleted. When it is deleted as a failed application, the runtime environment queries the interface authorization tables of all current logical channels to see if there is any authorization information with that failed application as the requestee. If it exists, all found authorization information is cleared.

[0071] The technical solution of this invention provides an application interface authorization management method for establishing an authorization table in the runtime environment, while further providing a variety of typical scenarios involving authorization revocation, clearly defining the effective scope of authorization, and ensuring the security and timeliness of authorization.

[0072] Based on the above embodiments, before writing the first authorization information into the target interface authorization table within the target logical channel, the following may also be included:

[0073] Clear any other currently stored authorization information from the target interface authorization table.

[0074] In this optional implementation, it can be further defined that when a client application within a logical channel needs to request authorization from multiple server applications in a business process, the request can only be made in queue order. Only one server application's authorization status is recorded by the runtime environment within the same logical channel. That is, if a client application has requested interface authorization from server application A, and then needs to request authorization from server application B, the authorization information in the interface authorization table with server application A as the requestee must first be cleared.

[0075] Figure 3 This is a flowchart illustrating another method for maintaining an interface authorization table provided in this embodiment of the invention. This embodiment is a refinement based on the above embodiments. In this embodiment, the process by which the applicant requests an interface call authorization from the respondent is further defined. Accordingly, as... Figure 3 As shown, the method includes:

[0076] S310. When the applicant code initiates an authorization request for calling the interface of the applicant, check whether the authorization information between the applicant and the applicant is stored in the target interface authorization table: if not, execute S320; if yes, execute S380.

[0077] In this embodiment, the interface call authorization request is generated by the applicant based on the respondent's identifier and the request parameters by calling the authorization request interface provided by the runtime environment.

[0078] The authorization request is handled by the client application calling the authorization request interface provided by the runtime environment. This interface, defined and implemented by the runtime environment, is provided to application developers when they need to obtain authorization from the server application. In a specific example, the function definition could be: "boolean GetSccLibInterface(AIDaid, u8 param)". `aid` represents the recipient, or the application identifier of the server application, and `param` represents the requested parameters. After authorization is granted, the program code in the client application module can call the server application module's interface across modules.

[0079] In this embodiment, the runtime environment can obtain the target interface authorization table bound to the target logic channel in the target logic channel that executes the applicant's code, and first check whether the target interface authorization table stores the authorization information between the applicant and the applicant based on the applied identifier.

[0080] If the authorization information between the applicant and the respondent is already stored in the target interface authorization table, there is no need to submit an application interface authorization request to the respondent again. The interface call authorization result can be returned directly to the applicant's code, where the interface call authorization result is used to describe the successful application for authorization.

[0081] S320. Determine whether the respondent is an instantiated application or an uninstantiated application module: If it is an instantiated application, execute S330; if it is an uninstantiated application module, execute S340.

[0082] If the target interface authorization table does not store authorization information between the applicant and the applicant, it can be further determined whether the applicant is an instantiated application that has been installed in the embedded operating system or a downloaded but not installed, uninstantiated application module.

[0083] Of course, there may also be cases where the applicant's identifier cannot be found in the embedded operating system. In this case, the interface call failure result can be directly reported to the applicant's code.

[0084] S330. Execute the applicant's authorization detection code within the target logic channel, obtain the execution result, and execute S350.

[0085] When determining that the respondent is an instantiated application, the respondent's authorization detection code needs to be executed within the target logical channel. Specifically, this authorization detection code can be executed by calling the authorization check interface provided by the respondent application within the target logical channel. Optionally, the execution result includes: confirming interface authorization or denying interface authorization.

[0086] In an optional implementation of this embodiment, executing the applicant's authorization detection code within the target logical channel and obtaining the execution result may include:

[0087] S3301. Switch the first operating domain currently used by the target logical channel to the second operating domain corresponding to the applicant.

[0088] Since the applicant's authorization detection code needs to be executed within the target logical channel, it is necessary to first suspend the applicant's code to switch the currently executing application within the target logical channel from the applicant to the applicant. After suspending the applicant's code, the first execution domain currently used by the target logical channel needs to be switched to the second execution domain corresponding to the applicant.

[0089] The runtime domain refers to the virtual machine runtime domain, which is a virtual memory space constructed by the runtime environment for the scope of data accessible to applications. It records information such as application identifiers and logical channels. Corresponding to each logical channel, there is one and only one running application bound to the virtual machine runtime domain on that channel. On each logical channel, the activated application should have a virtual machine runtime domain allocated by the RTE.

[0090] When calling the interface of the application module's module assembly, which is a server-side authorization interface, the RTE should switch the module assembly, module dataset, and application dataset in the virtual machine runtime domain to the server-side module assembly, module dataset, and application dataset.

[0091] In an optional implementation of this embodiment, switching the first operating domain currently used by the target logical channel to the second operating domain corresponding to the applicant may include:

[0092] The associated data of the first operating domain is temporarily stored; after switching the first operating domain currently used by the target logical channel to the second operating domain corresponding to the applicant, the dataset and program assembly corresponding to the applicant are established in the second operating domain.

[0093] The runtime domain-related data within the first runtime domain may include: application datasets and assemblies related to the applicant's application, various global variables, and intermediate calculation results. In other words, the current runtime state of the applicant's code is saved for subsequent processing.

[0094] S3302. Based on the applicant's identifier and the application parameters in the authorization application, call the authorization check interface of the applicant within the target logical channel and obtain the interface return result.

[0095] The authorization detection interface is used to execute the program logic code defined in the interface based on the applicant's application identifier and application parameters to determine whether to authorize the applicant and to return the corresponding execution result.

[0096] S3303. Re-switch the first running domain as the running domain currently used by the target logical channel.

[0097] Once the runtime environment receives the execution result returned by the respondent application, it can update the currently running application from the respondent application back to the applicant application and switch the currently running runtime domain to the applicant application's runtime domain.

[0098] Furthermore, after switching the first operating domain back to the operating domain currently used by the target logical channel, it may also include:

[0099] Rewrite the runtime domain association data in the temporarily stored first runtime domain back into the first runtime domain; reclaim the second runtime domain, as well as the datasets and assemblies created for the applicant.

[0100] S340. Confirm that the applicant code has successfully obtained authorization to call the interface of the applicant, and execute S370.

[0101] S350. Determine whether the execution result is to confirm or deny the interface authorization: If it is to confirm the interface authorization, then execute S360; if it is to deny the interface authorization, then execute S390.

[0102] S360, Establish the first authorization information between the applicant and the respondent, and execute S370.

[0103] S370. Write the first authorization information into the target interface authorization table within the target logical channel, and execute S380.

[0104] Specifically, the first authorization information can be established based on the applicant's identifier and the respondent's identifier.

[0105] S380. Generate the interface call authorization result and feed it back to the applicant code executing in the target logic channel, so that the applicant code can execute the subsequent interface call code to the applicant based on the interface call authorization result.

[0106] S390: The failure result of the generated interface call is fed back to the applicant code executing in the target logic channel.

[0107] The interface authorization method based on the interface authorization table provided in this embodiment of the invention can complete the management logic of interface authorization calls in the runtime environment, thereby improving the performance of interface calls. In addition, the method of managing the authorization information of the interface using the interface authorization table in the runtime environment avoids consuming the data storage space of the application.

[0108] Figure 4 This is a flowchart of an application interface authorization call method provided in an embodiment of the present invention. This embodiment is applicable to situations where the runtime environment in an embedded operating system controls the running application code to call the interface code of other applications. The method can be executed by an application interface authorization call device, which can be implemented in hardware and / or software and is generally configured in a restricted device (e.g., various security elements or smart cards) with an embedded operating system installed.

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

[0110] S410. If it is determined that the caller code calls the target interface code of the callee during execution, then query the target interface authorization table in the target logical channel.

[0111] The target interface authorization table is maintained using the interface authorization table maintenance method described in any embodiment of the present invention, wherein the caller code is executed in the target logical channel.

[0112] Specifically, the caller code is the program code currently running in the target logic channel and belonging to the caller.

[0113] The caller can be an application activated in the target logical channel, or it can be the program code in an instantiated application or an uninstantiated application module that is authorized to be called during the operation of an application activated in the target logical channel.

[0114] The target interface authorization table contains authorization information for those who successfully applied for interface authorization, including the applicant's identifier and the identifier of the applicant.

[0115] Correspondingly, if the caller code needs to call the target interface code of the callee during execution, it needs to first obtain the caller identifier and the callee identifier, and check whether there is any authorization information in the target interface authorization table with the caller identifier as the applicant identifier and the callee identifier as the applicant identifier.

[0116] S420. If it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee, then execute the target interface code of the callee in the target logical channel to obtain the interface call result.

[0117] When the target interface code of the callee is executed within the target logical channel, the caller code is suspended. That is, at any given time, only one application or application module's program code is running within the target logical channel.

[0118] In this embodiment, if it is determined that the target interface authorization table does not store the second authorization information corresponding to the caller and the callee, the call to the target interface code of the callee will be directly rejected.

[0119] In this embodiment, since the caller code is suspended when obtaining the interface call result, it is necessary to switch the caller code from the suspended state back to the running state after obtaining the interface call result in the runtime environment. Accordingly, the method may further include:

[0120] The API call result is fed back to the caller code executing in the target logic channel, so that the caller code can continue execution based on the API call result.

[0121] The technical solution of this invention determines whether the target interface code of the caller can be executed within the target logical channel when it is determined that the caller code needs to call the target interface code of the callee during execution. This is achieved by querying the target interface authorization table in the target logical channel to see if the authorization information corresponding to the caller and the callee is stored. This allows most of the functions of handling interface authorization calls to be quickly completed by the runtime environment, so that the application layer handles as little call and authorization-related logic as possible. In addition, the above implementation does not require adding special definitions and identifiers to the application interfaces called by the running application code, which avoids a lot of programming trouble in the application development process.

[0122] Figure 5 This is a flowchart of another application interface authorization call method provided by an embodiment of the present invention. This embodiment is based on the above embodiments and is a refinement. In this embodiment, the operation of "executing the target interface code of the callee in the target logic channel and obtaining the interface call result" is specified.

[0123] Correspondingly, such as Figure 5 The method may specifically include:

[0124] S510. If it is determined that the caller code calls the target interface code of the callee during execution, then query the target interface authorization table in the target logical channel.

[0125] S520. If it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee, then the third running domain currently used by the target logical channel is switched to the fourth running domain corresponding to the callee.

[0126] Switching the target logic channel's currently used third execution domain to the fourth execution domain corresponding to the callee can include:

[0127] Temporarily store the operation domain-related data within the third operation domain;

[0128] After switching the third execution domain currently used by the target logic channel to the fourth execution domain corresponding to the callee, a dataset and program assembly corresponding to the callee are established in the fourth execution domain.

[0129] S530. Execute the target interface code of the callee within the target logic channel and obtain the interface call result.

[0130] S540. Re-switch the third operating domain as the operating domain currently used by the target logical channel.

[0131] This may further include, after switching the third operating domain back to be the operating domain currently used by the target logical channel:

[0132] Rewrite the runtime domain-related data temporarily stored in the third runtime domain back into the third runtime domain; reclaim the fourth runtime domain, as well as the datasets and assemblies created for the callee.

[0133] S550. Feedback the interface call result to the caller code executing in the target logic channel, so that the caller code can continue to execute according to the interface call result.

[0134] The technical solution of this invention determines whether the target interface code of the caller can be executed within the target logical channel when it is determined that the caller code needs to call the target interface code of the callee during execution. This is achieved by querying the target interface authorization table in the target logical channel to see if the authorization information corresponding to the caller and the callee is stored. This allows most of the functions of handling interface authorization calls to be quickly completed by the runtime environment, so that the application layer handles as little call and authorization-related logic as possible. In addition, the above implementation does not require adding special definitions and identifiers to the application interfaces called by the running application code, which avoids a lot of programming trouble in the application development process.

[0135] In this embodiment, to ensure data security during interface calls, data access under authorized conditions is further restricted. Specifically, when a running application accesses global variables, it needs to check whether the accessed global variable belongs to the current runtime domain, and access to data outside the runtime domain's access policy is not allowed.

[0136] Accordingly, in an optional implementation of this embodiment, executing the target interface code of the callee within the target logic channel and obtaining the interface call result may further include:

[0137] During the execution of the callee's target interface code within the target logical channel, if it is necessary to access the first application data belonging to the caller, it is checked whether the execution domain currently used by the target logical channel conflicts with the first application data.

[0138] If not, then access to the first application data is performed within the operating domain currently used by the target logical channel; if yes, then when it is determined that the first application data is cross-operating domain access data, access to the first application data is performed within the operating domain currently used by the target logical channel.

[0139] In this embodiment, to ensure data security, the data access method under authorized status is also limited. That is, if the target interface code of the callee needs to access the caller's first application data during the execution of the target logical channel, it is necessary to first check whether the currently used execution domain conflicts with the first application data. For example, if the first application data is a global variable, it is checked whether the global variable belongs to the currently used execution domain. If it does, it is determined that the execution domain currently used by the target logical channel does not conflict with the first application data; if it does not, it is determined that the execution domain currently used by the target logical channel conflicts with the first application data.

[0140] If there is no conflict, the first application data can be accessed directly within the current runtime domain. If there is a conflict, it is necessary to check whether the first application data is cross-runtime domain access data. Cross-runtime domain access data can be understood as application data that can be accessed across runtime domains. Specifically, this can be identified by adding attribute identifiers to the application data.

[0141] Specifically, when the first application data is cross-runtime domain access data, it can be accessed directly within the current runtime domain. When the first application data is not cross-runtime domain access data, the runtime environment can abnormally exit the continued execution of the target interface code of the callee. Furthermore, feeding back the interface call result to the caller code executing in the target logic channel may also include:

[0142] When the interface call result contains second application data belonging to the callee, check whether the running domain currently used by the target logical channel conflicts with the second application data;

[0143] If not, the result of the interface call will be fed back to the caller code that is executing in the target logic channel;

[0144] If so, when it is determined that the second application data is cross-domain access data, the interface call result will be fed back to the caller code executing in the target logical channel.

[0145] By implementing the above settings, data security during application API calls can be guaranteed to the greatest extent possible, preventing application data leaks.

[0146] Specific application scenarios

[0147] To further describe the technical solutions of the various embodiments of the present invention, in Figure 6 The diagram illustrates a three-party interaction diagram that integrates the complete process of requesting authorization and invoking methods, applicable to embodiments of the present invention.

[0148] like Figure 6As shown, application A, app A, and A all refer to application A, while application B and app B both refer to application B. The runtime environment refers to the runtime environment. Method Fun1 can be understood as the application interface settings within application B.

[0149] Specifically, to facilitate application development and enable application developers to seamlessly complete interface authorization calls while maintaining application performance, this invention designs an interface authorization management method that establishes an interface authorization table in the runtime environment. This method delegates most of the functionality for handling interface authorization calls to the runtime environment for rapid completion, minimizing the application layer's handling of call and authorization-related logic. Consequently, when a running application calls the authorization interface code of other applications, the runtime environment automatically switches the runtime domain (including the dataset and assembly required for running the application), enabling high-performance completion of interface authorization calls.

[0150] The interface authorization table records authorization information for successfully requested interfaces. This table is designed with a two-dimensional structure, divided into multiple tables based on the number of logical channels supported by the runtime environment. Authorization information is recorded in the corresponding table for each logical channel. Initially, the table is empty. Information is recorded as running applications request interfaces from the runtime environment, and cleared when the runtime environment cancels the currently running application. Each authorization record includes information about the running application and the called application, with a one-to-one correspondence between the caller and callee information. Once information is successfully recorded in the interface authorization table, it remains valid throughout the runtime of the caller application. If the caller application is no longer running, its interface authorization information is cleared from the table.

[0151] The interface authorization application process is the process by which a calling application requests authorization to call the interfaces of other applications through the runtime environment. The key output of this process is to determine the authorization information and record this information in the interface authorization table.

[0152] During the API call, the runtime environment needs to check if authorization information exists in the API authorization table; if not, the call will fail.

[0153] Authorization revocation process: When the caller application is no longer running, the runtime environment automatically clears the authorization information in the interface authorization table.

[0154] Data access under authorized status: When a running application accesses a global variable, it checks whether the global variable belongs to the current running domain and does not allow access to data outside the running domain's access policy.

[0155] Specifically, such as Figure 6 As shown, the interface authorization call method designed above needs to be explained in the following parts:

[0156] (I) Applying for API call authorization

[0157] Requesting authorization to call an API is a process initiated by the currently running application. It requests authorization from the callee application by calling a dedicated interface provided by the runtime environment. The process is as follows:

[0158] 1. The currently running application calls the authorization request interface provided by the runtime environment to initiate an application to the respondent application.

[0159] 2. The runtime environment checks the callee identifier and request parameters. If the called application does not exist, it checks whether the callee identifier is the module identifier of the application. If neither is true, the request fails. Otherwise, it queries the interface authorization table to see if the authorization record of the currently running application and the callee is recorded. If the authorization information already exists, it directly returns that the authorization request was successful. If the authorization information does not exist, it proceeds to the next step.

[0160] 3. If the respondent is an application module, establish authorization information using the applicant's application ID and the respondent's ID (application ID or module ID), and write this authorization information to the interface authorization table. Otherwise, the runtime environment switches the runtime domain (application dataset and assembly) of the currently running application to the respondent application's runtime domain, and changes the currently running application to the respondent application. Create global variables, application data, and other datasets and assemblies for application B.

[0161] 4. The runtime environment calls the authorization check interface of the applicant application to check the identifier and parameters of the applicant application, determines whether to authorize based on the program logic of the interface, and returns the check result.

[0162] 5. After the runtime environment receives the result returned by the applicant application, it changes the currently running application to the applicant application, switches the currently running runtime domain to the applicant application's runtime domain, and then proceeds to the next step.

[0163] 6. Establish authorization information using the applicant's application ID and the respondent's ID (application ID or module ID), and write this authorization information into the interface authorization table.

[0164] 7. Return the API call authorization result to the applicant. The applicant's application executes subsequent program code based on the application result.

[0165] (II) Interface Call

[0166] When an application calls any interface code during runtime, there are two types of interface code: one is the application's own interface code, and the other is the interface code of other applications. Since only the application itself is currently running, and other applications or modules are not running, and related global variables, constants, and application data have not been allocated, when calling the interface of the requested application, the runtime environment needs to seamlessly complete the runtime domain settings required for the program code to run. The process is as follows:

[0167] 1. Application A calls and runs the interface code FUNC1 of application B.

[0168] 2. The runtime environment checks whether application B has authorized application A in the interface authorization table. If there is no authorization record, the call is rejected.

[0169] 3. If there is an authorization record, the runtime environment will temporarily set the current runtime domain to the runtime domain of application B. The relevant runtime domain data of application A will be retained, and datasets and assemblies such as global variables and application data will be created for application B.

[0170] 4. The runtime environment executes the interface code FUNC1 of application B and returns the execution result.

[0171] 5. The runtime environment restores the current runtime domain to the runtime domain of application A, and reclaims the runtime environment, related datasets, and assemblies created for application B.

[0172] 6. The runtime environment returns the result of the API call, and application A continues to execute subsequent program code based on the result.

[0173] (III) Authorized Recycling

[0174] Interface call authorizations are recorded in the interface authorization table. This table is divided into n sub-lists based on the number of logical channels (n), forming a two-dimensional table structure. Each logical channel corresponds to one interface authorization table. Information recorded in the interface authorization table is promptly cleared under the following circumstances:

[0175] 1. When an application is changed from a running state to a non-running state by the runtime environment, the runtime environment needs to query the authorization table corresponding to the current logical channel to see if there is any authorization information with the application as the applicant. If so, all the authorization information found is cleared.

[0176] 2. When the embedded operating system loses power and then restarts, all applications are not running. At this time, the authorization information in the authorization table corresponding to all logical channels must be cleared.

[0177] 3. In the same logical channel, the applicant application is running, while the applicant application is not running. On other logical channels, the applicant application may be deleted. When it is deleted, the runtime environment needs to query the authorization table corresponding to the current logical channel to see if there is an authorization record with the deleted application as the applicant. If it exists, all found authorization information is cleared.

[0178] (iv) Data Access

[0179] During the execution of the current application's program code, when calling the interface code of other applications after requesting authorization, the application may pass its own application data (global variable data, constant data, etc.) to the requested application. When the interface call ends, the application data (global variable data, constant data, etc.) of the requested application may be passed to the currently running application. At this time, the runtime environment discovers a conflict between the running domain and the accessed data when performing data access. From the perspective of data security access design, the runtime environment should abnormally exit the run in the event of such a conflict to prevent the application's data from being leaked.

[0180] Considering the needs of practical application development, data that does not require security protection or is encrypted needs to be transmitted. The application dataset is designed to allow data types that can be accessed across runtime domains. When the runtime environment finds a conflict between the runtime domain and the application data to be accessed, it needs to check whether the application data is cross-runtime domain data. If so, access is allowed; otherwise, the runtime environment exits the program abnormally.

[0181] Figure 7 This is a schematic diagram of a device for maintaining an interface authorization table according to an embodiment of the present invention. The runtime environment is configured within an embedded operating system, which is installed on a restricted device, such as... Figure 7 As shown, the device includes: an authorization information construction module 710 and an authorization information writing module 720, wherein:

[0182] The authorization information construction module 710 is used to construct the first authorization information between the applicant and the applicant if it is determined that the applicant's code has successfully obtained authorization to call the interface of the applicant during the execution process;

[0183] The authorization information writing module 720 is used to write the first authorization information into the target interface authorization table in the target logical channel, wherein the applicant code is executed in the target logical channel.

[0184] The technical solution of this invention provides an application interface authorization management method that establishes an authorization table in the runtime environment. By writing authorization information between the applicant and the applicant into the interface authorization table within the target logic channel executing the applicant's code, and implementing application interface authorization calls based on this authorization information, the method delegates most of the functionality for handling interface authorization calls to the runtime environment for rapid completion, minimizing the application layer's handling of call and authorization-related logic. While maintaining application performance, it allows application developers to seamlessly complete application interface authorization calls, improving application development convenience and achieving high-performance application interface authorization calls while minimizing the programming workload for application developers.

[0185] Based on the above embodiments, the applicant includes an application program that is running within the target logical channel.

[0186] Based on the above embodiments, the applicant includes an instantiated application or an uninstantiated application module.

[0187] Based on the above embodiments, a first type of authorization information clearing module is also included, used for:

[0188] When the selected active target application in the target logical channel switches from running to non-running state, the authorization information of the target application as the applicant is cleared in the target interface authorization table.

[0189] Based on the above embodiments, a second type of authorization information clearing module is also included, used for:

[0190] When the embedded operating system restarts after a power failure, or when the runtime environment is reset after a power failure, all authorization information is cleared from the interface authorization table in each logical channel managed by the runtime environment.

[0191] Based on the above embodiments, a third type of authorization information clearing module is also included, used for:

[0192] When determining to remove a failed application from the embedded operating system, the authorization information for the failed application as the applicant is cleared from the interface authorization table in each logical channel managed by the runtime environment.

[0193] Based on the above embodiments, a fourth type of authorization information clearing module is also included, used for:

[0194] Before writing the first authorization information into the target interface authorization table within the target logical channel, clear any other authorization information currently stored in the target interface authorization table.

[0195] Based on the above embodiments, the authorization information construction module 710 specifically includes:

[0196] The execution result acquisition unit is used to execute the authorization detection code of the applicant in the target logical channel and obtain the execution result when the applicant code initiates an authorization request for the interface call of the applicant. If the authorization information between the applicant and the applicant is not stored in the target interface authorization table and the applicant is an instantiated application, the unit will obtain the execution result.

[0197] The successful application confirmation unit is used to determine that if the execution result is a confirmation of interface authorization, the applicant code has successfully applied for authorization to call the interface of the applicant.

[0198] Based on the above embodiments, the execution result acquisition unit may further include:

[0199] The first switching subunit of the operating domain is used to switch the first operating domain currently used by the target logical channel to the second operating domain corresponding to the applicant;

[0200] The result acquisition subunit is used to call the authorization check interface of the applicant within the target logical channel based on the applicant's identifier and the application parameters in the authorization application, and obtain the interface return result.

[0201] The second switching subunit of the operating domain is used to switch the first operating domain back to the operating domain currently used by the target logical channel.

[0202] Based on the above embodiments, the first switching subunit of the operating domain can be specifically used for:

[0203] Temporarily store the operation domain-related data within the first operation domain;

[0204] After switching the first running domain currently used by the target logic channel to the second running domain corresponding to the applicant, a dataset and program assembly corresponding to the applicant are established in the second running domain.

[0205] Correspondingly, it may also include a runtime domain recycling subunit, used for:

[0206] After switching the first running domain back to the running domain currently used by the target logical channel, the running domain association data temporarily stored in the first running domain is rewritten back to the first running domain;

[0207] Reclaim the second runtime domain, as well as the datasets and assemblies created for the applicant.

[0208] Based on the above embodiments, the authorization information construction module 710 is specifically used for:

[0209] When the applicant code initiates an authorization request for calling the interface of the respondent, if the authorization information between the applicant and the respondent is not stored in the target interface authorization table, and the respondent is an uninstantiated application module, then the applicant code is determined to have successfully obtained the authorization to call the interface of the respondent.

[0210] Based on the above embodiments, the interface call authorization application is generated by the applicant by calling the application authorization interface provided by the runtime environment, according to the applicant's identifier and application parameters.

[0211] Based on the above embodiments, an authorization result feedback module is also included, used for:

[0212] After writing the authorization information into the target interface authorization table within the target logical channel, the interface call authorization result is generated and fed back to the applicant code executing in the target logical channel, so that the applicant code can execute subsequent interface call code to the applicant based on the interface call authorization result.

[0213] The interface authorization table maintenance device provided in this embodiment of the invention can execute the interface authorization table maintenance method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

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

[0215] Figure 8 This is a schematic diagram of the structure of an application interface authorization invocation device provided in an embodiment of the present invention. The runtime environment is configured within an embedded operating system, which is installed in a restricted device, such as... Figure 8 As shown, the device includes: an interface authorization table query module 810 and an interface code calling module 820.

[0216] The interface authorization table query module 810 is used to query the target interface authorization table in the target logical channel if it is determined that the caller code calls the target interface code of the callee during the execution process. The target interface authorization table is maintained by the method described in any one of the embodiments of the present invention.

[0217] The interface code invocation module 820 is used to execute the target interface code of the callee in the target logical channel and obtain the interface invocation result if it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee. The caller code is executed in the target logical channel.

[0218] The technical solution of this invention determines whether the target interface code of the caller can be executed within the target logical channel when it is determined that the caller code needs to call the target interface code of the callee during execution. This is achieved by querying the target interface authorization table in the target logical channel to see if the authorization information corresponding to the caller and the callee is stored. This allows most of the functions of handling interface authorization calls to be quickly completed by the runtime environment, so that the application layer handles as little call and authorization-related logic as possible. In addition, the above implementation does not require adding special definitions and identifiers to the application interfaces called by the running application code, which avoids a lot of programming trouble in the application development process.

[0219] Based on the above embodiments, the interface code calling module 820 specifically includes:

[0220] The first switching unit of the running domain is used to switch the third running domain currently used by the target logical channel to the fourth running domain corresponding to the callee;

[0221] The call result acquisition unit is used to execute the target interface code of the callee within the target logical channel and obtain the interface call result;

[0222] The second switching unit of the operating domain is used to switch the third operating domain back to the operating domain currently used by the target logical channel.

[0223] Based on the above embodiments, the first switching unit of the operating domain is specifically used for:

[0224] Temporarily store the operation domain-related data within the third operation domain;

[0225] After switching the third execution domain currently used by the target logic channel to the fourth execution domain corresponding to the callee, a dataset and program assembly corresponding to the callee are established in the fourth execution domain.

[0226] Correspondingly, it may also include: a runtime domain recycling unit, used for:

[0227] After switching the third running domain back to the running domain currently used by the target logical channel, the running domain association data temporarily stored in the third running domain is rewritten back to the third running domain;

[0228] Reclaim the fourth run domain, as well as the datasets and assemblies created for the callee.

[0229] Based on the above embodiments, it may further include an interface call result feedback module, used for:

[0230] After obtaining the API call result, the API call result is fed back to the caller code executing in the target logic channel so that the caller code can continue to execute based on the API call result.

[0231] Based on the above embodiments, the interface code calling module 820 further includes:

[0232] The first conflict detection unit is used to detect whether the execution domain currently used by the target logical channel conflicts with the first application data if it needs to access the first application data belonging to the caller during the execution of the target interface code of the callee in the target logical channel.

[0233] The first control access unit is used to, if not, perform access to the first application data within the operating domain currently used by the target logical channel.

[0234] Based on the above embodiments, the interface code calling module 820 further includes:

[0235] The second control access unit is configured to, if the first application data is determined to be cross-operation domain access data, perform access to the first application data within the operating domain currently used by the target logical channel.

[0236] Based on the above embodiments, the interface call result feedback module further includes:

[0237] The second conflict detection unit is used to detect whether the running domain currently used by the target logical channel conflicts with the second application data when the interface call result contains second application data belonging to the callee.

[0238] The third control access unit is used to, if not, feed back the interface call result to the caller code executing in the target logic channel.

[0239] Based on the above embodiments, the interface call result feedback module further includes:

[0240] The fourth control access unit is used to, if the second application data is determined to be cross-operation domain access data, feed back the interface call result to the caller code executing in the target logic channel.

[0241] The application interface authorization invocation device provided in the embodiments of the present invention can execute the application interface authorization invocation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

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

[0243] Figure 9 A schematic diagram of the structure of a limited device 10 that can be used to implement an embodiment of the present invention is shown.

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

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

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

[0247] If it is determined that the applicant's code successfully obtained authorization to call the interface of the respondent during the execution process, then the first authorization information between the applicant and the respondent is constructed;

[0248] Write the first authorization information into the target interface authorization table within the target logical channel, where the applicant's code is executed within the target logical channel.

[0249] For example, an authorized invocation method for an application interface as described in various embodiments of the present invention is executed by a runtime environment in an embedded operating system installed on a restricted device. The method includes:

[0250] If it is determined that the caller code calls the target interface code of the callee during execution, the target interface authorization table in the target logical channel is queried, wherein the target interface authorization table is maintained by the method described in any one of the embodiments of the present invention;

[0251] If it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee, then the target interface code of the callee is executed in the target logical channel to obtain the interface call result. The caller code is executed in the target logical channel.

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

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

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

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

[0256] Figure 10 This is a structural diagram of a terminal provided according to an embodiment of the present invention. Figure 10 The terminal includes the restricted device 1010 as described in any embodiment of the present invention.

[0257] The restricted device 1010 can be an embedded security element.

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

Claims

1. A method for maintaining an interface authorization table, characterized in that, The method, executed by a runtime environment within an embedded operating system installed on a restricted device, comprises: If it is determined that the applicant's code successfully obtained authorization to call the interface of the respondent during the execution process, then the first authorization information between the applicant and the respondent is constructed; Write the first authorization information into the target interface authorization table within the target logical channel, where the applicant's code is executed within the target logical channel.

2. The method according to claim 1, characterized in that, The applicant includes applications that are running within the target logical channel.

3. The method according to claim 1, characterized in that, The applicant can be an instantiated application or an uninstantiated application module.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: When the selected active target application in the target logical channel switches from running to non-running state, the authorization information of the target application as the applicant is cleared in the target interface authorization table.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: When the embedded operating system restarts after a power failure, or when the runtime environment is reset after a power failure, all authorization information is cleared from the interface authorization table in each logical channel managed by the runtime environment.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: When determining to remove a failed application from the embedded operating system, the authorization information for the failed application as the applicant is cleared from the interface authorization table in each logical channel managed by the runtime environment.

7. The method according to claim 1, characterized in that, Before writing the first authorization information into the target interface authorization table within the target logical channel, the following steps are also included: Clear any other currently stored authorization information from the target interface authorization table.

8. The method according to claim 1, characterized in that, Confirm that the applicant's code successfully obtained authorization to call the respondent's interface during execution, including: When the applicant code initiates an authorization request for an interface call to the respondent, if the authorization information between the applicant and the respondent is not stored in the target interface authorization table, and the respondent is an instantiated application, then the authorization detection code of the respondent is executed in the target logic channel to obtain the execution result. If the execution result is "Confirm Interface Authorization", then it is determined that the applicant's code has successfully obtained authorization to call the interface of the applicant.

9. The method according to claim 8, characterized in that, Execute the applicant's authorization detection code within the target logic channel and obtain the execution results, including: Switch the first operating domain currently used by the target logical channel to the second operating domain corresponding to the applicant; Based on the applicant's identifier and the application parameters in the authorization application, the authorization check interface of the applicant is called within the target logical channel to obtain the interface return result; Switch the first run domain back to the run domain currently used by the target logical channel.

10. The method according to claim 9, characterized in that, Switching the target logic channel's current first operating domain to the second operating domain corresponding to the applicant includes: Temporarily store the operation domain-related data within the first operation domain; After switching the first running domain currently used by the target logic channel to the second running domain corresponding to the applicant, a dataset and program assembly corresponding to the applicant are established in the second running domain. After switching the first run domain back to the run domain currently used by the target logical channel, the following is also included: Rewrite the runtime domain association data in the temporarily stored first runtime domain back into the first runtime domain; Reclaim the second runtime domain, as well as the datasets and assemblies created for the applicant.

11. The method according to claim 1, characterized in that, Confirm that the applicant's code successfully obtained authorization to call the respondent's interface during execution, including: When the applicant code initiates an authorization request for calling the interface of the respondent, if the authorization information between the applicant and the respondent is not stored in the target interface authorization table, and the respondent is an uninstantiated application module, then the applicant code is determined to have successfully obtained the authorization to call the interface of the respondent.

12. The method according to any one of claims 8-11, characterized in that, The API call authorization request is generated by the applicant based on the respondent's identifier and the request parameters by calling the authorization request interface provided by the runtime environment.

13. The method according to claim 1, characterized in that, After writing the authorization information into the target interface authorization table within the target logical channel, the following is also included: The API call authorization result is generated and fed back to the applicant code executing in the target logic channel, so that the applicant code can execute subsequent API call code to the applicant based on the API call authorization result.

14. A method for authorizing the invocation of an application interface, characterized in that, The method, executed by a runtime environment within an embedded operating system installed on a restricted device, comprises: If it is determined that the caller code invokes the target interface code of the callee during execution, the target interface authorization table in the target logical channel is queried, wherein the target interface authorization table is maintained by the method described in any one of claims 1-13; If it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee, then the target interface code of the callee is executed in the target logical channel to obtain the interface call result. The caller code is executed in the target logical channel.

15. The method according to claim 14, characterized in that, Execute the target interface code of the callee within the target logic channel, and obtain the interface call result, including: Switch the target logic channel's current third execution domain to the fourth execution domain corresponding to the callee; Execute the target interface code of the callee within the target logic channel and obtain the interface call result; Switch the third run domain back to the run domain currently used by the target logical channel.

16. The method according to claim 15, characterized in that, Switching the target logic channel's current third execution domain to the fourth execution domain corresponding to the callee includes: Temporarily store the operation domain-related data within the third operation domain; After switching the third execution domain currently used by the target logic channel to the fourth execution domain corresponding to the callee, a dataset and program assembly corresponding to the callee are established in the fourth execution domain. After switching the third runtime domain back to the runtime domain currently used by the target logical channel, the following is also included: Rewrite the runtime domain association data temporarily stored in the third runtime domain back into the third runtime domain; Reclaim the fourth run domain, as well as the datasets and assemblies created for the callee.

17. The method according to claim 14, characterized in that, After obtaining the API call result, it also includes: The API call result is fed back to the caller code executing in the target logic channel, so that the caller code can continue execution based on the API call result.

18. The method according to any one of claims 14-17, characterized in that, Executing the target interface code of the callee within the target logic channel, obtaining the interface call result, and also including: During the execution of the callee's target interface code within the target logical channel, if it is necessary to access the first application data belonging to the caller, it is checked whether the execution domain currently used by the target logical channel conflicts with the first application data. If not, then access to the first application data is performed within the operating domain currently used by the target logical channel.

19. The method according to claim 18, characterized in that, After detecting whether the operating domain currently used by the target logical channel conflicts with the first application data, the process also includes: If so, when it is determined that the first application data is cross-operation domain access data, access to the first application data is performed within the operation domain currently used by the target logical channel.

20. The method according to claim 17, characterized in that, The API call result is fed back to the caller code executing in the target logic channel, including: When the interface call result contains second application data belonging to the callee, check whether the running domain currently used by the target logical channel conflicts with the second application data; If not, the result of the interface call will be fed back to the caller code executing in the target logic channel.

21. The method according to claim 20, characterized in that, After detecting whether the operating domain currently used by the target logical channel conflicts with the second application data, the process also includes: If so, when it is determined that the second application data is cross-domain access data, the interface call result will be fed back to the caller code executing in the target logical channel.

22. A device for maintaining an interface authorization table, characterized in that, A runtime environment configured within an embedded operating system, wherein the embedded operating system is installed in a restricted device, the device comprising: The authorization information construction module is used to construct the first authorization information between the applicant and the applicant if it is determined that the applicant's code has successfully obtained authorization to call the interface of the applicant during the execution process. The authorization information writing module is used to write the first authorization information into the target interface authorization table within the target logical channel, wherein the applicant code is executed in the target logical channel.

23. An authorization invocation device for an application interface, characterized in that, A runtime environment configured within an embedded operating system, wherein the embedded operating system is installed in a restricted device, the device comprising: The interface authorization table query module is used to query the target interface authorization table in the target logical channel if it is determined that the caller code calls the target interface code of the callee during execution. The target interface authorization table is maintained by the method described in any one of claims 1-13. The interface code invocation module is used to execute the target interface code of the callee within the target logical channel and obtain the interface invocation result if it is determined that the target interface authorization table stores the second authorization information corresponding to the caller and the callee. The caller code is executed within the target logical channel.

24. A restricted device, characterized in that, The restricted device is equipped with an embedded operating system, which executes a runtime environment. The restricted device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the interface authorization table maintenance method of any one of claims 1-13, or to perform the application interface authorization invocation method of any one of claims 14-21.

25. A terminal, characterized in that, Includes the restricted device as described in claim 24.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method for maintaining the interface authorization table as described in any one of claims 1-13, or the method for authorizing the invocation of the application interface as described in any one of claims 14-21.

27. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method for maintaining the interface authorization table according to any one of claims 1-13, or implements the method for authorizing the invocation of the application interface according to any one of claims 14-21.

Images