CN117971676A - Application risk detection method and device - Google Patents

Abstract

The present application provides an application risk detection method and device, which relates to the field of risk detection technology, and can perform risk detection on applications to determine objects with cross-operating system application risks in applications. The method includes: obtaining the calling relationship between M objects of the application, and determining the objects with risks based on the calling relationship between the M objects and the operating system application to which each object belongs. Wherein, M is greater than or equal to 2, and the objects include functions and/or variables; the calling relationship between the M objects includes at least one of function accessing variables, function calling functions, variable referencing variables, and variable referencing functions; and at least two operating system applications have different risk levels.

Description

Application risk detection method and device

Technical Field

The present application relates to the field of risk detection technologies, and in particular, to a method and an apparatus for detecting risk of an application program.

Background

An automotive open system architecture (automotive open system architecture, AUTOSAR) is a set of software architecture systems built jointly by global automotive manufacturers, component suppliers, and other electronic, semiconductor, and software system companies, each member maintaining a development partnership. AUTOSAR is dedicated to developing an open, standardized software architecture for the vehicle industry.

However, during the development process, due to negligence or insufficient cognition of the developer, some errors may occur in the running process of the developed application program, and a certain risk exists.

Disclosure of Invention

The application provides an application risk detection method and device, which can detect risks of an application program so as to determine objects of cross-operating system application risks existing in the application program.

In order to achieve the above object, the present application provides the following technical solutions:

In a first aspect, the present application provides an application risk detection method, including: acquiring a calling relation among M objects of an application program, wherein M is more than or equal to 2, and the objects comprise functions and/or variables; the calling relation among the M objects comprises at least one of a function access variable, a function calling function and a variable reference variable, wherein the variable reference function is used for referencing the function; according to the calling relation among the M objects and the operating system application programs to which each object belongs, determining the object with risk, wherein the risk levels of at least two operating system application programs are different.

By the method, the risk detection of the application program can be performed on the application program in advance, and the object with the risk of the application program crossing the operating system is determined in the application program, so that a subsequent developer can adjust the application program, and the risk of the application program crossing the operating system is eliminated.

In one possible implementation, the application risk detection simulates machine code of an executing application to obtain call relationships between M objects of the application.

Compared with the method for manually configuring function pointers to obtain the calling relations among the objects in the application program in the related technology, the method can reduce the workload of developers and improve the efficiency and accuracy of determining the calling relations among M objects of the application program. And the application processes the binary file (machine code) of the application program, does not depend on source code, does not need to run on the real environment, reduces the detection cost,

In one possible implementation, the method further includes: displaying the object with risk.

Through the mode, a developer can conveniently and intuitively acquire the object information with risk in the application program, and user experience is improved.

In one possible implementation, the method further includes: determining first information and/or second information according to calling relations among the M objects and an operating system application program to which each object belongs; the first information represents the calling relation between the object with risk and other objects, and the second information represents the operating system application program to which the object with risk belongs; the first information and/or the second information is displayed.

Through the mode, the developer can also acquire other information related to the object with risk in the application program, so that the developer can conveniently change the application program with risk, and the user experience is further improved.

In one possible implementation, the method includes: acquiring a configuration file of an application program, wherein the configuration file comprises N sections and an operating system application program to which each section belongs, and N is more than or equal to 1; the N segments include M objects; each segment includes a data segment or a code segment; and determining the operating system application program to which each object in the M objects belongs according to the configuration file.

Alternatively, the application risk detection device may receive a configuration file of an application from a developer, where the configuration file includes N segments to which M objects belong, and an operating system application to which each segment belongs. By the method, the application risk detection device can determine the operating system application program to which each object belongs according to the N segments to which the M objects belong and the operating system application program to which each segment belongs, so that whether the calling relationship among the M objects has a risk of crossing the operating system application program or not is determined.

In one possible implementation, the risk includes a risk of an application across operating systems, the M objects include a first object and a second object, and determining an object having a risk according to a call relationship between the M objects and the operating system application to which each object belongs includes: if the first object calls the second object, the first object is subordinate to the first operating system application program, the second object is subordinate to the second operating system application program, and the first operating system application program prohibits access to the second operating system application program, the risk of the first object crossing the operating system application program is determined.

For example, when the vehicle functional safety integrity level of the first operating system application is equal to or lower than the vehicle functional safety integrity level of the second operating system application, it is determined that the first object is at risk across operating system applications.

In one possible implementation, the configuration file includes a third party library of the application program, the method further comprising: analyzing a third party library of the application program to obtain calling relations among L objects; and simulating and executing the application program according to the calling relation among the L objects to obtain the calling relation among H objects, wherein the H objects comprise the L objects and the M objects.

By the method, the application risk detection can determine the calling relation among the H objects by the third party library and the application, and the data competition risk in the application can be detected more comprehensively.

In one possible implementation, the configuration file further includes a thread entry function that determines an object that is at risk, including: if at least more than two thread entry functions call the same object, determining that the object has data contention risk.

Exemplary if thread entry function 1 and thread entry function 2 pass through call variable 2, then variable 2 presents a risk of data race.

In a second aspect, the present application provides an application risk detection apparatus, including: the receiving and transmitting module is used for acquiring calling relations among M objects of the application program, M is greater than or equal to 2, and the objects comprise functions and/or variables; the calling relation among the M objects comprises at least one of a function access variable, a function calling function and a variable reference variable, wherein the variable reference function is used for referencing the function; and the processing module is used for determining the object with risk according to the calling relation among the M objects and the operating system application program to which each object belongs, and the risk levels of at least two operating system application programs are different.

In one possible implementation, the apparatus further includes: and the display module is used for displaying the object with risk.

In a possible implementation manner, the processing module is further configured to determine the first information and/or the second information according to a calling relationship between M objects and an operating system application program to which each object belongs; the first information represents the calling relation between the object with risk and other objects, and the second information represents the operating system application program to which the object with risk belongs; and the display module is also used for displaying the first information and/or the second information.

In one possible implementation manner, the transceiver module is further configured to obtain a configuration file of the application program, where the configuration file includes N segments and an operating system application program to which each segment belongs, and N is greater than or equal to 1; the N segments include M objects; each segment includes a data segment or a code segment; and the processing module is also used for determining an operating system application program to which each object in the M objects belongs according to the configuration file. In one possible implementation, the risk includes a cross-operating system application risk, the M objects include a first object and a second object, and the processing module is further configured to determine that the first object has the cross-operating system application risk if the first object invokes the second object, the first object is subordinate to the first operating system application, the second object is subordinate to the second operating system application, and the first operating system application prohibits access to the second operating system application. In one possible implementation, the configuration file includes a third party library of the application program, and the processing module is further configured to parse the third party library of the application program to obtain a calling relationship between the L objects; and simulating and executing the application program according to the calling relation among the L objects to obtain the calling relation among H objects, wherein the H objects comprise the L objects and the M objects. In one possible implementation, the configuration file further includes a thread entry function, and the processing module is further configured to determine that the object has a risk of data contention if at least two of the thread entry functions call the same object.

In a third aspect, the present application provides an application risk detection system, including: the application risk detection apparatus according to the second aspect.

In a fourth aspect, the present application provides a computer readable storage medium comprising a computer program or instructions which, when run on an application risk detection device, cause the application risk detection device to perform the method as described in the first aspect.

In a fifth aspect, the present application provides a system on a chip comprising at least one processor and at least one interface circuit for performing transceiving functions and for sending instructions to the at least one processor, the at least one processor performing the method according to any of the first aspects described above when the at least one processor executes the instructions.

In a sixth aspect, the application also provides a computer program product comprising instructions which, when run on a computer, cause the computer to perform the method according to any of the first aspects.

In a seventh aspect, the application also provides circuitry comprising processing circuitry configured to perform the first aspect or the method of any of the embodiments of the first aspect.

The technical effects corresponding to the second aspect to the seventh aspect and any implementation manner of the second aspect to the seventh aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, and are not repeated here.

Drawings

FIG. 1 is a schematic diagram of a risk across operating system applications provided in an embodiment of the present application;

Fig. 2 is a schematic structural diagram of an application risk detection device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of an application risk detection system according to an embodiment of the present application;

FIG. 4 is a flowchart of an application risk detection method according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a risk across operating system applications provided by an embodiment of the present application;

fig. 6 is a schematic diagram of a data contention risk according to an embodiment of the present application;

Fig. 7 is a schematic structural diagram of an application risk detection device according to an embodiment of the present application;

Fig. 8 is a schematic structural diagram of a chip system according to an embodiment of the present application.

Detailed Description

The terms "comprising" and "having" and any variations thereof, as used in the description of embodiments of the application, are intended to cover a non-exclusive inclusion. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed but may optionally include other steps or elements not listed or inherent to such process, method, article, or apparatus.

It should be noted that, in the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. "and/or" herein is merely an association relationship describing an association object, and means that three relationships may exist, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone.

The particular features, structures, or characteristics of the application may be combined in any suitable manner in one or more embodiments. In various embodiments of the present application, the sequence number of each process does not mean the sequence of execution sequence, and the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

Some optional features of the embodiments of the present application may be implemented independently without depending on other features in some scenarios, so as to solve corresponding technical problems, achieve corresponding effects, and may also be combined with other features according to requirements in some scenarios.

In the present application, the same or similar parts between the embodiments may be referred to each other unless specifically stated otherwise. In the various embodiments of the application, if there is no specific description or logical conflict, terms and/or descriptions between the various embodiments will be consistent and will reference each other. The embodiments of the present application do not limit the scope of the present application.

In addition, the network architecture and the service scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided by the embodiments of the present application, and as a person of ordinary skill in the art can know, with evolution of the network architecture and appearance of a new service scenario, the technical solution provided by the embodiments of the present application is also applicable to similar technical problems.

First, some technical terms related to the embodiments of the present application will be described:

1. Operating system applications (operating system Application, OS-Application, OSA)

The operating system application is a concept of an AUTOSAR Classical Platform (CP), and an OSA represents a functional security domain corresponding to an automotive functional security integrity level (ASIL). Among them, OSA can have 5 levels of vehicle functional safety integrity, classified as QM, A, B, C, D from low to high. The function/variable in the OSA with different safety integrity levels of the vehicle functions can be called freely, and the call between the functions/variables in the OSA with different safety integrity levels of the vehicle functions is strictly constrained. Functions/variables in the OSAs of a lower vehicle function safety integrity level cannot be invoked either by functions/variables in OSAs of a higher vehicle function safety integrity level or by OSAs of the same vehicle function safety integrity level. If the function/variable in the OSA of the vehicle function safety integrity level is called against the constraint, the operating system will be involved in the exception and stop working.

Alternatively, some of the functions/variables may be located in a common library, and the functions/variables in the OSA for each vehicle functional safety integrity level may call the functions/variables in the common library.

Optionally, the variables in the embodiments of the present application are the same as the system lifecycle (global variables).

2. Third party library

The third party library is a software library created and maintained by an independent developer or organization for enhancing or extending the functionality of the programming language or framework.

In software development, third party libraries are typically used to solve specific problems, provide additional functionality, or simplify the implementation of common tasks. These libraries are typically shared and provided by other developers and distributed and obtained through a package manager or official website.

The third party library may be a target file, i.e. a binary file (which may be an xxx.o file) generated by the compiler to be linked, storing code and data and other information related to the linker in a certain format. Code and data, as well as other linker-related information, may be stored in executable and linkable formats (executable and linkable format, ELF), unified object file format (common object file format, COFF), and the like. None of the symbols in the target file determine the run address and are therefore not executable. Wherein, the symbol is a concept in compiling links, and is a generic term of functions, variables, constants and the like.

The third party library may also be a static library (e.g., may be an xxx.a file) that packages multiple target files together in order. Such as the C standard library (C STANDARD library).

3. Section/section (section)

Symbols in the target file/executable file are sorted into corresponding segments, such as code segments, data segments, heap segments, stack segments, etc., according to the same attribute (e.g., read/write/executable attribute). Wherein the executable file represents a binary file that can be loaded for execution after completion of the link, wherein the symbols have already determined the run address and can be executed.

In one solution, the AUTOSAR CP has strict constraints on accessing functions/variables across operating system applications. As shown in fig. 1, a schematic diagram of the relationship between functions/variables and OSA is shown. The vehicle function safety integrity level of the OSA 1 is QM level, and the OSA 1 comprises a function f11, a function f12 and a function f13; the vehicle function safety integrity level of the OSA 2 is QM level, and the OSA 2 comprises a function f21, a variable d22 and a function f23; the common library comprises a function f31, a variable d32 and a variable d33; the OSA 4 has a D-level vehicle functional safety integrity level, and the OSA 4 includes a function f41, a function f42, and a function f43.

Wherein the call relationship f12- > f21 (f 12 call f 21) is a cross-operating system application call that violates a constraint. The vehicle function safety integrity level of the OSA 1 to which the function f12 belongs is QM level, the vehicle function safety integrity level of the OSA 2 to which the function f21 belongs is QM level, and the OSA 1 and the OSA 2 are the same in vehicle function safety integrity level, so the function f12 cannot call the function f21.

The call relationship f13- > f41 is a cross-operating system application call that violates a constraint. The vehicle functional safety integrity level of the OSA 1 to which the function f13 belongs is QM level, the vehicle functional safety integrity level of the OSA 4 to which the function f41 belongs is D level, and the vehicle functional safety integrity level of the OSA 4 is higher than the vehicle functional safety integrity level of the OSA 1, so the function f13 cannot call the function f41.

The call relationship f43→f11 is an allowed cross-operating system application call. The vehicle functional safety integrity level of the OSA 4 to which the function f43 belongs is a D level, the vehicle functional safety integrity level of the OSA 1 to which the function f11 belongs is a QM level, and the vehicle functional safety integrity level of the OSA 4 is higher than the vehicle functional safety integrity level of the OSA 1, so the function f43 can call the function f11.

The call relationships f41- > f31, d22- > f31 are allowed cross-operating system application calls. The function f31 is a function in a common library, and the functions/variables in the OSA for each vehicle function safety integrity level can be called. Thus, function f41 may call function f31, and variable d22 may call function f31.

In the call relationship f23- > d22- > f31- > d32- > d33, d33- > f42 is a cross-operating system application call that violates the constraint. The function f23 in this call relationship has a QM-class vehicle function safety integrity level of OSA 2, while the function f42 has a D-class vehicle function safety integrity level of OSA 4, so that the call relationship violates the constraint cross-operating system application call, and the function f42 cannot be called by the variable D33.

In the development process of an application program, functions/variables in the application program are mapped to wrong OSAs often due to negligence or cognition deficiency of a developer, so that an operating system is abnormal when the application program is run.

In order to solve the above problems, an embodiment of the present application provides an application risk detection method. According to the method, the application risk detection device can acquire the calling relation among M objects of the application, and the object with risk is determined according to the calling relation among M objects and the operating system application to which each object belongs. Wherein M is greater than or equal to 2, and the object comprises a function and/or a variable; the calling relation among the M objects comprises at least one of a function access variable, a function calling function and a variable reference variable, wherein the variable reference function is used for referencing the function; the risk levels of at least two operating system applications are different. And detecting the risk of the application program in advance, and determining that the object with the risk of the application program crossing the operating system exists in the application program, so that a subsequent developer can adjust the application program and eliminate the risk of the application program crossing the operating system.

In one embodiment, the application risk detection means may be a single dimension measuring device. Or the application risk detection device can also be embedded equipment and applied to development scenes such as vehicle-mounted equipment, terminal equipment, industrial control equipment and the like. Or the above method may also be integrated into the compilation flow of an application. The embodiment of the present application is not particularly limited thereto.

Fig. 2 is a schematic hardware structure diagram of an application risk detection device according to an embodiment of the present application. The application risk detection means comprises at least one processor 201, a communication line 202, a memory 203, at least one communication interface 204. The memory 203 may also be a memory in the processor 201.

The processor 201 may be a central processing unit (central processing unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (field programmable GATE ARRAY, FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general purpose processor may be a microprocessor or any conventional processor.

Communication line 202 may include a pathway to transfer information between the aforementioned components.

A communication interface 204 for communicating with other devices. In the embodiment of the present application, the communication interface may be a module, a circuit, a bus, an interface, a transceiver, or other devices capable of implementing a communication function. Alternatively, when the communication interface is a transceiver, the transceiver may be a separately provided transmitter that is operable to transmit information to other devices, or a separately provided receiver that is operable to receive information from other devices. The transceiver may also be a component that integrates the functions of transmitting and receiving information, and embodiments of the present application are not limited to the specific implementation of the transceiver.

In some embodiments, the communication interface may be a media interface. That is, one interface may be used as both a communication interface and a media interface.

The memory 203 may be volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile memory may be a read-only memory (ROM), a Programmable ROM (PROM), an erasable programmable ROM (erasable PROM), an electrically erasable programmable EPROM (EEPROM), or a flash memory. The volatile memory may be random access memory (random access memory, RAM) which acts as external cache memory. By way of example, and not limitation, many forms of RAM are available, such as static random access memory (STATIC RAM, SRAM), dynamic random access memory (DYNAMIC RAM, DRAM), synchronous Dynamic Random Access Memory (SDRAM), double data rate synchronous dynamic random access memory (doubledata RATE SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (ENHANCED SDRAM, ESDRAM), synchronous link dynamic random access memory (SYNCHLINK DRAM, SLDRAM) and direct memory bus random access memory (direct rambus RAM, DR RAM) or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory may be stand alone and be coupled to the processor 201 via a communication line 202. Memory 203 may also be integrated with processor 201.

Wherein the memory 203 stores computer executable instructions for implementing aspects of the present application and is controlled for execution by the processor 201. The processor 201 is configured to execute computer executable instructions stored in the memory 203, thereby implementing the application risk detection method provided in the following embodiments of the present application.

Computer-executable instructions in embodiments of the present application may also be referred to as application code, instructions, computer programs, or other names, and embodiments of the present application are not limited in detail.

In a particular implementation, as one embodiment, processor 201 may include one or more CPUs, such as CPU0 and CPU1 of FIG. 2.

In a specific implementation, as an embodiment, the application risk detection means may comprise a plurality of processors, such as processor 201 and processor 205 in fig. 2. Each of these processors may be a single-core processor or a multi-core processor.

It will be appreciated that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the application risk detection means. In other embodiments of the application, the electronic device may include more or less components than illustrated, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Fig. 3 is a schematic diagram of an application risk detection system according to an embodiment of the present application. The application risk detection system comprises an application risk detection device.

Optionally, the application risk detection device is configured to receive a machine code of the application and a configuration file of the application, and determine an object in the application that is at risk according to the machine code of the application and the configuration file of the application.

Alternatively, the configuration file of the application may include the relationship (subordinate relationship) of the segment to the OSA.

In one embodiment, the configuration file of the application may also include a third party library.

In one embodiment, the configuration file of the application may also include a thread entry function.

In one embodiment, the configuration file of the application program may also include other files, which the embodiments of the present application do not particularly limit.

Alternatively, the application risk detection device may also be referred to as a static scanning device, a static scanning system, or the like.

As shown in fig. 4, a flowchart of an application risk detection method according to an embodiment of the present application includes steps S101 to S102:

S101, an application risk detection device acquires calling relations among M objects of an application.

Wherein M is greater than or equal to 2, and the object comprises a function and/or a variable.

Alternatively, the application risk detection device may acquire the machine code of the application, and parse the machine code to acquire M objects in the application.

In one embodiment, the application risk detection device may simulate executing each function in the application to obtain the calling relationship between M objects in the application.

Alternatively, the calling relationship between the M objects may include at least one of a function access variable, a function call function, a variable reference variable, and a variable reference function.

In one scenario, the application includes a function call instruction, where the function call instruction may record a call relationship between a function and a function or between a function and a variable, may save a call site, and cause the application to jump to a called object.

Alternatively, the function call instruction may include a direct call instruction and an indirect call instruction.

Wherein, the direct call instruction can directly obtain the address of the target object (called object) from the instruction.

Alternatively, the indirect call instruction may be an instruction that is called by a function pointer, which is a pointer variable pointing to a function, that may be used to store an address of the function and call a corresponding function by the pointer variable. The application risk detection means may traverse all target objects to which the function pointer may be directed.

Alternatively, when the object is called by the function pointer, if the user designates the target object, the application program may preferentially call the target object designated by the application program. The application risk detection means may detect only whether or not there is a risk in the call relation of the function call to the specified target function.

In another scenario, the application program includes a calculation instruction, and the application program may perform calculation according to the semantics of the calculation instruction, and may subsequently write the calculation result into the target register.

Alternatively, the calculation instructions may include assignment instructions, calculation instructions, and the like. The embodiment of the present application is not particularly limited thereto.

In another scenario, a jump instruction is included in the application.

Optionally, the jump instruction may cause only a part of the function instructions to be executed in a simulation, so that the application risk detection device may ignore the jump instruction when executing the application in a simulation, and execute all the application in a simulation, thereby ensuring that the calling relationship between all the objects is obtained.

Optionally, result independent instructions in the application may be ignored, such as operating system state instructions, interrupt off instructions, interrupt on instructions, and the like.

In another scenario, a write memory instruction is included in an application. Wherein the write memory instruction indicates that the application program writes a value into the memory.

In another scenario, a read memory instruction is included in an application. Wherein, the read memory instruction indicates that the application program reads a value from the memory.

Optionally, if the application program reads the value from the memory for the first time, that is, when the application program starts to execute, the operating system allocates the memory for the application program and loads the initial value of the variable in the data segment into the corresponding memory location. Subsequent applications, when executed, may read the initial values of the variables by accessing the variables in memory.

Alternatively, the pointer is a variable that stores a memory address through which data in memory may be indirectly accessed and modified. When the application program reads the memory address, if the read memory address corresponds to a certain variable of the application program, the function in the memory space of the variable can be searched and recorded and stored as a function list, and when the application program passes through an object called by the function pointer, the function list can be traversed, so that the simulation execution efficiency is improved.

Optionally, other instructions may be included in the application, which are not further illustrated by the embodiments of the present application.

For example, as shown in fig. 5, the call relationship of the object in the application program obtained by simulating execution of each function in the application program may be function 1 (one example of the first object) - > function 2 (one example of the second object), that is, function 1 calls function 2.

In another embodiment, the application risk detection means may read directly in the function call relationship specified by the user.

For example, after determining the function call relationship in the application program, the user may directly send the function call relationship to the application program risk detection device.

S102, the application risk detection device determines the object with risk according to the calling relation among M objects and the operating system application program to which each object belongs.

Optionally, the application risk detection device may further parse the machine code of the application to obtain a segment to which each object of the application belongs.

Illustratively, the application program includes a function 1 and a function 2; where function 1 is located at segment 1 and function 2 is located at segment 2.

Alternatively, the application risk detection device may obtain a configuration file of the application, where the configuration file includes N segments and an operating system application to which each segment belongs. Wherein N is greater than or equal to 1; the N segments comprise M objects in the application program; each segment includes a data segment or a code segment.

Illustratively, the configuration file includes a segment 1 and a segment 2, wherein the segment 1 belongs to an operating system application 1, and the segment 2 belongs to the operating system application 2. The vehicle function security integrity level of the operating system application 1 is QM level, and the vehicle function security integrity level of the operating system application 2 is D level.

Optionally, the application risk detection device may determine the first information and/or the second information according to a calling relationship between M objects and an operating system application program to which each object belongs; the first information represents the calling relation between the object with risk and other objects, and the second information represents the operating system application program to which the object with risk belongs.

Illustratively, function 1 belongs to operating system application 1 and function 2 belongs to operating system application 2. Then function 1 call function 2 is a cross-operating system application call that violates the constraint in the call relationship of the object in the application. Function 1 presents a risk across operating system applications, the operating system application to which function 1 belongs being operating system application 1.

Alternatively, the application risk detection means may display that a cross-operating system application risk object exists.

For example, the application risk detection means may display function 1.

Optionally, the application risk detection device may further display that there is a call relationship across operating system application risks.

For example, the application risk detection means may display that call relation function 1 calls function 2.

Optionally, the application risk detection device may further display an operating system application to which the object having the risk of crossing the operating system application belongs.

For example, the application risk detection means may display the operating system application 1 to which the function 1 belongs.

In another embodiment, the application risk detection apparatus may further send information such as the object, the first information, the second information, and the like, which are at risk, to other devices.

For example, the application risk detection device may further send information such as the object, the first information, the second information, and the like, which are at risk, to the terminal device of the developer. And the developer acquires the information such as the object with risk, the first information, the second information and the like through the terminal equipment.

Optionally, the subsequent developer may modify the application according to the object, the call relationship, and the operating system application to which the object belongs, where the object exists in the application, so as to ensure that the risk of the cross-operating system application no longer exists in the application.

In another possible scenario, there may be a risk of data race in the application, which may also cause many unexpected errors in the application, with serious consequences to the operating system that are difficult to predict.

In one implementation, an application may be statically scanned to determine objects that are at risk of data race. However, the method needs to manually configure the function pointer, so that the manual analysis and configuration have huge workload and are easy to make mistakes.

Such as for the following applications:

int var

var＝0

void thread1()

{

var++

}

void thread2()

{

var++

}

The developer's expectation for the application is that the variable var value is 2, however the application may actually perform as: int: 0= > var; thread1: var+1; thread2: var+1; thread2: 1= > var; thread1: 1= > var, the actual value of var obtained may be 1.var presents a risk of data race.

In the embodiment of the application, the application program can be simulated and executed, and in the simulation and execution process, all target objects possibly pointed by the function pointer can be traversed. And a function pointer is not required to be manually configured, so that the efficiency of determining the data competition risk is improved.

In one embodiment, the configuration file of the application program obtained by the application program risk detection device may further include a thread entry function.

Alternatively, the application risk detection means may determine the object at risk from the thread entry function and the call relationship between the M objects.

Optionally, if at least two or more thread entry functions call the same object, it is determined that the object has a risk of data race. The thread entry function that calls the object is the thread entry function that causes the risk of data race, and the call relationship that the object relates to is the call relationship that causes the risk of data race.

The application risk detection means may display an object having a data race risk, a thread entry function causing the data race risk, and a call relationship causing the data race risk.

Exemplary, as shown in FIG. 6, a schematic diagram of data race, including call relationships: thread entry function 1- > function 2- > variable 1, thread entry function 1- > function 2- > variable 2, thread entry function 3- > function 4- > variable 2.

If the variable 2 is called by the thread entry function 1 and the thread entry function 3 at the same time, the variable 2 has a data contention risk, the thread entry function 1 and the thread entry function 3 are thread entry functions causing the data contention risk, and the thread entry function 1- > -function 2- > -variable 2 and the thread entry function 3- > -function 4- > -variable 2 are call relations causing the data contention risk.

In one embodiment, the configuration file of the application program obtained by the application program risk detection device may further include a third party library.

Alternatively, the application risk detection device may parse a third party library of the application to obtain the calling relationship between the L objects.

Alternatively, the calling relationship between the L objects may be embodied in a relocation table of the unconnected third party library. Wherein, the relocation table is output by the compiler, describes the collection of relocation information in the section, and the relocation work is completed by the linker. The relocation information may include the location to be relocated, the type of relocation, and the target object information that is dependent.

Optionally, relocation means determining the running address of the object, when an object invokes the target object, the running address of the target object needs to be known, but in most cases, the compiling stage cannot know the running address of the target object, and at this time, the object whose running address is not determined needs to be handed to the linker to complete relocation, so as to determine the address of the target object.

For the call between the objects in the homologous code file, the application program directly determines the jump target address in the compiling stage, and the participation of the linker is not needed, so that the jump target address is not reflected in the relocation table of the third party library. Thus relying solely on relocation tables may miss call relationships between parts of the objects.

Optionally, the application risk detection device may simulate and execute the application according to the calling relationships between L objects in the third party library, where the application may call the objects in the third party library when simulating and executing the application, so that the application risk detection device may obtain the calling relationships between H objects. The H objects comprise the L objects and M objects. The application risk detection device can acquire calling relations among all objects in the application and the third party library, and can more comprehensively detect data competition risks in the application.

In one embodiment, the configuration file of the application risk detection device may not include a third party library, and the application risk detection device needs to perform simulation execution on each instruction in the application to determine a situation that the application calls the third party library.

The method simplifies external input, does not need to input a third party library, can also determine the condition that the application program calls the third party library, obtains the calling relationship between the application program and the objects in the third party library, and can more comprehensively detect the data competition risk in the application program.

In one embodiment, the configuration file of the application risk detection device may also include a function pointer, so as to improve the efficiency of the application risk detection device in simulating execution.

The risk of data competition exists in various fields such as smart phones, smart home, industrial control and the like. Therefore, the application program risk detection device can detect the data competition risk in the application program compiling process of the intelligent mobile phone, the intelligent home equipment and the industrial control equipment so as to eliminate the data competition risk.

In another embodiment, the configuration file of the application risk detection device may further include other files, and the corresponding other risks may be determined. Illustratively, the configuration file of the application risk detection device includes a file related to the shared memory, and the application risk detection device may determine a risk of consistency of data in the shared memory, and so on.

It should be noted that some operations in the flow of the above-described method embodiments are optionally combined, and/or the order of some operations is optionally changed. The order of execution of the steps in each flow is merely exemplary, and is not limited to the order of execution of the steps, and other orders of execution may be used between the steps. And is not intended to suggest that the order of execution is the only order in which the operations may be performed. Those of ordinary skill in the art will recognize a variety of ways to reorder the operations described herein. In addition, it should be noted that details of processes involved in a certain embodiment herein are equally applicable to other embodiments in a similar manner, or may be used in combination between different embodiments.

Moreover, some steps in method embodiments may be equivalently replaced with other possible steps. Or some steps in method embodiments may be optional and may be deleted in some usage scenarios. Or other possible steps may be added to the method embodiments.

Moreover, the method embodiments described above may be implemented alone or in combination.

Further embodiments of the present application provide an apparatus that may be an application risk detection apparatus or a component (such as a system-on-a-chip) in an application risk detection apparatus.

The apparatus may include: a memory and one or more processors. The memory is coupled to the processor. The memory is for storing computer program code comprising computer executable instructions. When the processor executes the computer-executable instructions, the electronic device may perform the functions or steps performed by the application risk detection apparatus in the above-described method embodiments.

The core structure of the application risk detection apparatus may be as shown in fig. 7, that is, includes: the device comprises a processing module 151, a transceiver module 152, a storage module 153 and a display module 154.

The processing module 151 may include at least one of a Central Processing Unit (CPU), an application processor (application processor), or a communication processor (communication processor). The processing module 151 may perform operations or data processing related to control and/or communication of at least one of the other elements of the application risk detection device. Optionally, the processing module 151 is configured to support the application risk detection device to execute S102 in fig. 4;

The transceiver module 152 is configured to obtain an application program (machine code of the application program) and/or a configuration file of the application program input by a developer, and transmit the obtained application program (machine code of the application program) and/or the configuration file of the application program to other modules of the application program risk detection device. The transceiver module 152 is further configured to send the object and/or the first information and/or the second information that are at risk to other devices.

The storage module 153 is configured to search and store a function in a storage space of a variable of an application program when the application program reads a memory address and if the read memory address corresponds to the variable. When the application program passes through the object called by the function pointer, the function list can be traversed, and the simulation execution efficiency is improved.

A display module 154 for displaying the object and/or the first information and/or the second information at risk.

Optionally, the application risk detection device may further comprise a communication module 155 for supporting the application risk detection device to communicate with other personal devices (via a communication network). For example, the communication module may be connected to a network via wireless communication or wired communication to communicate with other personal devices or web servers. The wireless communication may employ at least one of cellular communication protocols such as 5G, long Term Evolution (LTE), long term evolution-advanced (LTE-a), code Division Multiple Access (CDMA), wideband Code Division Multiple Access (WCDMA), universal Mobile Telecommunications System (UMTS), wireless broadband (WiBro), or global system for mobile communications (GSM). The wireless communication may include, for example, short-range communication. The short-range communication may include at least one of wireless fidelity (Wi-Fi), bluetooth, near Field Communication (NFC), magnetic Stripe Transmission (MST), or GNSS. For example, the application risk detection means sends the risk-bearing object and/or the first information and/or the second information to other devices.

The apparatus shown in fig. 7 may also include more, fewer, or split portions of the components, or have other arrangements of components, as embodiments of the application are not limited in this respect.

The embodiment of the present application also provides a chip system, as shown in fig. 8, which includes at least one processor 161 and at least one interface circuit 162. The processor 161 and the interface circuit 162 may be interconnected by wires. For example, interface circuit 162 may be used to receive data from other devices (e.g., a memory of an electronic apparatus). For another example, interface circuit 162 may be used to send data to other devices (e.g., processor 161). The interface circuit 162 may, for example, read instructions stored in the memory and send the instructions to the processor 161. The instructions, when executed by the processor 161, may cause the electronic device to perform the various steps of the embodiments described above. Of course, the system-on-chip may also include other discrete devices, which are not particularly limited in accordance with embodiments of the present application.

The embodiment of the application also provides a computer storage medium, which comprises computer executable instructions, when the computer executable instructions run on the electronic equipment, the electronic equipment is caused to execute the functions or steps executed by the mobile phone in the embodiment of the method. The aforementioned storage medium includes: a U-disk, a removable hard disk, a Read Only Memory (ROM), a random access memory (random access memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The embodiment of the application also provides a computer program product which, when run on a computer, causes the computer to execute the functions or steps executed by the mobile phone in the above method embodiment.

It will be apparent to those skilled in the art from this description that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above. The specific working processes of the above-described systems, devices and modules may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, and the division of modules or units, for example, is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and the parts displayed as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a readable storage medium. Based on such understanding, the technical solution of the embodiments of the present application may be essentially or a part contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, including several instructions for causing a device (may be a single-chip microcomputer, a chip or the like) or a processor (processor) to perform all or part of the steps of the method described in the embodiments of the present application. The foregoing is merely illustrative of specific embodiments of the present application, but the scope of the present application is not limited thereto, and any changes or substitutions within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (11)

1. An application risk detection method, the method comprising:

Acquiring a calling relation among M objects of an application program, wherein M is more than or equal to 2, and the objects comprise functions and/or variables; the calling relation among the M objects comprises at least one of a function access variable, a function calling function, a variable reference variable and a variable reference function;

And determining the object with risk according to the calling relation among the M objects and the operating system application program to which each object belongs, wherein the risk levels of at least two operating system application programs are different.

2. The method according to claim 1, wherein the method further comprises:

Displaying the object with risk.

3. The method according to claim 1 or 2, characterized in that the method further comprises:

Determining first information and/or second information according to the calling relation among the M objects and the operating system application program to which each object belongs; the first information represents the calling relation between the object with risk and other objects, and the second information represents the operating system application program to which the object with risk belongs;

and displaying the first information and/or the second information.

4. A method according to any one of claims 1-3, characterized in that the method comprises:

Acquiring a configuration file of the application program, wherein the configuration file comprises N sections and an operating system application program to which each section belongs, and N is greater than or equal to 1; the N segments include the M objects; each segment includes a data segment or a code segment;

And determining the operating system application program to which each object in the M objects belongs according to the configuration file.

5. The method of any of claims 1-4, wherein the risk comprises a cross-operating system application risk, the M objects comprise a first object and a second object, and the determining the object at risk according to the call relationship between the M objects and the operating system application to which each object belongs comprises:

And if the first object calls a second object, the first object is subordinate to a first operating system application program, the second object is subordinate to a second operating system application program, and the first operating system application program prohibits access to the second operating system application program, determining that the first object has risk of crossing the operating system application program.

6. A method according to any of claims 1-3, wherein the configuration file comprises a third party library of the application, the method further comprising:

Analyzing a third party library of the application program to obtain calling relations among L objects;

and simulating and executing the application program according to the calling relation among the L objects to obtain the calling relation among H objects, wherein the H objects comprise the L objects and the M objects.

7. The method of any of claims 1-6, wherein the configuration file further comprises a thread entry function, and wherein the determining the risky object comprises:

If at least more than two thread entry functions call the same object, determining that the object has data contention risk.

8. An application risk detection apparatus, comprising:

The receiving and transmitting module is used for acquiring calling relations among M objects of the application program, M is more than or equal to 2, and the objects comprise functions and/or variables; the calling relation among the M objects comprises at least one of a function access variable, a function calling function, a variable reference variable and a variable reference function;

And the processing module is used for determining the object with risk according to the calling relation among the M objects and the operating system application programs to which each object belongs, and the risk levels of at least two operating system application programs are different.

9. The apparatus of claim 8, wherein the apparatus further comprises:

and the display module is used for displaying the object with the risk.

10. An application risk detection system comprising an application risk detection apparatus as claimed in claim 8 or 9.

11. A computer readable storage medium comprising a computer program or instructions which, when run on an application risk detection device, cause the application risk detection device to perform the method of any of claims 1-7.